Join GitHub today
mimePart.php - uncommon header encoding #1617
Reported by rosali on 23 Jun 2008 10:10 UTC as Trac ticket #1485151
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!
Comment by @alecpl on 23 Jun 2008 12:58 UTC
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.
Comment by arekm on 3 Sep 2008 12:17 UTC
[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:
So ascii only characters should be shown as raw ascii without any encoding/quoting.
Currently roundcube encodes pure ascii headers using rfc2184 like this one:
while kmail for example does what RFC2183 says:
Comment by arekm on 3 Sep 2008 16:50 UTC
google mail uses qp encoding. Hm, the rfc2183 says:
but quoted-string is not "quoted-printable" stuff... and I'm lost on what's correct here.