Feature: Basic support for RFC 2231

[jbostoen]

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.

RFC 2231 - MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations (ietf.org)

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.

[jbostoen]

Trying to get an example. Will likely need changes in ExtractHeadersAndRawBody .

[jbostoen]

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.

[jbostoen]

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--