Blocking sender email addresses with Postfix

How to block sender e-mail addresses and domains in Postfix to effectively eliminate marketing spam.

2803 views
d

By. Jacob

Edited: 2023-11-22 19:17

Blocking individual senders with Postfix can be done by editing the /etc/postfix/sender_access file. If it does not exist, you can go ahead and create it.

1. Edit the file:

nano /etc/postfix/sender_access

2. Type in the sender address that you want to reject (one per line):

/some_user@example\.com/ REJECT

Note that I use a RegEx pattern, because then it will also catch from fields like this <[email protected]>. E.g:

some_user <[email protected]>

3. For this the PCRE extension needs to be enabled. On Debian/Ubuntu, you can install it by running:

sudo apt install postfix-pcre

Sometimes you may choose to block entire domains. E.g:

/@example\.com/ REJECT

4. Create a database file that postfix understands:

postmap sender_access

5. Edit /etc/postfix/main.cf and add the following:

smtpd_recipient_restrictions = check_sender_access pcre:/etc/postfix/sender_access

If you have multiple rules in this block, you should separate them with comma and optionally indent them with spaces for readability. E.g:

smtpd_recipient_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  check_sender_access pcre:/etc/postfix/sender_access,
  check_policy_service unix:private/policyd-spf

In fact, it seems even separating each rules with a line break works.

6. Restart postfix:

systemctl restart postfix

Things to watch out for

Be aware that once you have enabled the PCRE extension, you will seemingly need to use regular expressions even when blocking single domains. So, if you had used a hash map, you could have done this:

spammyhost.com REJECT

But when using PCRE you will instead need to do this:

/spammyhost\.com/ REJECT

Another issue is that regular expressions are very sensitive, so if you make a small mistake or typo, it might break your filtering completely. But, if this is the case, you will see errors in your mail.log when someone tries to send you e-mail. E.g:

... NOQUEUE: reject: RCPT from mail-qt1-f172.google.com[209.85.160.172]: 451 4.3.5 <[email protected]>: Sender address rejected: Server configuration error; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail-qt1-f172.google.com>

Remember to Test, test, test! Postfix's configuration is highly sensitive, and you need to be sure things are working properly – especially security- and filter settings.

What happens when an address is blocked?

Once the sender-address has been blocked properly, future e-mail from them will bounce, and they will get a message like this in their inbox telling them they are blocked:

554 5.7.1 <[email protected]>: Sender address rejected: Access denied

This should give an entry in your /var/log/mail.log file:

postfix/smtpd[5358]: NOQUEUE: reject: RCPT from mail.example.com[xxx.xxx.xxx.xxx]: 554 5.7.1 <[email protected]>: Sender address rejected: Access denied; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail.example.com>

You can easily check that email is rejected by using grep:

grep "[email protected]" /var/log/mail.log

When to block individual addresses

Personally, I rarely block individual senders, because there is absolutely no point in doing it if the message is indeed "malicious". E.g. Someone found your e-mail address online and started sending you advertisements, they are probably also hiding their real identity.

If the sender is not hiding behind anonymity, then sometimes I want to bounce their e-mail by hard-blocking them in my server configuration; for example, maybe they are a real sender that started sending me e-mail marketing spam without my consent, in which case I sometimes block them to show them that their spam is not welcome – hopefully some will get the message.

Blocking a specific sender is not exactly a trivial task when you manage your own e-mail server, because you have to SSH into your server and manually add the senders e-mail address to your blocklist, and if you use Postfix, then you also have to restart the server to apply your changes.

E-mail services hosted at Microsoft and Google might not even provide a real way to block senders, and to the average user the option would be sort of obsolete anyway, because people are not able to tell when it will actually be useful to hard-block a sender; the problem is that most spammers will be spoofing their e-mail addresses, or indeed, simply change their address to get around such silly little blocks.

However, some e-mails are obviously genuine and originating from senders that at least will comply with some laws on spamming; we can easily block those senders if we wish to signal our disapproval of the message, and that way we avoid having to click their unsubscribe link.

Hard blocking

If a block is setup correctly by your e-mail provider, the e-mail server should plainly reject the unwanted message, this is a "hard block", and it should result in a bounced e-mail message.

Soft blocking

Gmail, for example, does not seem offer an option to block e-mail originating from specific addresses; their block function is a "ghost" soft-block; a block does not actually block future messages from the sender, and they will not know that they have been blocked; instead it will just move future messages to your spam folder. In my opinion, Google has actually implemented blocking incorrectly and contrary to what we would intuitively expect a block to mean!

When users block an e-mail address, they intuitively expect e-mail originating from that address to be rejected entirely – it should not even enter the spam folder – to then find future e-mail in the spam folder is just a disappointment. But, it also highlights the ongoing need for decentralization of e-mail.

The spam folder should be reserved for messages that might have been incorrectly labeled as spam. E.g. The spam filter was not confident enough to completely reject the message, or the sending domain has not configured their DKIM or SPF correctly. Etc.

Sometimes it does not work, here is why

Some senders, perhaps predominantly e-mail marketing organisations, will mask the true sender and/or the domain name of their clients. E.g. Using random numbers and symbols: [email protected]. Services such as MailChimp is known to use a deceptive address like this as sender: bounce-mc.us4_12353543.11889934-012daddc2d@mail120.sea21.rsgsv.net, and Amazon SES might do something equally nasty – this practice is just misleading, so I think you should block these mail servers to teach their owners an important lesson.

There is no legitimate reason to hide the true sender of e-mails. Companies that use services such as MailChimp have to keep in mind that they may be hiding the sender address, which will immediately raise a red flag with the security conscious user – it is often a sign of attempted phishing! Please. I beg you; use an address on your own domain name as the sending address – and please avoid using fake addresses for tracking purposes. The user should ideally be able to reply directly to your sender address, and it should be a real e-mail address (not an automatically generated one).

The practice also makes it difficult to block individual senders, so instead we may have to block the entire mail-server, and all users of said server. E.g. rsgsv.net for MailChimp. This is not in my own interest, in MailChimp's interest, or even users interest. But will I block you for using this deceitful practice? You bet I will.

Security expert Troy Hunt has also warned against this practice. Read: When Bank Communication is Indistinguishable from Phishing Attacks.

As a user of e-mail I think the practice is super obnoxious. If your company is currently engaged in this behaviour, please stop it!

I repeat – there is no legitimate reason for this practice to exist and everyone should just block it. It is super confusing to users and a sign of phishing! As a mail administrator, I want to be able to look at the sender-address alone and be able to quickly deduce if the sending domain-name legitimately belongs to the company the e-mail claims to originate from.

Links

  1. smtpd_recipient_restrictions - postfix.org
  2. When Bank Communication is Indistinguishable from Phishing Attacks - troyhunt.com

Tell us what you think:

Anonymous

Unfortunately, this won't work. Did you even try it? This filters MAIL FROM sender command, not the From: header. If sender from differs, abd this pretty usual, e.g. Foo <[email protected]> it simply won't work if you try to block [email protected]
Regards.

Jacob

@Anonymous I can confirm that it works. I use it on my own Postfix server, and have successfully blocked numerous of spammers by using this method. However, you may need to enable the pcre extension and use regular expressions to block certain things. The article is now updated to better reflect this.

  1. How to link the ca-certificates in your Postfix configuration.
  2. We can find out if Postfix was hacked by reading the mail and syslog files, learn what to look for in this article.
  3. Configure Postfix to check SPF records and fight e-mail spoofing.
  4. How to use SPF records to increase the likelihood that your e-mails will be received and not go to spam.

More in: Postfix