mimePart.php - uncommon header encoding

[rosali]

---

Content-Type: application/msword;

name*0*="UTF-8xxxxxholding%20AG,%20Pr%C3%BCfung%20f%C3%BCr%20xxxxxxxx_"
name*1*="ge%C3%A4_Liebl.doc";

Content-Disposition: attachment;

filename*0*="UTF-8xxxxxholding%20AG,%20Pr%C3%BCfung%20f%C3%BCr%20xxxxx"
filename*1*="xxx_ge%C3%A4_xxxxx.doc";

---

mimePart.php function _buildHeaderParam encodes the Content-Type and the Content-Disposition header in an uncommon way. Neither RC itself nor f.e. Outlook express understands this encoded stuff.

I simply switched back to the old mimePart.php (before SVN 1530) which solved the issue for me!

-Roland

[alec]

It's RFC2231. Section 3. Parameter Value Continuations. The headers are looking good, but small number of servers and clients supports that feature. "IMAP4 [RFC-2060] servers SHOULD decode parameter value continuations when generating the BODY and BODYSTRUCTURE fetch attributes." but my dovecot don't do this.

[alec]

#1485225 marked as duplicate.

[arekm]

[1c253664] change is wrong for Content-Disposition header. Looks like different MIME headers need to be treated differently.

RFC2183 talks explictly about Content-Disposition and it says:

 NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters)
   parameter value containing only non-`tspecials' characters SHOULD be
   represented as a single `token'.  A short parameter value containing
   only ASCII characters, but including `tspecials' characters, SHOULD
   be represented as `quoted-string'.  Parameter values longer than 78
   characters, or which contain non-ASCII characters, MUST be encoded as
   specified in [RFC 2184].

So ascii only characters should be shown as raw ascii without any encoding/quoting.
ascii with tspecials should be shown as ascii + tspecial characters quoted using backslash
(rfc822 defines this quoted-string). Non ASCII header should be encoded using RFC 2184.

Currently roundcube encodes pure ascii headers using rfc2184 like this one:

Content-Disposition: attachment;
 filename*="UTF-8''aaa%20bbb%20ccc.pdf"; 

while kmail for example does what RFC2183 says:

Content-Disposition: attachment;
	filename="aaa bbb ccc.pdf

[arekm]

kmail part should be of course (I didn't copy ending ")

Content-Disposition: attachment;
	filename="aaa bbb ccc.pdf"

[arekm]

Content-Disposition: attachment;

filename="=?ISO-8859-2?B?YWFhYWGxs/G286/R06bRLnR4dA==?="

google mail uses qp encoding. Hm, the rfc2183 says:

  filename-parm := "filename" "=" value

  `Extension-token', `parameter', `tspecials' and `value' are defined
   according to [RFC 2045] (which references [RFC 822] in the definition
   of some of these tokens).  `quoted-string' and `DIGIT' are defined in
   [RFC 822].

RFC2045 says:

 value := token / quoted-string

but quoted-string is not "quoted-printable" stuff... and I'm lost on what's correct here.

[arekm]

Part of solution. Revert wrong commit r1576 and quote tspecials as defined in RFC2045.

[alec]

Fixed in [e8a1b7ef] and [5df0ad04], but we're still using RFC2231 and Outlook is not capable for that.