Toni, > recently, my spamassassin started to score system messages as spam, > mentioning IP numbers not in the email: > [...] > * 2.0 CHECK_SPAMHAUS_ZEN RBL: SPAMHAUS_ZEN: IP is listed in Spamhaus' > * ZEN list > * [91.0.104.164 listed in zen.spamhaus.org] > * 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address > * [91.0.104.164 listed in dnsbl.sorbs.net] > > The report prominently mentions the IP number 91.0.104.164, which has > absolutely nothing to do with us, and likewise, the server w1.oeko.net > does actually have an A record. This is SpamAssassin 3.3.1 on > Debian/Squeeze, run from amavisd-new. > > Am I looking at a bug in SA? And/Or, how do I debug this, please?
Which version of amavisd? If older than 2.7.0, perhaps results caching was the culprit - assuming the mail body was exactly the same as of some previous unrelated message, but with a different mail header section. Try disabling it: $enable_global_cache = 0; Starting with 2.7.0 the results caching is no longer in use. > I do see this IP number several times, but it tried to send a completely > different email to someone else on my server. It does sound similar to Bug 6617 in a way that it might reflect events from some past message. But I agree it is not the same bug. Kevin wrote: | I'm guessing something in Amavis synthesizing a received header and | putting the wrong IP is more my guess. SA isn't going to make up an IP | address to go check. The only synthesized header fields by amavisd are Return-Path, X-Envelope-To, and some X-Amavis-* (none of which contain an IP address). The Received header fields as seen by SpamAssassin are only those generated by MTA - the Received header field generated by amavisd is only inserted as a last step during mail forwarding, after all checks have already been done. Did you check the message itself? Could it be the IP address in question comes from some URL in a mail body? > I was rather thinking along some memory corruption associated with > threads (SA runs as a module in amavisd-new), but that would be well > beyond my debugging skills, unfortunately. No threads are in use. A crosstalk can potentially come from messages previously checked by the same child process, or from borked DNS packets. > tests=[... DKIM_ADSP_NXDOMAIN... NO_DNS_FOR_FROM > The server w1.oeko.net does actually have an A record. Unless this is indeed a result for caching, these two SA tests, along with the made-up 91.0.104.164, might point a finger to a DNS issue. Are you using a local recursive DNS server or some foreign service? Any NAT or a small-office firewall involved? Mark
