Debian – spamassassin has false-positives with emails originating from dialup addresses

debianeximsa-eximspamspamassassin

I'm mostly a happy admin of spamassassin (3.4.0-6) + exim4 (4.84.2), setup for server-side spam-filtering on a Debian/jessie system.

Recently a user reported some false positives.
On closer inspection it turns out, that the legit emails were

  1. sent from some dialup IP address (which gets listed in multiple blacklists)
  2. passed on to the mail-server of the sender's ISP (using whatever authentication they had in place), which
  3. then delivered the email to my mail server
  4. which flagged the mail as SPAM because one of the IPs in the "Received" headers was blacklisted

spamassassin matched a handful of blacklist rules (RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_SBL_CSS, RCVD_IN_SORBS_SPAM, RCVD_IN_SORBS_WEB).
Note that the email only got positive scores due to the IP being blacklisted.

The relevant header in the email that triggered the SPAM flagging is:

Received: from [10.126.95.175] (unknown [109.126.64.1])
    by smtpfilter1.public.one.com (Halon) with ESMTPSA
    id ee1f1e82-251c-11e7-8f0e-b8ca3afa9d73;
    Wed, 19 Apr 2017 16:26:25 +0000 (UTC)

now given that:

  • the mail server(s) of the sender's ISP are all clean (seemingly not listed in any blacklist)

  • I obviously don't know how the sender proves their email legit to their ISP, but I assume that some form of authentication does take place

… I think that spamassassin should not have flagged that email as spam.

To be precise: my gut feeling tells me that spamassassin should properly add SPAM score for mails directly received from blacklisted IP addresses. However, if the mail went through a "clean" MTA (the ISP's mail servers), sa should assume that "they" (the ISP) has taken proper measures to ensure the legitimacy of the email.

Since I'm running my setup for quite some time and haven't had many false positive reports until now, I wonder:

  • Is the above expected behaviour?

  • If not, is the problem on my side (e.g. i misconfigured my spam analysis to take parts of the received-chain into account which it shouldn't. if so, where should i look for a fix?)

  • If not, is the problem on the ISPs side? (e.g. they should better conceal the broken IP addresses from which they accepted authorized emails. if so, should i direct complaints to them?)

Best Answer

These SpamAssassin rules matches if A relay in the message's Received headers was listed...

While RCVD_IN_SORBS_WEB works closer to what you'd like them all to do:

check tests the IP address of the last untrusted relay against the DNSBL maintained by SORBS.

If you don't trust in these tests, you can always adjust rule scores. score RCVD_IN_BL_SPAMCOP_NET 0 doesn't add any score if the test matches, resulting that the test will be completely disabled.

There's no need for Spamassassin to test against only the latest Received: header as this is the Received from your own MTA that could have done the same test and actually rejected the mail from matching IP address instead of marking it as SPAM.

In Postfix main.cf the equivalent recipient restrictions would be:

smtpd_recipient_restrictions =

    reject_rbl_client sbl.spamhaus.org,
    reject_rbl_client bl.spamcop.net,
    reject_rbl_client dnsbl.sorbs.net

And with Exim 4.x in acl_rcpt ACL in the exim.conf:

deny     message  =  Access denied - $sender_host_address\
                     listed by $dnslist_domain\n$dnslist_text
         dnslists =  sbl.spamhaus.org : \
                     bl.spamcop.net : \
                     dnsbl.sorbs.net

If you use Exim dnslists in warn mode, you could simulate RCVD_IN_* style rules on only the last MTA delivery by adding X-blacklisted-at header

warn     message  =  X-blacklisted-at: $dnslist_domain
         dnslists =  sbl.spamhaus.org : \
                     bl.spamcop.net : \
                     dnsbl.sorbs.net

and then scoring the existence (or content of) that header in Spamassassin instead of RCVD_IN_*:

header LAST_RCVD_BLACKLISTED exists:X-blacklisted-at
score LAST_RCVD_BLACKLISTED 10.0

Please notice that these reject lists might be too wide for what you actually need as for example the dnsbl.sorbs.net is a aggregate zone containing almost all SORBS zones available. Before rejecting or even flagging based on these list you should familiarize yourself with the purpose of each list and decide how aggressive you want to be.

Personally I'd trust SPF, DMARC and Bayesian filtering more and would be really sensitive in trusting DNSBLs, i.e. only using lists with IPs certainly only used for spam, like smtp.dnsbl.sorbs.net for open SMTP relay servers or edrop.spamhaus.org containing "hijacked" netblocks.

Related Topic