Disabling RBL for auth users

1

I can understand using RBLs for inbound mail, but it’s causing enormous problems for many of my users because it also blocks outbound mail sent by authenticated users, which seems completely nonsensical. I have removed all traces of spamhaus and rbls from my postfix config (which seems like a silly thing to have to do to fix this), but senders are still being rejected like this:

Client host [x.x.x.x] blocked using zen.spamhaus.org; https://www.spamhaus.org/sbl/query/SBLCSS

How can I disable this?

2

That should not be happening. Mail-in-a-Box skips Spamhaus IP-based filtering for authenticated users via:

smtpd_recipient_restrictions=permit_sasl_authenticated(...reject_rbl_client)

i.e. permit_sasl_authenticated comes first and causes the remaining restrictions to be skipped.

The only reason you should be seeing this problem is if you changed the configuration.

3

Until this issue I’m not aware of having touched these settings (other than removing the RBL part). It’s currently set to:

smtpd_sender_restrictions=reject_non_fqdn_sender,reject_unknown_sender_domain,reject_authenticated_sender_login_mismatch
smtpd_recipient_restrictions=permit_sasl_authenticated,permit_mynetworks,reject_unlisted_recipient,check_policy_service inet:127.0.0.1:10023

whereas the original is:

smtpd_sender_restrictions="reject_non_fqdn_sender,reject_unknown_sender_domain,reject_authenticated_sender_login_mismatch,reject_rhsbl_sender dbl.spamhaus.org" \
smtpd_recipient_restrictions=permit_sasl_authenticated,permit_mynetworks,"reject_rbl_client zen.spamhaus.org",reject_unlisted_recipient,"check_policy_service inet:127.0.0.1:10023"

There are some other differences, so I’ve restored this original config and will see how it goes.

I’m confused by the naming though - I would have expected the “sender” restrictions to apply to outbound, and the “recipient” ones to apply to inbound, but it looks like it’s the reverse, because there is no auth permission for the “sender” restrictions. Is that right?

4

Whenever I’ve decided to go out on my own and configure postfix, I’ve only been successful after spending a couple of hours reviewing Postfix official documents (i.e., not some blog some place or any place), as I have determined that changing one thing usually changes other things, and there is separately some different configuration to deal with those other things.

5

Eep, well it looks like doing that was a mistake… I’m immediately deluged with error messages complaining that this config is broken, and everything is rejected, saying:

NOQUEUE: reject: RCPT from unknown[x.x.x.x]: 451 4.3.5 Server configuration error;

apparently because:

unknown smtpd restriction: ""reject_non_fqdn_sender"

so it looks like postfix doesn’t like the double quotes around those things. I got these lines from here. I see that this isn’t a config file itself, but a script that alters a config file - so I guess it may not result in the same values. I’ve removed all the quotes and it’s no longer complaining, but I can’t test the original problem from where I am because I’m not on the blacklists.

6

As I recall, both sets of restrictions are applied to all connections. The difference is nominally at what point in the connection the restriction is applied, although reading the docs again I think they’re all applied at the same time.

7

Having reverted to the default config, I’m still having the same problem. It’s even failing to allow sending from one local user to another. In the logs I can see that it’s also rejecting real sources of spam, as it should, but it’s also blocking authenticated users. How can I turn off the spamhaus check altogether?

8

What happens when you run sudo mailinabox? That should set everything on the server to default.

9

I’ve done that, I can see that it has reverted to defaults in main.cf, but the same users are still unable to send mail.

10

I’ve done some more experiments with this. It seems that it may be a problem with Apple Mail on a brand new MacBook Air M1. I can see (from both ends) that it attempts to connect over TLS, but just hangs on the initial connection, it doesn’t even get as far as showing a welcome banner. Oddly, using openssl s_client from the same machine connects just fine using both SMTPS on port 465 and SMTP+STARTTLS on 587, though I noticed that it selected a ChaCha20-Poly1305 cipher suite even though that is listed relatively late in the cipher suite list. Is that perhaps selected because M1 doesn’t have hardware acceleration of AES? What was then happening is that it was attempting to send despite the authentication failing, and so the rejection due to spamhaus is then understandable.

More weirdly, another MacBook air M1 using the same OS and IP has no problem at all.

Any other ideas what might be going on here?