New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mimePart.php - uncommon header encoding #1617

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

Comments

Projects
None yet
1 participant
@rcubetrac

rcubetrac commented Jun 23, 2008

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

----Snippet----
Content-Type: application/msword;
name_0_="UTF-8''xxxxxholding%20AG,%20Pr%C3%BCfung%20f%C3%BCr%20xxxxxxxx_"
name_1_="ge%C3%A4_Liebl.doc";
Content-Disposition: attachment;
filename_0_="UTF-8''xxxxxholding%20AG,%20Pr%C3%BCfung%20f%C3%BCr%20xxxxx"
filename_1_="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

This comment has been minimized.

rcubetrac commented Jun 23, 2008

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

This comment has been minimized.

rcubetrac commented Jun 23, 2008

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

=> none

@rcubetrac

This comment has been minimized.

rcubetrac commented Jun 23, 2008

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

later => 0.2-beta

@rcubetrac

This comment has been minimized.

rcubetrac commented Aug 30, 2008

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

#1485225 marked as duplicate.

@rcubetrac

This comment has been minimized.

rcubetrac commented Sep 3, 2008

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

This comment has been minimized.

rcubetrac commented Sep 3, 2008

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

This comment has been minimized.

rcubetrac commented Sep 3, 2008

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

This comment has been minimized.

rcubetrac commented Sep 5, 2008

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

This comment has been minimized.

rcubetrac commented Sep 5, 2008

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