Feature: Basic support for RFC 2231
Opened this issue · 3 comments
An administrator reported an issue where this extension isn't correctly handling an attachment.
It seems that iTop is processing the e-mail, but the failure occurs due to a lack of support for RFC 2231.
The result is a corrupted attachment, with corrupted file name and no content.
Combining Character Set, Language, and Parameter Continuations
Character set and language information may be combined with the
parameter continuation mechanism. For example:
Content-Type: application/x-stuff
title0=us-ascii'en'This%20is%20even%20more%20
title1=%2A%2A%2Afun%2A%2A%2A%20
title*2="isn't it!"
Note that:
(1) Language and character set information only appear at
the beginning of a given parameter value.
(2) Continuations do not provide a facility for using more
than one character set or language in the same
parameter value.
(3) A value presented using multiple continuations may
contain a mixture of encoded and unencoded segments.
Freed & Moore Standards Track [Page 5]
RFC 2231 MIME Value and Encoded Word Extensions November 1997
(4) The first segment of a continuation MUST be encoded if
language and character set information are given.
(5) If the first segment of a continued parameter value is
encoded the language and character set field delimiters
MUST be present even when the fields are left blank.
Trying to get an example.
Will likely need changes in ExtractHeadersAndRawBody
.
The affected customer provided an export of the .EML through the webmail client of Kopana. This was not RFC 2231 and would work fine.
However, the extension got a RFC 2231 version. Most important bit is that the attachment data was actually missing. Filename and MIME type were present, and we would have been able to handle this.
The headers rely on php-imap's native IMAP methods.
Did not investigate further whether this is an issue with php-imap, the Linux VM (Devuan) or the mail server (older Kopana version) as the user is planning to switch to a different mail server soon anyway.
The .EML contents looked like this:
<the typical email headers>
This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_ZG_static
Content-Type: multipart/alternative; boundary="=_ZG_static_0"
--=_ZG_static_0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Hallo ...
--=_ZG_static_0--
--=_ZG_static
Content-Type: application/pdf; name=filename.pdf;
name*0*=iso-8859-1''first URL encoded part (of filename.pdf);
name*1*=second URL encoded part
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=filename.pdf;
filename*0*=iso-8859-1''first URL encoded part (of filename.pdf);
filename*1*=second URL encoded part
--=_ZG_static--