I seem to be having a problem that defies SA logic, so there must be another variable I’m not aware of. A message comes through our network for Undisclosed Recipients. Here are the related headers:
>X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on eq-gw2.ly.net >X-Spam-Level: *************** >X-Spam-Status: Yes, score=15.3 required=3.8 tests=INVALID_MSGID, > MISSING_SUBJECT,NO_REAL_NAME,RCVD_HELO_IP_MISMATCH,RCVD_IN_DSBL, > RCVD_IN_XBL,RCVD_NUMERIC_HELO,SARE_MSGID_SHORT,UNDISC_RECIPS > autolearn=disabled version=3.0.0
<snip>
I’m getting a lot of these. If the message was scored 15.3 out of 3.8 – why was the subject not modified so that our next server could stop it and put it in the spam queue? As you can see I’m running SA 3.0 called by Postfix 2.
It's not tagged because there's no subject header to be tagged. This is a bug in SA 3.0.0 and 3.0.1, but was fixed in SA 3.0.2.
http://bugzilla.spamassassin.org/show_bug.cgi?id=3816
From the 3.0.2 release announcement:
SpamAssassin 3.0.2 is released! 3.0.2 contains some important bugfixes, and is recommended.
Highlights:
- Detect legitimate SMTP AUTH submission, to avoid false positives on Dynablock-style rules - Fix URIDNSBL plugin to honor uridnsbl_max_domains config option - Various documentation and rule fixes - Deal with 'rewrite_header Subject' markup when no Subject header exists - Fix 'make test' failure on Solaris