mimePart.php - uncommon header encoding #1617

Closed
rcubetrac opened this Issue Jun 23, 2008 · 9 comments

1 participant

@rcubetrac

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

----Snippet----
Content-Type: application/msword;
name0="UTF-8''xxxxxholding%20AG,%20Pr%C3%BCfung%20f%C3%BCr%20xxxxxxxx_"
name1="ge%C3%A4_Liebl.doc";
Content-Disposition: attachment;
filename0="UTF-8''xxxxxholding%20AG,%20Pr%C3%BCfung%20f%C3%BCr%20xxxxx"
filename1="xxx_ge%C3%A4_xxxxx.doc";
----Snippet----

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

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

@rcubetrac

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.

@rcubetrac

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

=> none

@rcubetrac

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

later => 0.2-beta

@rcubetrac

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

#1485225 marked as duplicate.

@rcubetrac

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;
 filename*="UTF-8''aaa%20bbb%20ccc.pdf"; 

while kmail for example does what RFC2183 says:


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

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"
@rcubetrac

Comment by arekm on 3 Sep 2008 16:50 UTC

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 [2045](RFC) (which references [822](RFC) in the definition
   of some of these tokens).  `quoted-string' and `DIGIT' are defined in
   [822](RFC).

RFC2045 says:

 value := token / quoted-string

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

@rcubetrac

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.

@rcubetrac

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