One user complained about a false positive. When I examined the mail,
there appeared to be at least two rules that didn't work as I thought
they should because of a Received line in which IPv6 Link Local
addresses were used. It appears that a patch was previously put in
that was thought to fix these kinds of things.
SpamAssassin 3.3.2 (2011-06-06)
The (obfuscated) Received headers are
Received: from XXX.ai.sri.com (XXX.AI.SRI.COM [130.107.XX.YY])
by AI.SRI.COM ...
for xx...@ai.sri.com; Mon, 1 Oct 2012 09:54:18 -0700 (PDT)
Received: from AAA.sri.com (AAA.SRI.COM [128.18.XX.YY])
by XXX.ai.sri.com ...; Mon, 1 Oct 2012 06:49:40 -0700 (PDT)
X-AuditID: ....
Received: from BBB.SRI.COM (BBB.SRI.COM[128.18.YY.ZZ])
...
by AAA.sri.com ...; Mon, 1 Oct 2012 09:54:18 -0700 (PDT)
Received: from CCC.SRI.COM ([fe80::123:4567:89ab:cdef]) by
BBB.SRI.COM ([fe80::1234:5678:90ab:cdef%12]) ...
...; Mon, 1 Oct 2012 09:54:14 -0700
Other headers include:
x-originating-ip: [AA.BB.CC.DD]
The scoring was
Content analysis details: (4.9 points, 5.0 required)
pts rule name description
---- ----------------------
--------------------------------------------------
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
[AA.BB.CC.DD listed in dnsbl.sorbs.net]
1.3 RCVD_IN_RP_RNBL RBL: Relay in RNBL,
https://senderscore.org/blacklistlookup/
[AA.BB.CC.DD listed in
bl.score.senderscore.com]
3.6 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
[AA.BB.CC.DD listed in zen.spamhaus.org]
0.0 HTML_MESSAGE BODY: HTML included in message
0.1 RDNS_NONE Delivered to internal network by a host
with no rDNS
The sender was apparently using AA.BB.CC.DD (a Comcast address,
presumably his home address).
He logged into the mail system of SRI.COM (independent of our mail
system) and
sent his mail from within it (which is why CCC.SRI.COM is the oldest
Received line).
1. I believe that RDNS_NONE should not have fired. At the time of
processing, the
internal networks included 130.107/16 and 128.18/16, and cover the top 3
Receiveds.
The earliest received shows a Link Local IPv6 address, which should
match IP_PRIVATE in Constants.pm.
All of the IPv4 addresses have reverse DNS, including the x-originating-ip.
2. I believe that ALL_TRUSTED should have fired. The trusted networks
included 130.107/16 and
128.18/16. The Link Local IPv6 address should not have affected that.
Apparently the patch for bug 4964 did not fix this, and not the
ALL_TRUSTED problem in bug 4503, as claimed.
I presume the problem is due to the IPv6 addresses. I also
(subsequently) added
fe80:/10
to the trusted and internal networks, but that didn't change things.
Am I missing something, or should I file this as a bug report?
Other things of note:
3. At the time the message was sent, RDNS_NONE was scored as 1.3.
I manually changed its score to 0.1 after seeing this problem, until it
is fixed.
This gets the score below 5.0.
4.
http://spamassassin.apache.org/tests_3_3_x.html has
RCVD_IN_PBL = 3.6 (Spamhaus Policy black list)
RCVD_IN_SBL = 2.6 (Spamhaus Spam black list)
RCVD_IN_XBL = 0.7 (Spamhaus Botnet black list)
which seems backward to me. The 3.2 tests scoring seems more reasonable.
http://spamassassin.apache.org/tests_3_2_x.html has
RCVD_IN_PBL = 0.5
RCVD_IN_SBL = 2.8
RCVD_IN_XBL = 2.9
The Policy Black List applies to anyone using Comcast (this /14, and
similarly for the /12
that includes my home IP address) as their ISP, unless they opt out
http://www.spamhaus.org/pbl/query/PBL1523209
To hit all of the users that use that mail system with a 3.6 score is
surely going to cause a number of false positives.
5. This recipient got no benefit from Bayesian scoring. Another
recipient did get benefit.
It turns out this recipient's mail has had most of the spam stripped out
before the mail gets
to our server. So there were too few spam messages for the Bayesian
scoring to be triggered.
