I've found that some spammers are sending out mails (in this case multipart/alternative) with blank boundaries, in violation of the RFC. aka: Content-type: multipart/alternative; boundary=""
The RFC states that the boundary must be at least 1 char long. So the question comes up -- should we accept the blank boundary and parse as normal, or should we see it as invalid and treat the entire mime part as 'text/plain'? Of course, MUAs are no help here... Apple Mail happily takes the empty boundary and shows the text/html part Outlook Express shows the whole message as a single text/plain part mutt shows the whole message as a single text/plain part pine happily takes the empty boundary and shows the text/plain part Part of me says we should follow the RFC, and part of me says we can see what was meant so go ahead and do it (and let rules hit appropriately). Thoughts? FYI: At the moment, I've modified the 2.70 code to accept the empty boundary and parse as normal. It's extremely trivial to change the behavior to the single text/plain version though (comment out the current line, uncomment the one next to it ... ;) ) -- Randomly Generated Tagline: It's kind of like grandpa used to say: "People's opinions differ on many things. It's a good thing too, or everybody would be after grandma, and that would be a big problem." - Unknown
pgplvlgeGhkEF.pgp
Description: PGP signature
