Run the email through "spamassassin -D received-header". That'll tell you how and if the headers got parsed. SA has certainly had bugs where it failed to parse received headers before, and IPv6 hasn't had a whole lot of use.
There has also been a fair amount of work on IPv6 since the last release, so it's possible there was a bug, it got fixed, and you don't have the fix yet. On 10/02, Mabry Tyson wrote: > 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. > 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). That should result in a received header clearly indicating that the connection from comcast was authenticated, and SA should notice that and use it to skip the tests on that comcast IP. It mostly sounds like this is what's missing. SRI.com not indicating the authentication in their received header in the standard way. > 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. So it said RDNS_NONE for the comcast IP? Did it have a reverse DNS entry? (Also seems like it should be solved by a received header indicating authentication.) > 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. I'm not too familiar with these, but my guess is, private IPs should be skipped, and IPs before those should still be parsed / tested. > 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. "x-originating-ip: [AA.BB.CC.DD]" appears to be treated effectively the same as a received header. So that seems like a good reason for ALL_TRUSTED to not have fired. > 4. > [3]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. Do not attempt to comprehend the depths of the mind of the re-scorer :P No seriously, it has no concept of "this rule means the email is more bad than another rule, therefore it should have a higher score". Only "This score results in a better approximation of the 1 false positive in 2,500 non-spams goal". Which often results in unexpected things. It comes up a lot. I very recently found a case where a rule that hit more non-spam than spam got a score of something like 3. Which may have been suboptimal. > 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 > > [5]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. Should be handled by headers indicating authentication. -- Immorality: "The morality of those who are having a better time" - Henry Louis Mencken http://www.ChaosReigns.com
