Hi, there. Several multipart emails, typically hand-written/spam, have broken syntax FWICS according to the MIME standard. In particular, the boundary delimiter is often seen following immediately in the body part of a message, with no leading CRLF:
--------8<------------------- ... ... <headers> Content-Type: multipart/mixed; boundary="magic" Subject: Hello --magic ---------8<------------------ The funniest case was a recent IETF draft; the message is here: http://news.gmane.org/gmane.ietf.dnsext If someone can track down the full headers, they will see the same encoding error there. So it's not just spam, but most often hand-written emails. In rfc2046, the multipart delimiter is defined as delimiter := CRLF dash-boundary dash-boundary := "--" boundary In rfc1341, this was made even more explicit, 7.2.1: Note that the encapsulation boundary must occur at the beginning of a line, i.e., following a CRLF, and that that initial CRLF is considered to be part of the encapsulation boundary rather than part of the preceding part. The boundary must be followed immediately either by another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part (and it is therefore assumed to be of Content-Type text/plain). (...) The requirement that the encapsulation boundary begins with a CRLF implies that the body of a multipart entity must itself begin with a CRLF before the first encapsulation line -- that is, if the "preamble" area is not used, the entity headers must be followed by TWO CRLFs. To me, it's obvious that the observed behavior is broken. How should an IMAP server behave when reading such messages? Binc IMAP will not interpret the first boundary as a boundary, but will skip to the next part, as it does in general not have workarounds for broken content. But what do your servers do? Andy -- Andreas Aardal Hanssen http://www.bincimap.org/ -- ----------------------------------------------------------------- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -----------------------------------------------------------------
