Postfix - Skip RBL checks after a SPF Pass

Question

I've started using policyd-spf and am using the following recipient restriction. What I'd like is for senders that pass the SPF check to skip any RBL checks. Unfortunately that's not happening.

  smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_sender,
    reject_non_fqdn_recipient,
    reject_unauth_destination,
    reject_unauth_pipelining,
    reject_invalid_hostname,
    check_policy_service unix:private/policy-spf
    check_sender_access mysql:/etc/postfix/mysql_sender_checks.cf
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net,
    reject_rbl_client cbl.abuseat.org,
    reject_rbl_client dnsbl.sorbs.net

Failed SPF checks are being correct, but as you can see from the syslog - policyd-spf is saying it's Passed but continues on with the RBL checks:

Mar 29 13:15:51 policyd-spf[6442]: Pass; identity=mailfrom; client-ip=69.171.232.144; helo=mx-out.facebook.com; envelope-from=REDACTED; receiver=REDACTED
Mar 29 13:15:51 postfix/smtpd[5971]: NOQUEUE: reject: RCPT from 69-171-232-144.outmail.facebook.com[69.171.232.144]: 554 5.7.1 Service unavailable; Client host [69.171.232.144] blocked using dnsbl.sorbs.net; Currently Sending Spam See: http://www.sorbs.net/lookup.shtml?69.171.232.144; from=<REDACTED> to=<REDACTED> proto=ESMTP helo=<mx-out.facebook.com>

Is anyone familiar with postfix-policyd-spf-python, and if so can you explain why it's not working as expected.

Using:

Debian GNU/Linux 7
Linux XXXXX 3.2.0-4-amd64 #1 SMP Debian 3.2.82-1 x86_64 GNU/Linux
Postfix 2.9.6-2
postfix-policyd-spf-python 1.0.2

I wouldn't recommend that. Spam senders can configure SPF too. — Gerald Schneider, Mar 29 '17 at 13:23
Why would you do that? Anyway, comment all the rows containing "reject_rbl_client" and it should not perform that check — Orphans, Mar 29 '17 at 13:27
@GeraldSchneider - That's a fair point, it's more that I expected a Pass not to continue down the list so I wasn't getting the result I expected. Orphans - My [possibly flawed] idea was to retain RBL checks, only of the SPF wasn't a pass. My problem is that more and more of our contacts are using Google Suite for their email and we're bouncing a lot of valid email. It was just an concept I wanted to investigate. — oobayly, Mar 29 '17 at 13:38
If one of your blacklists rejects valid emails, remove it. There are a lot of blacklists out there, some better than others. — Gerald Schneider, Mar 29 '17 at 13:39

Esa Jokinen · Accepted Answer · 2017-03-29T14:20:46.837

According to the logs, the message was rejected by list dnsbl.sorbs.net.

As described on Introduction from Using SORBS

As a prospective user of the SORBS lists the most important question you need to ask yourself is: Do I understand the listing criteria for the list(s) I plan to use?

Then, you have a number of choices/decisions to make:

How aggressive at stopping spam do you want to be?

Do you want to trust the SORBS admins as well as a testing script?

Do you trust the scripts the SORBS admins employ to identify badly configured hosts?

The list dnsbl.sorbs.net is an aggregate zone containing all the SORBS zones except spam.dnsbl.sorbs.net). That means your setup is highly aggressive at stopping spam, i.e. you will likely have false positives, like you already did.

While it is true that (from Postfix Configuration Parameters, smtpd_recipient_restrictions)

Restrictions are applied in the order as specified; the first restriction that matches wins.

the check_policy_service only causes sending a query to the specified policy server, not direct reject or permit. Then, your python-policyd-spf can return reject if PermError_reject = True, otherwise it will just adds Received-SPF header and processing restrictions continues.

You should read the Using SORBS for list of Zones Available. Then you can decide which zones best suits your needs and add them separately, e.g.

smtpd_recipient_restrictions =
    . . .
    reject_rbl_client relays.dnsbl.sorbs.net,
    reject_rbl_client web.dnsbl.sorbs.net,
    reject_rbl_client escalations.dnsbl.sorbs.net,
    reject_rbl_client block.dnsbl.sorbs.net,
    reject_rbl_client zombie.dnsbl.sorbs.net,
    reject_rbl_client dul.dnsbl.sorbs.net,
    reject_rbl_client noserver.dnsbl.sorbs.net,
    reject_rbl_client rhsbl.sorbs.net,
    . . .

or you could swap dnsbl.sorbs.net to less aggressive aggregate zone safe.dnsbl.sorbs.net.

_"the check_policy_service only causes sending a query to the specified policy server, not direct reject or permit."_ - Aha, that would be the source of my misunderstanding. Thanks. — oobayly, Mar 29 '17 at 14:27
If you are willing to trust the SPF enough, you can just configure `PermError_reject = True` and remove all the `reject_rbl_client`s and it should do the trick. — Esa Jokinen, Mar 29 '17 at 14:32
In light of other comments I'll probably have to rethink this concept. At least now I can start seeing how _reliable_ SPF is for our usage case and revisit if necessary. — oobayly, Mar 29 '17 at 14:38

Postfix - Skip RBL checks after a SPF Pass

1 Answers1