Hi, If I've read this correctly, this issue...
> 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<------------------ [snip rfc1341 reference] > 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? ...sounds like the same issue I raised on the ietf-smtp list (wrong list, should have been ietf-822) in the thread: http://article.gmane.org/gmane.ietf.smtp/2716 The upshot of that was Those That Know (e.g. Ned Freed) pointed out that only a single CRLF was needed after the message headers, as the ABNF details: multipart-body := [preamble CRLF] dash-boundary transport-padding CRLF body-part *encapsulation close-delimiter transport-padding [CRLF epilogue] where the 'dash-boundary' definition doesn't include the leading CRLF. i.e. the above *is* valid MIME per RFC2046 (but isn't according to earlier standards). So the message should be parsed and stored, with an empty 'preamble'. In IMAP terms, I guess the TEXT starts at the first '-'. Hope that helps. regards, jb
