[horde] Email attachments with special filenames

[Jens Wahnes]

Hi,

today, I looked into the encoding employed by Horde to properly transmit 
the file name of attachments sent through Imp. We've had some users 
complaining about files they sent not being displayed properly at the 
recipient's side (which uses some non Horde email client).  Horde uses 
RFC 2231 encoding where appropriate, which is good, of course, even 
though not every other mail client is able to handle RFC 2231 encoded 
file names properly.

However, it seems to me that Horde is generating those RFC 2231 headers 
incorrectly in some cases.  Consider an attachment that has got a file 
name containing special non-ASCII characters, but the contents of the 
file are pure ASCII, i.e. "text/plain" as per MIME with no declaration 
of character set required.  If such a file is attached, the file name is 
encoded according to RFC 2231 rules, but the charset of the encoded file 
name (given before the first single quote character in the encoded line) 
is set to "us-ascii", which is wrong.

To make things clearer, here is an example of email headers generated by 
Horde in the case described before:

---

Subject: File with strange filename but pure ASCII content is attached
User-Agent: Horde Application Framework 5
Content-Type: multipart/mixed; boundary="=_m5H-xgvB12M0GEygFUEQ7FY"
MIME-Version: 1.0

This message is in MIME format.

--=_m5H-xgvB12M0GEygFUEQ7FY
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline

This message has got an attachment that contains pure ASCII text, but
the file name of the attachment is somewhat eccentric.

--=_m5H-xgvB12M0GEygFUEQ7FY
Content-Type: text/plain;
 
name*0*=us-ascii''File%20with%20a%20long%20name%20co%F1ta%EFning%20str%E5ng;
  name*1*=e%20characters%20but%20pure%20ASCII%20content.txt
Content-Disposition: attachment; size=27;
 
filename*0*=us-ascii''File%20with%20a%20long%20name%20co%F1ta%EFning%20str;
  filename*1*=%E5nge%20characters%20but%20pure%20ASCII%20content.txt

Hello Peter, how are you?

--=_m5H-xgvB12M0GEygFUEQ7FY--

---

I hope the above information is sent correctly, considering I'm trying 
to discuss MIME matters in an email using MIME. ;-)

The name of the attached file should read "File with a long name 
coñtaïning strånge characters but pure ASCII content.txt".

As you can see, the non-ASCII characters in the file name like "ñ" in 
the word "coñtaïning" are encoded in the "first" (number 0) "name" and 
"filename" lines with two hex chars (0xF1), or one byte (octet if you 
will).  So the actual character set used is ISO-8859-1 or similar, as 
opposed to the declared charset "us-ascii", which would not even contain 
the "ñ" character, as there is no character with hex code above 0x7F 
available in ASCII anyway.

It seems that this only happens on attachments that have got pure ASCII 
content.  When the attached file itself contains e.g. UTF-8 characters 
and the file name contains non-ASCII characters too, the file name is 
encoded correctly, e.g. an "ñ" in the filename is represented by 
"%C3%B1" (two bytes in UTF-8) in that case and the charset declared is 
"utf-8".

So, in conclusion, could it be that Horde is using the charset of the 
attachment's /content/ in the place where it should use the charset of 
the attachment's /filename/?
If so, I'm not sure where a bug report should go.  Is this an issue of 
Imp?  Or of Horde_Mime?  Or some other package I'm not even aware of?

If you need more info to reproduce this, I'll be glad to provide it. The 
assessments above where made using Imp 6.2.18, Horde 5.2.14, and 
Horde_Mime 2.10.3.

Thanks,

Jens