Created attachment 970 [details]
This is an Outlook msg file, hopefully someone can convert or other wise make it usable in a *nix environment

Best way to show Outlook mails to non-outlooking folks is probably the 
following: right-click over the mail and select options from the bottom of the 
list, or double-click the mail to open it and select options from the View 
menu. You'll see the "Internet headers", and those along with the body ('view 
source' if it's html mail) should be enough... :-) I guess that leaves out 
jpeg/gif and other attachments, though.

Anyways, here with SA 2.54 the spam scored:

Content analysis details:   (22.10 points, 5 required)
X_MSMAIL_PRIORITY_HIGH (0.4 points)  Sent with 'X-Msmail-Priority' set to high
X_PRIORITY_HIGH    (1.9 points)  Sent with 'X-Priority' set to high
SMTPD_IN_RCVD      (0.6 points)  Received via SMTPD32 server (SMTPD32-n.n)
EXTRA_MPART_TYPE   (0.7 points)  Message with extraneous Content-type:...type= 
header
FROM_HAS_MIXED_NUMS (0.1 points)  From: contains numbers mixed in with letters
MARKETING_PARTNERS (2.1 points)  BODY: Claims you registered with some kind of 
partner
OPT_OUT            (0.5 points)  BODY: Talks about opting out (lowercase 
version)
BAYES_80           (2.9 points)  BODY: Bayesian classifier says spam 
probability is 80 to 90%
                   [score: 0.8722]
HTML_40_50         (0.7 points)  BODY: Message is 40% to 50% HTML
HTML_IMAGE_ONLY_06 (0.6 points)  BODY: HTML has images with 400-600 bytes of 
words
RCVD_IN_NJABL      (0.8 points)  RBL: Received via a relay in dnsbl.njabl.org
                   [RBL check: found 154.240.75.220.dnsbl.njabl.org., type: 
127.0.0.9]
RCVD_IN_OSIRUSOFT_COM (0.9 points)  RBL: Received via a relay in 
relays.osirusoft.com
                   [RBL check: found 154.240.75.220.relays.osirusoft.com., 
type: 127.0.0.9]
RCVD_IN_OPM        (4.3 points)  RBL: Received via a relay in opm.blitzed.org
                   [RBL check: found 154.240.75.220.opm.blitzed.org., type: 
127.1.0.4]
FORGED_MUA_OUTLOOK (2.2 points)  Forged mail pretending to be from MS Outlook
MIME_HTML_ONLY     (0.1 points)  Message only has text/html MIME parts
MISSING_MIMEOLE    (0.1 points)  Message has X-MSMail-Priority, but no X-MimeOLE
OBFUSCATING_COMMENT (3.2 points)  HTML comments which obfuscate text

And now to the real reason I wanted to reply: it seems all reserved netblocks 
are popular in the Received fakes/spoofs spammers use. Not just multicast 
addresses, but others as well. And using addresses that actually are used is 
also common... at least DoD networks seem to appear often :-)

Some firewall scripts drop stuff coming from blocks listed as reserved at 
http://www.iana.org/assignments/ipv4-address-space, but I'm not sure if that's 
a good idea for SA to somehow score based on that. Doesn't SA have some kind of 
Received forgery detection anyways.

I did quick statistics on how much spam includes spoofed IANA reserved 
addresesses by creating a local DNSBL. sorry for the small corpus, due to 
full hard drive I deleted all spam folders last week... 
 
OVERALL     SPAM      HAM     S/O   SCORE  NAME 
    622      210      412    0.338   0.00    0.00  (all messages) 
     14       14        0    1.000   0.00   1.00  RCVD_IN_IANA 
 
Later I noticed that these IP's are already listed in 
$IP_IN_RESERVED_RANGE , togetether  with RFC1918 and other special 
purpose addresses, which is not very usefull for scoring. There are 
RFC1918 valid reasons to have RFC1918 addressess in mail, unlike an 
IANA reserved or multicast address which are obvious forgery. 
 
spamassassin should split IP_IN_RESERVED_RANGE to 
IP_ILLEGAL_RANGE all the addressess that can be safely assumed to be 
forged on sight. 
IP_IN_NONPUBLIC_RANGE loopback, RFC1918 and similar legal but 
non-routable addressess, used for ignoring (like 
IP_IN_RESERVED_RANGE is used now) 
 
 
 
 
 
 
 

Subject: Re: [SAdev]  Multicast address in received should be scored


bugzilla-daemon@bugzilla.spamassassin.org wrote:

> http://bugzilla.spamassassin.org/show_bug.cgi?id=1923
> 
> ------- Additional Comments From nchip@kos.to  2003-09-18 04:20 -------
> I did quick statistics on how much spam includes spoofed IANA reserved 
> addresesses by creating a local DNSBL. sorry for the small corpus, due to 
> full hard drive I deleted all spam folders last week... 
>  
> OVERALL     SPAM      HAM     S/O   SCORE  NAME 
>     622      210      412    0.338   0.00    0.00  (all messages) 
>      14       14        0    1.000   0.00   1.00  RCVD_IN_IANA 
>  
> Later I noticed that these IP's are already listed in 
> $IP_IN_RESERVED_RANGE , togetether  with RFC1918 and other special 
> purpose addresses, which is not very usefull for scoring. There are 
> RFC1918 valid reasons to have RFC1918 addressess in mail, unlike an 
> IANA reserved or multicast address which are obvious forgery. 
>  
> spamassassin should split IP_IN_RESERVED_RANGE to 
> IP_ILLEGAL_RANGE all the addressess that can be safely assumed to be 
> forged on sight. 
> IP_IN_NONPUBLIC_RANGE loopback, RFC1918 and similar legal but 
> non-routable addressess, used for ignoring (like 
> IP_IN_RESERVED_RANGE is used now) 
>  

I highly agree. Although, perhaps it would just be simpler to remove the 
RFC1918 addresses from IP_ILLEGAL_RANGE?

In my own setup, for instance, My external SMTP gateway (which also 
virus scans using Amavis) passes inbound email to my main mailserver 
over a 10.x.x.x network. Similarily, my webmail server passes outbound 
email to the SMTP servers over the 10.x.x.x network.

Also worth mentioning is the need to periodically review IANA's 
allocation. As anyone using the IANA-RESERVED blocks at their edge 
routers (hopefully) knows, they're occasionally released (like 
69.0.0.0/8, which was reserved until Aug of 2002, and now includes SBC, 
among others).

--Rich

_________________________________________________________

Rich Puhek
ETN Systems Inc.
2125 1st Ave East
Hibbing MN 55746

tel:   218.262.1130
email: rpuhek@etnsystems.com
_________________________________________________________

ok, now in testing as T_RCVD_ILLEGAL_IP