Opened 6 years ago

Closed 6 years ago

#1485151 closed Bugs (fixed)

mimePart.php - uncommon header encoding

Reported by: rosali Owned by:
Priority: 5 Milestone: 0.2-beta
Component: MIME parsing Version: 0.2-alpha
Severity: normal Keywords:
Cc:

Description


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

Attachments (1)

tspecials.patch (1.5 KB) - added by arekm 6 years ago.
Part of solution. Revert wrong commit r1576 and quote tspecials as defined in RFC2045.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 6 years ago by alec

  • Component changed from Client Scripts to MIME parsing
  • Milestone changed from later to 0.2-beta

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:2 Changed 6 years ago by alec

#1485225 marked as duplicate.

comment:3 Changed 6 years ago by 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

comment:4 Changed 6 years ago by arekm

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

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

comment:5 Changed 6 years ago by 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.

Changed 6 years ago by arekm

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

comment:6 Changed 6 years ago by alec

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.