[Tickets #14618] Attachments with special file names (RFC 2231)

[noreply at bugs.horde.org]

BITTE NICHT AUF DIESE NACHRICHT ANTWORTEN. NACHRICHTEN AN DIESE  
E-MAIL-ADRESSE WERDEN NICHT GELESEN.

Ticket-URL: https://bugs.horde.org/ticket/14618
------------------------------------------------------------------------------
  Ticket           | 14618
  Erstellt Von     | wahnes at uni-koeln.de
  Zusammenfassung  | Attachments with special file names (RFC 2231)
  Warteschlange    | IMP
  Version          | 6.2.18
  Typ              | Bug
  Status           | Unconfirmed
  Priorität        | 2. Medium
  Milestone        |
  Patch            |
  Zuständige       |
------------------------------------------------------------------------------


wahnes at uni-koeln.de (2017-04-18 11:03) hat geschrieben:

In some cases, the RFC 2231 encoding of the file name for attached  
files is wrong, causing trouble on the receiving side of email with  
such attachments. This seems to be happening when the *content* of an  
attachment is pure ASCII but the *filename* contains non-ASCII  
characters.

Example:
Given a file by the name of "File with a long name coñtaïning strånge  
characters but pure ASCII content.txt" that does, as the name implies,  
contain only ASCII characters and thus will have a MIME encoding of  
"Content-Type: text/plain". When attaching this file, the file name  
will be encoded like this:

name*0*=us-ascii''File%20with%20a%20long%20name%20co%F1ta%EFning%20str%E5ng;
name*1*=e%20characters%20but%20pure%20ASCII%20content.txt

Note that the charset used for the encoding of the filename (given  
before the first single-quote character in the "name*0*" line) is  
"us-ascii" in this case. Cleary, this cannot be the case as ASCII does  
not contain the character "ñ". In fact, ASCII does not contain any  
character with hex code above 0x7F, so an encoding that uses a hex  
code "F1" with "us-ascii" must be wrong. The actual charset would be  
ISO-8859-1 or similar, as it contains the "n" with tilde at position  
0xF1 (241 decimal).

This error does not happen, however, when the attachment's *content*  
has non-ASCII characters in it. When attaching a file that has got  
both non-ASCII content and a non-ASCII name, the encoding generated by  
Horde is fine. For example, a file by the name of "Example file with  
name coñtaïning strånge characters which has non-ASCII content  
too.txt" that does in fact contain non-ASCII content (e.g. the string  
"Hallo Bärbel") is encoded correctly. In this case, the encoding  
generated would be

name*0*=utf-8''Example%20file%20with%20name%20co%C3%B1ta%C3%AFning%20str;
name*1*=%C3%A5nge%20characters%20which%20has%20non-ASCII%20content%20too.tx;
name*2*=t

which is perfectly right. For instance, the "ñ" is encoded here as two  
characters in UTF-8, 0xC3 and 0xB1, which is correct.

The root cause of the problem seems to be that Horde uses the charset  
of the attachment's *content* to encode the attachment's filename.  
This is wrong because the filename can use a different encoding than  
the content. This issue manifests itself as well when there is an  
attachment that contains non-ASCII characters but the filename uses  
pure ASCII: the filename will be encoded as "UTF-8". This does not  
cause real problems because any ASCII text is also valid UTF-8 text,  
but it adds to my assumption that Horde wrongfully uses the content's  
charset in the place where the filename's charset should be used.

I will attach a zip file with four files that can be used to  
illustrate the problem:
1. File with ASCII content and ASCII filename --> OK.
2. File with ASCII content and non-ASCII filename --> wrong.
3. File with non-ASCII content and ASCII filename --> OK in a way  
because UTF-8 is a superset of ASCII.
4. File with non-ASCII content and non-ASCII filename --> OK.

I hope the file names will be preserved correctly in the zip file.  
This zip file was generated using Microsoft Windows's built-in ZIP  
functionality, so the file names might not be recognized as they  
should everywhere. If you are unable to read them, I will try some  
other way to send them.



wahnes at uni-koeln.de (2017-04-18 11:03) hat hochgeladen: horde  
attachment examples rfc 2231.zip

https://bugs.horde.org/h/services/download/?app=whups&actionID=download_file&file=horde%20attachment%20examples%20rfc%202231.zip&ticket=14618&fn=%2Fhorde%20attachment%20examples%20rfc%202231.zip