mimePart.php - uncommon header encoding #1617

rcubetrac opened this Issue Jun 23, 2008 · 9 comments


None yet
1 participant

Reported by rosali on 23 Jun 2008 10:10 UTC as Trac ticket #1485151

Content-Type: application/msword;
Content-Disposition: attachment;

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!


Migrated-From: http://trac.roundcube.net/ticket/1485151

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.

Owner changed by @alecpl on 23 Jun 2008 12:58 UTC

=> none

Milestone changed by @alecpl on 23 Jun 2008 12:58 UTC

later => 0.2-beta

Comment by @alecpl on 30 Aug 2008 17:06 UTC

#1485225 marked as duplicate.

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:

 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](1c253664]).

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;

while kmail for example does what RFC2183 says:

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

Comment by arekm on 3 Sep 2008 12:18 UTC

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

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

Comment by arekm on 3 Sep 2008 16:50 UTC

Content-Disposition: attachment;

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

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

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

RFC2045 says:

 value := token / quoted-string

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

Comment by @alecpl on 5 Sep 2008 06:56 UTC

Fixed in [and 5df0ad0(e8a1b7e]), but we're still using RFC2231 and Outlook is not capable for that.

Status changed by @alecpl on 5 Sep 2008 06:56 UTC

new => closed

@rcubetrac rcubetrac closed this Sep 5, 2008

@rcubetrac rcubetrac added this to the 0.2-beta milestone Mar 20, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment