Malformed email cannot be parsed correctly

[GoogleCodeExporter]

The attached email contains an extra erroneous MIME part whose boundary that 
not actually being used in the body data, causing TIdMessage's parser to 
generate the wrong TIdMessageParts content.  If the following 3 lines are 
removed, the entire email can be parsed correctly:

--=_MoreStuf_2altzzz1234sadvnqw3nerasdf
Content-Type: multipart/alternative; boundary="--ALT--rHC3OhLW1291024574"
Content-Transfer-Encoding: quoted-printable

A workaround would be to detect when the terminating 
"--=_MoreStuf_2altzzz1234sadvnqw3nerasdf--" appears before 
"--ALT--rHC3OhLW1291024574" boundary begins/ends, possibly discarding it, so 
the parser can recover.

Original issue reported on code.google.com by gambit47 on 4 Dec 2010 at 1:11

Attachments:

• malformed.zip

[GoogleCodeExporter]

Attached another example

Original comment by gambit47 on 7 Dec 2010 at 8:06

Attachments:

• malformed2.zip

[GoogleCodeExporter]

Parsing of this condition is covered by RFC 2046 Section 5.1.2:

5.1.2.  Handling Nested Messages and Multiparts

   The "message/rfc822" subtype defined in a subsequent section of this
   document has no terminating condition other than running out of data.
   Similarly, an improperly truncated "multipart" entity may not have
   any terminating boundary marker, and can turn up operationally due to
   mail system malfunctions.

   It is essential that such entities be handled correctly when they are
   themselves imbedded inside of another "multipart" structure.  MIME
   implementations are therefore required to recognize outer level
   boundary markers at ANY level of inner nesting.  It is not sufficient
   to only check for the next expected marker or other terminating
   condition.

Original comment by gambit47 on 8 Dec 2010 at 7:25

[GoogleCodeExporter]

Original comment by gambit47 on 12 Dec 2012 at 9:08

• Changed state: Started