My SMTP server is being probed. It looks like a brute force attach on SASL, where they're going through a password dictionary.

Having seen thousands of these lines in the log files

Sep 18 14:09:52 xxx postfix/smtpd[7412]: connect from ca255.calcit.fastwebserver.de[]
Sep 18 14:09:55 xxx postfix/smtpd[7412]: warning: ca255.calcit.fastwebserver.de[]: SASL LOGIN authentication failed: authentication failure
Sep 18 14:09:55 xxx postfix/smtpd[7412]: lost connection after AUTH from ca255.calcit.fastwebserver.de[]
Sep 18 14:09:55 xxx postfix/smtpd[7412]: disconnect from ca255.calcit.fastwebserver.de[]

I modified my main.cf like this:

inet_interfaces = all
smtpd_helo_required = yes
smtpd_sender_restrictions = reject_unknown_address

smtpd_client_restrictions =  check_client_access hash:/etc/postfix/maps/access_client,

smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/maps/access_client,
                               reject_rbl_client zen.spamhaus.org,
                               reject_rbl_client list.dsbl.org

broken_sasl_auth_clients = yes

And my /etc/postfix/maps/access_client only has this line: REJECT

However after restarting postfix there is still no change in behaviour, I still see the same error, so SASL is still being checked, even though I thought with these settings the client would be rejected based on its IP address before SASL even comes into the game ?

A 2nd question is - I am relaying outgoing mail traffic from one machine to another on the internal network - apart from the 'relayhost' setting on the machine that just relays, can I keep the rest of the postfix settings the same on both ?


Postfix doesn't evaluate the smtpd_client_restrictions until the RCPT TO (or ETRN) command is sent.


Current Postfix versions postpone the evaluation of client, helo and sender restriction lists until the RCPT TO or ETRN command. This behavior is controlled by the smtpd_delay_reject parameter. Restriction lists are still evaluated in the proper order of (client, helo, etrn) or (client, helo, sender, relay, recipient, data, or end-of-data) restrictions. When a restriction list (example: client) evaluates to REJECT or DEFER the restriction lists that follow (example: helo, sender, etc.) are skipped.

Thus you can get around this by setting the following in your main.cf:

smtpd_delay_reject = no


As for your second question, there are so many controls for postfix, this is near impossible to answer without having complete details of your network, postfix configuration, and client configuration. Best way is to just try it.

| improve this answer | |
  • Good pointer which is missed in many howtos. I was about to use that – until I've read the entire section behind the link. Make sure to check the bullet-points at its end for side effects. // I wish there were a way e.g. the SASL AUTH could be "faked" in such cases, so the client is rejected at the proper place (with the proper information gathered) without being given the possibility of "brute-forcing SASL" – and without the other trade-offs mentioned. – Izzy Aug 11 '17 at 18:39

If you want to disable SASL AUTH for specific IPs or IP ranges without the side-effects of smtpd_delay_reject = no, take a look at the smtpd_discard_ehlo_keyword_address_maps keyword. Example configuration and explanation:


First, we set up the keyword in /etc/postfix/main.cf:

smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/esmtp_cidr

Now we define our blacklist in /etc/postfix/esmtp_cidr (the file we just specified):

# /etc/postfix/esmtp_cidr  auth   auth    auth

As this is a cidr: list file, no postmap run is required. But we need to tell Postfix to reload its configuration:

service postfix reload


Now, what does that mean? For the addresses specified (either full IP or an IP range in this example), we told Postfix to disable a specific ESMTP feature: AUTH. This means, the hosts covered no longer can use SASL. Let's check the log:

Aug 11 22:37:39 xxx postfix/smtpd[32630]: connect from unknown[]
Aug 11 22:37:39 xxx postfix/smtpd[32630]: discarding EHLO keywords: AUTH
Aug 11 22:37:39 xxx postfix/smtpd[32630]: lost connection after AUTH from unknown[]
Aug 11 22:37:39 xxx postfix/smtpd[32630]: disconnect from unknown[]

So we got what we want, without having to use smtpd_delay_reject = no, and thus don't need to fear the side-effects of the latter.

Note: the very same way you can forbid clients to use other ESMTP features, such as pipelining or starttls. A list of available keywords can e.g. be found in this Wikipedia article. Other than with smtpd_sasl_exceptions_networks, those keywords will not only not be announced, but they won't be accepted at all – as the log shows.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.