On Mon, Aug 15, 2011 at 05:06:10PM -0700, John Hardin wrote: > On Mon, 15 Aug 2011, Michael Parker wrote: > > >On Aug 15, 2011, at 5:14 PM, [email protected] wrote: > > > >>https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6649 > >> > >>--- Comment #8 from Justin Mason <[email protected]> 2011-08-15 22:14:02 UTC > >>--- > >>it's a phish containing the following MIME headers: > >> > >>Content-Type: ; > >> name="UPS_document.zip" > >>Content-Transfer-Encoding: base64 > >>Content-Disposition: attachment; > >> filename="UPS_document.zip" > >> > >>and a phishing attachment which is then being interpreted as text. > > > >That's because it's missing a Content-Type and SpamAssassin is > >interpreting that as text/plain. Anyone have any thoughts on how > >to prevent that? > > Apart from trusting the filename extension? Examining the first few > bytes of the attachment for non-ASCII characters (excluding UTF > encoding markers) is the only thing that springs to mind. > > File::Type perhaps? Or is that overkill?
Sought can make easy assumptions, but if we want to "fix" SA, there are many gotchas. For example the problem with real text/plain binary attachments[1].. it would be nice to solve, but it's hard to come up with a "foolproof" binary detector. I think best thing to do is just to limit the problems any binary data might cause. We need to make sure rules and plugins don't crap out, some binary test cases would be nice.. [1] https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6582
