On Mon, 28 Mar 2011, Daniel McDonald wrote:
I just got a spam that scored relatively low (mostly due to DNSWL_MED). But
it also contained an html attachment that would have scored significantly
more had it been part of the main message.
I put it at http://pastebin.com/vXF0vGVS
When I run the complete message, I only get a few hits, mostly relating to
the headers:
X-Spam-Status: Yes, score=5.534 tagged_above=-99 required=4.5
tests=[BOTNET_SOHO=-0.1, DEAR_FRIEND=2.604, FORGED_MUA_OUTLOOK=2.785,
L_P0F_Linux=1, NSL_RCVD_FROM_USER=1.226, RCVD_IN_DNSWL_MED=-2.3,
RCVD_IN_LBBL_RELAY=0.3, RELAY_US=0.01, SPF_PASS=-0.001,
T_OBFU_HTML_ATTACH=0.01] autolearn=disabled
When I run just the attachment through spamassassin, I get the usual
advanced fee hits (and the ³no headers² hits, since it isn¹t an email at
that point...):
X-Spam-Report:
[snip..]
problem with that critter is that "payload" attachment is mime-typed
"application/octet-stream" and by default the Spamassassin engine only
auto-magically parses attachments that it recognises as textural.
So SA just completely ignores that attachment, considers it binary.
That spam depends upon common MUAs doing the windows trick of keying
off the extension of the file name for type recognition.
(IE: filname="blah.htlm")
So do we modify SA to do as the devil does and assume that:
'Content-Type: application/octet-stream; name="Details.html"'
should be processed in the same way as the proper mime label:
'Content-Type: text/html; name="Details.html"'
A while back I tried creating some rules that explicitly looked for
messages with that perverted mime labeling but they FP'ed all over the
place as there are multiple ham sources that make the same faux-pas.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
