Yes.  My commits fixed the display of multi-line RFC 2231 encoded 
values - such as in "e-mail-with-attached-greek-filename.txt".  The 
code didn't handle these multi-line values correctly previously.



There is nothing to fix in the "...simple.txt" example.  The filename 
parameter is incorrectly encoded by Thunderbird, so there is nothing 
to unencode.  The name parameter is as follows:

  filename*=%C4%EF%EA%E9%EC%E1%F3%F4%E9%EA%FC.doc



As *clearly* indicated by RFC 2231 [4]:

Note also that the single quote delimiters MUST be present even when 
one of the field values is omitted.

No, it didn't. That was (supposed to be) fixed.
No, you never will, because IE is broken.

Your fixes didn't change anything for me. Did you try with the 
attached message?

A bit confused here: since Horde handles MIME encoding correctly by 
RFC standards, what was the fix that was applied? Which behaviour 
should I check to confirm the fix? Should I now be able to download 
filenames correctly with IExplorer in all cases?



Thanks.

Should be fixed in Horde HEAD and 3.1.4.  Testing/additional feedback 
would be great.

This is an issue with RFC 2231 encoding; namely, the recognition of 
RFC 2231 encoded fields in MIME_Structure:: (the actual RFC 2231 
decoding code in MIME.php works fine).

The second message is not handled correctly by IMP, it only happens to 
work with IE by accident, probably because you are using a Windows 
version which uses iso-8859-7. It's not working for any other 
operating system, language, or browser.

In trying to figure out what differs between the two cases, I see that 
if the message includes an attachment with a filename like this:

filename*=ISO-8859-7''%C4%EF%EA%E9%EC%E1%F3%F4%E9%EA%FC.doc

the link that IMP 4.1.3 offers for downloading is like this:

https://webmail.auth.gr/horde_for_stpetrak/services/download/?module=imp&thismailbox=INBOX&index=1060&

mailbox=INBOX&actionID=download_attach&id=2&mimecache=8bec980a27dabc720f1e028b02d27a30

&fn=%2F%25CE%2594%25CE%25BF%25CE%25BA%25CE%25B9%25CE%25BC%25CE%25B1%25CF%2583%25CF%2584%25CE%25B9%25CE%25BA%25CF%258C.doc

Notice that the originally 11 char long filename was incorrectly 
translated into a 22 char long filename, probably due to an 
inappropriate UTF-8 conversion.



On the other hand, if the message includes an attachment with a 
filename like this:

filename*=%C4%EF%EA%E9%EC%E1%F3%F4%E9%EA%FC.doc

the link that IMP 4.1.3 offers for downloading is like this:

https://webmail.auth.gr/horde_for_stpetrak/services/download/?module=imp&thismailbox=INBOX&index=1061&

mailbox=INBOX&actionID=download_attach&id=2&mimecache=a112acf7855208dfd1c1cc07265d542c

&fn=%2F%25C4%25EF%25EA%25E9%25EC%25E1%25F3%25F4%25E9%25EA%25FC.doc

Notice that the originally 11 char long filename was correctly 
translated into a 11 char long UTF-8 filename and it is correclty 
downloaded by IExplorer.



Hope all these can be of help.

And here is a simpler version of a filename encoding that works.



The trick is to remove the charset specification from the following line:

filename*=ISO-8859-7''%C4%EF%EA%E9%EC%E1%F3%F4%E9%EA%FC.doc

and present it to Internet Explorer browsers as:

filename*=%C4%EF%EA%E9%EC%E1%F3%F4%E9%EA%FC.doc

which allows them to correctly display the filename while 
downloading-saving the file.



Thanks.

OK, here it, the full message source.

Note that the message is composed by Thunderbird and the filename is 
split in two parts in the MIME description. As a resut IMP does not 
display it correctly, but downloads it fine from Internet Explorer 
browsers, specifying only the second part of the filename (See 
separate bug report for this issue with split filenames: [#4347] ).

Sorry for my misinterpratation, it not a UTF-8 encoding at all, just a 
URL encoding with 1 byte per character.



It works fine for IExplorer downloads, and it is the way Mozilla 
Thunderbird encodes attachment filenames !!!



Thanks.

Please upload the complete message source to this ticket as an attachment.

Both were included in original mail. Here is one that works, as it 
spells out the filename in what looks like a UTF-8 encoding of 2-bytes 
for each character:



--------------080904060007010807050604

Content-Type: application/msword; 
name*=ISO-8859-7''%C4%EF%EA%E9%EC%E1%F3%F4%E9%EA%FC%E1%F1%F7%E5.doc

Content-Transfer-Encoding: base64

Content-Disposition: inline; 
filename*=ISO-8859-7''%C4%EF%EA%E9%EC%E1%F3%F4%E9%EA%FC%E1%F1%F7%E5.doc



And here is one that does not work, since it requires deconding from 
IE, which does not recognize the encoding specifier:



--=_3z1haj6nfrs4

Content-Type: application/msword;

         name="=?iso-8859-7?b?5O/q6ezh8/Tp6vzh8ffl3+8uZG9j?="

Content-Disposition: attachment;

         filename="=?iso-8859-7?b?5O/q6ezh8/Tp6vzh8ffl3+8uZG9j?="

Content-Transfer-Encoding: base64



Thanks.

Interesting. Can you upload the message sources of a message that 
works, and one that doesn't?

Thanks Jan,



Is there a chance that this other encoding method could be implemented 
for attachment filenames in Composing mails in future IMP versions, 
that would solve the problem for IExplorer downloads?



We have confirmed that encoding filenames like this, with base64 
encoding, solves the problem:



--------------080904060007010807050604

Content-Type: application/msword; 
name*=ISO-8859-7''%C4%EF%EA%E9%EC%E1%F3%F4%E9%EA%FC%E1%F1%F7%E5.doc

Content-Transfer-Encoding: base64

Content-Disposition: inline; 
filename*=ISO-8859-7''%C4%EF%EA%E9%EC%E1%F3%F4%E9%EA%FC%E1%F1%F7%E5.doc



Thanks.

This is indeed a well known bug in Internet Explorer which is ignoring 
the charset we send with the filename. Since we send the file as-is, 
only providing the charset with it, it doesn't matter how the file 
name is encoded in the mime part headers.

In messages composed from IMP 4.1.3 with attachment filenames that 
contain greek (ISO-8859-7) characters, even though they are received 
and displayed correctly in IMP 4.1.3, when downloaded from IExplorer 
browsers, filenames appear garbled in OS save dialog window and file 
type info is destroyed.



On the other hand, when the same attachments are downloaded from 
Mozilla Firefox, filenames appear and get saved correctly.



Example message source of attachment filename that is not downloaded 
correctly:



--=_3z1haj6nfrs4

Content-Type: application/msword;

        name="=?iso-8859-7?b?5O/q6ezh8/Tp6vzh8ffl3+8uZG9j?="

Content-Disposition: attachment;

        filename="=?iso-8859-7?b?5O/q6ezh8/Tp6vzh8ffl3+8uZG9j?="

Content-Transfer-Encoding: base64



This is probably an Internet Explorer bug, but since it affects all 
IExplorer users when handling attachment filenames with international 
character sets, you may want to consider offering a workaround solution.



A solution could be to offer a different filename encoding type which 
seems to work for IExplorer as well as other browsers, e.g. base64 
encoded filenames:



--------------080904060007010807050604

Content-Type: application/msword; 
name*=ISO-8859-7''%C4%EF%EA%E9%EC%E1%F3%F4%E9%EA%FC%E1%F1%F7%E5.doc

Content-Transfer-Encoding: base64

Content-Disposition: inline; 
filename*=ISO-8859-7''%C4%EF%EA%E9%EC%E1%F3%F4%E9%EA%FC%E1%F1%F7%E5.doc





Thanks.