Bug 803991

Created attachment 570539 [details]
problem mbox

Thanks for a bug report. I tried to reproduce this, but with no luck. I suppose this was downloaded by evolution-mapi, right? I created a similar message and tried to upload it to an Exchange 2007 server, but the filename is shown property if I download it. I then named my TXT file the same as is your PDF, and sent a message from various clients (including Outlook 2007 and OWA of the server), and all I receive have the filename set correctly. From the difference on your test message and my message I see that yours is using
> Content-Disposition: attachment;
>    filename="FIS =?UTF-8?Q?Direct=5F=D0=94=D0=91=D0=9E=5F2012=2Epdf?="
while mine has:
> Content-Disposition: attachment;
>    filename*=UTF-8''FIS%20Direct_%D0%94%D0%91%D0%9E_2012.txt
Note of the different notation of the same value.

I suspect that your value is stored on the server, which might be fault of the client which sent it.

Furthermore, yours encoding is defined in RFC2047 [1], see beginning of page 7 there, where is written that this encoding is useless for Content-Type or Content-Disposition parameters, where should be used encoding which uses evolution, described in RFC2231 [2]. Thus we may try find out where this was created.

[1] http://tools.ietf.org/html/rfc2047
[2] http://tools.ietf.org/html/rfc2231

I was send also empty file from Outlook 2007 and original file from Gmail with name "FIS Direct_ДБО_2012.pdf" and always received mail with attached file with incorrect file name. The main condition seems to get this bug is to use evolution-mapi.

I tried to reproduce this with my exchange server, but it seems to be different here. I sent attachments with your filename from GMail to my account, and GMail encoded file names for the attachments differently, depending on the settings of GMail account, namely the option for encoding being used for message text. If I left there the default encoding (the non-utf8), then I receive attachment named as
> name="=?KOI8-R?B?RklTIERpcmVjdF/k4u9fMjAxMi50eHQ=?="
while if I select there to use utf8 encoding, then the attachment is received like:
> name="=?UTF-8?B?RklTIERpcmVjdF/QlNCR0J5fMjAxMi5wZGY=?="
which is still different from that yours version of the string. More interesting is that the evolution-mapi should receive filename decoded, and the eds part only transforms utf8 name (it's always in utf8 for evolution) to the value you see in message's source view for the message being received by evolution-mapi. That means that your server probably stored it as 
> >    filename="FIS =?UTF-8?Q?Direct=5F=D0=94=D0=91=D0=9E=5F2012=2Epdf?="
but it's quite unexpected.

We can check this out, fortunately. All locally downloaded messages are stored in
   ~/.cache/evolution/mail/<mapi-account-id>/folders/Mailbox - .....
they are stored in subfolders of that folder, with their message IDS. The hard part is to find out the correct file to delete. I would like to delete it and let evoluton-mapi download it again with debugging turned on, thus we will be able to check what is received from the server. One option is to rename folder
   ~/.cache/evolution/mail/<mapi-account-id>/folders/ to
   ~/.cache/evolution/mail/<mapi-account-id>/folders.old/
and then start evolution like this:
   $ MAPI_DEBUG=1 evolution &>log.txt
and then select the message with this attachment. You should see that the message is downloaded again, rather than picked up from the local cache. When it's done close evolution again and rename the "folders.old" back to "folders", thus evolution-mapi will not download all your messages again. I would also move away cache for the particular folder only, not for all of them, especially if you download messages for offline.

I suppose you have at least evolution-mapi-3.3.91, where the MAPI_DEBUG variable was introduced.

Created attachment 574797 [details]
received with ews

I received this message throught exchange-ews connector, and attach file name is right. Please compare right and wrong mboxes it can help solve problem in mapi connector.

Aha, this is interesting. It also uses utf-8, but encoded as base64, not as quoted printable, and it makes it work as expected.

> Content-Type: application/pdf;
>    name="=?utf-8?B?RklTIERpcmVjdF/QlNCR0J5fMjAxMi5wZGY=?="
> Content-Description: =?utf-8?B?RklTIERpcmVjdF/QlNCR0J5fMjAxMi5wZGY=?=
> Content-Disposition: attachment;
>    filename="=?utf-8?B?RklTIERpcmVjdF/QlNCR0J5fMjAxMi5wZGY=?=";
>    size=1275810; creation-date="Wed, 14 Mar 2012 09:20:17 GMT";
>    modification-date="Wed, 14 Mar 2012 09:20:17 GMT"
> Content-ID: <2a24b31d-6b83-46d4-b323-9537c9309249>
> Content-Transfer-Encoding: base64

evo-mapi chose for you quoted printable, as I wrote above:
> Content-Disposition: attachment;
>    filename="FIS =?UTF-8?Q?Direct=5F=D0=94=D0=91=D0=9E=5F2012=2Epdf?="

I'm still unsure why evo-mapi chose quoted printable for you, but not for me. The equations inside the encoded string probably confused evolution itself.

Could you try the testing I asked for in comment #4, please? It'll show what was received from the server itself, by evo-mapi, which may explain couple things here.

Created attachment 575035 [details]
receive mapi log

Thanks for the update. I see the server sends this correctly, thus it's evolution-data-server itself breaking the stored value.
      PidTagDisplayName  (unicodestring) - 'FIS Direct_ДБО_2012.pdf'
      PidTagAttachExtension  (unicodestring) - '.pdf'
      PidTagAttachFilename  (unicodestring) - 'FISDir~1.pdf'
      PidTagAttachLongFilename  (unicodestring) - 'FIS Direct_ДБО_2012.pdf'
      PidTagAttachMimeTag  (unicodestring) - 'application/pdf'

I used these values in my test and when I run evolution with LANG=ru_RU.utf8,
then I get:
> Content-Disposition: attachment; 
>     filename*=koi8-r''FIS%20Direct_%E4%E2%EF_2012.pdf

or if I run it with LANG=en_US.utf8
> Content-Disposition: attachment; 
>     filename*=UTF-8''FIS%20Direct_%D0%94%D0%91%D0%9E_2012.pdf

The most confusing thing to me is that we are using basically the same code, thus we should have see same results. Also because this all is done on evolution's side only, there is nothing with the server (as you proved with your MAPI log).

Could you paste here output of the locale command, please? It's simple as this:
   $ locale

I suppose if you'll clear your cache again and redownload the message when you'll have evolution run as this:
   $ LANG=en_US.utf8 evolution
then you'll see the same result as I do, with the correctly shown filename in evolution. After that I will try with your LANG here, to see whether I'll be finally able to reproduce this.

[mikhail@telecon17l drive_c]$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=ru_RU.utf8
LC_TIME=ru_RU.utf8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=ru_RU.utf8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT=ru_RU.utf8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
[mikhail@telecon17l drive_c]$

runing  $ LANG=en_US.utf8 evolution not solve problem :(

Aah, I finally got it. It wasn't the LANG causing this, it's the option in preferences, namely: Edit->Preferences->Composer Preferences->Encode filenames in an Outlook/GMail way. I have it turned off and it works as expected, while if I turn it on, then I see same broken encoding and
> FIS =?UTF-8?Q?Direct=5F=D0=94=D0=91=D0=9E=5F2012=2Epdf?=
in evolution as you do (after I refetch the message).

I'll move this upstream as soon as I figure out which place will be the best to fix it. Thanks for your cooperation on this issue.

I moved this to evolution-data-server [1], to fix the encoding workaround there, rather than trying to workaround an issue in evolution-mapi (it would be workaround on a workaround, which doesn't sound good at all). Feel free to CC there, in case there will be any follow-ups, even I do not expect any. Only note that to have this fixed in evolution mapi the message should be refetched from the server, thus it'll be reencoded into MIME message from MAPI properties. You can, as a workaround, uncheck the option from comment #11, though you still need to refetch the message.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=673563