[Mailman-Developers] Mal Formed MIME post leakedthrough to list

[Barry Warsaw]

On Sat, 2005-09-17 at 12:12, Mark Sapiro wrote:

> I confirmed that the post e-mail was clearly wrong. RFC2046 states "The
> boundary delimiter MUST NOT appear inside any of the encapsulated
> parts, on a line by itself or as the prefix of any line." That
> notwithstanding, I think the parser and Mailman should protect against
> this kind of error.

The email 3.0 parser will be much more robust against these types of
problems, but the best you can hope for is to take the defects into
account when deciding what to do with the message.  For example, I don't
think it's unreasonable for Mailman to discard (or at least hold)
messages with defects.  IME, 99.99% of malformed messages are malware.

> I looked a bit at the documentation of the email library and based on
> that, I think what may have happened is when the parser saw the first
> "end of subpart boundary" which looked the same as the outer "end of
> part boundary", it took it as the end of the outer part and treated
> the rest as an epilogue. Hold.py does the following to compute message
> size:
> 
>     if mlist.max_message_size > 0:
>         bodylen = 0
>         for line in email.Iterators.body_line_iterator(msg):
>             bodylen += len(line)
> 
> but the body_line_iterator() method may skip the epilogue.

Yep.  In private email, Mark pointed us to a patch for Hold.py which
takes preambles and epilogues into account when calculating messages
sizes.  This has been applied to the 2.1 maintenance branch and the 2.2
trunk.

> Also, I think MimeDel.py will leave the epilogue in the message.

I think that's generally appropriate (though I'm open to opinions while
we're still on email 2.5).  If we start discarding malformed messages,
it probably makes sense to keep them, since it won't be possible to hide
content there.

> Interestingly, both Thunderbird 1.5b1 and MS Outlook Express 6 seem to
> parse the message as intended, but Mutt 1.4.1i sees it more like
> Mailman does.

Really, ultimately, it's up to the semantics of Python's email library. 
Changing that is not easy. ;)

Thanks!
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050918/34c4cde6/attachment.pgp