[OGo-Bugs][Bug 1872] New: OGo does not handle RFC2231 type header fields

[bugs@opengroupware.org]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1872

           Summary: OGo does not handle RFC2231 type header fields
           Product: OpenGroupware.org
           Version: 1.0.0
          Platform: PC
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: normal
         Component: Mailer
        AssignedTo: qa@opengroupware.org
        ReportedBy: samuli.seppanen@tietoteema.fi
         QAContact: qa@opengroupware.org
                CC: bugs@opengroupware.org


>From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201
Firefox/2.0.0.3 (Ubuntu-feisty)

Description of problem:
It seems to me that OGo webmail does not know how to (reliably?) interpret MIME
values as defined in RFC2231. This problem has been reproduced on OGo
1.0.0-final and OGo 1.0b2.

Anyway, I found the problem (see below) after reading through RFC's 2045, 2046,
2047, 2183 and 2231. The problem  is caused by the attachment's "content-type"
field's parameter "name".  There are two ways to specify the used "charset" and
"encoding".
According to older rfc2047 a s.c. "encoded word" is defined as

=? "charset" ? "encoding" ? "text" ?=

The newer rfc2231 defines another approach, which should is constructed like
this (a bit simplified):

parameter*=charset'language'value

--------

OGo webmail uses the older (rfc2047) approach, as seen in this header field:

------=_=-_OpenGroupware_org_NGMime-18020-1178262786.733317-9------
content-disposition: inline; filename="=?iso-8859-15?q?=E4=F6=E5=2Eodt?="
content-length: 8532
content-transfer-encoding: base64
content-type: application/vnd.oasis.opendocument.text;
name="=?iso-8859-15?q?=E4=F6=E5=2Eodt?="

This is interpreted by OGo webui correctly, and is displayed correctly in OGo webui:

Content Type: application/vnd.oasis.opendocument.text; name=äöå.odt

Thunderbird however creates headers like this:

--------------030000090803040504070503

Content-Type: application/vnd.oasis.opendocument.text;
name*=ISO-8859-1''%E4%F6%E5%2E%6F%64%74
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename*=ISO-8859-1''%E4%F6%E5%2E%6F%64%74

This uses the newer charset/language definition, which is not interpreted
correctly by OGo. It shows up as this in OGo webui, even though the name should
be parsed correctly to "äöå.odt"

Content Type: application/vnd.oasis.opendocument.text;
name*=ISO-8859-1''%E4%F6%E5%2E%6F%64%74

Apple Mail creates attachments slightly differently. These get messed up too
when viewed with OGo webmail.

--Apple-Mail-1-239892612
Content-Transfer-Encoding: base64
Content-Type: application/vnd.oasis.opendocument.text;
    x-mac-type=4E4F2546;
    x-unix-mode=0644;
    name==?ISO-8859-1?Q?=F6=E4=E5=D6=C4=C5.odt?=
Content-Disposition: attachment;
    filename*=ISO-8859-1''%F6%E4%E5%D6%C4%C5.odt

Even though both RFC2231 and RFC2047 conventions are used in the same entity,
this should still be valid. It does, however, look
like this in OGo Webui:

Content Type: application/vnd.oasis.opendocument.text; x-unix-mode=0644;
x-mac-type=4E4F2546

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Login to a Linux / MacOS X (any recent version with some UTF-8 locale as default)
2. Create a new mail with Thunderbird / Evolution
3. Attach a file which has scandinavian letters in the filename (filename in
UTF-8) such as a or u umlaut (ä or ö).
4. Send the message to a OGo user
5. Read the message via OGo WebUI as the recipient OGo user

Actual Results:  Attachment filename is messed up, as OGo interprets the name
wrong. Saving it to disk (Mozilla Firefox) works, but the filename is generated
from the MIME type, something like this:

download.vnd.oasis.opendocument.text

The actual filename is not used at all. 

Expected Results:  The filename should display correctly, as above examples in
description are valid RFC2231.

Additional info:

OGo sends mails in RFC2047 format which is fine. But it should interpret 
RFC2231-formatted mails correctly. This problem does not pop up if plain
US-ASCII mails is used.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.