http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5393
------- Additional Comments From [EMAIL PROTECTED] 2007-03-29 10:03 ------- (In reply to comment #8) > > Well, readers like Mutt (which I use) don't break MIME. You just look at the > text parts, not HTML or anything else. mailx and anything else that's not a > MIME-compliant reader will obviously show you everything. > > In as far as spammers are concerned, they're not targeting mailx users. Please read all of my message. > > I'd rate my confidence that this was intentional filter evasion at about > > 80% > > with a real chance that it was an "OOPS!" (the HTML was clearly built by > > hand > > by an amateur) but even so, it seems prudent to look in the epilogue. What > > could > > it hurt? > > Well, asking for us to stop being MIME compliant because we can is a little > ridiculous imo. :) I think your reasoning here is silly, since SA is not a MUA. There is spam being sent which is putting payload in the MIME epilogue. That alone ought to be a useful thing to detect, and HTML in the MIME epilogue even more useful, as well as detailed features of that payload that would already be detectable with SA except for the fact that SA totally ignores the epilogue. By your reasoning, one could support having SA ignore anything inside invalid HTML or completely passing on the analysis of mail with improper RFC822 format. SA already quite usefully identifies a variety of technical flaws as such and does not generally exempt the content of broken structures from filtering. >If common MIME-compliant MUAs display the preamble or the > epilogue (very obviously incorrect), then we may have to do the same, and also > should get people yell at the vendor about it. If they don't, then we > arguably > shouldn't either. I have confirmation from the original user who reported the spam to me that Outlook 97 displays the epilogue payload. Outlook 2003SP2 does not. Versamail does. Any MIME-ignorant MUA does. Which does not mean I think your rationale makes sense. > An obvious issue is that it potentially gives us a lot more data to process, > and > gives spammers a way of specifically trying to clog anti-spam tools. There's > already the issue of text/plain parts with garbage and a text/html part with > the > actual payload. It's hard enough trying to determine that the text/plain part > is garbage, let alone try to figure out whether or not all the data in the > epilogue should be ignored. Yeah, spam sucks. I think that's something we can agree on completely. Having a filter act like a piece of some spam simply doesn't exist because it is supposed to be ignored by MUA's that adhere to a standard seems like a novel variation on the idea that some spam is not spam because of its content. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
