Top 7 effective tips for blocking email spam with Postfix on CentOS/RHEL

​What does email spam actually entail? How does it work? Why do you get so much spam?

In short, email spam is unsolicited email. A constantly overflowing personal inbox can be frustrating. Also, useless or fraudulent emails that belong to the spam concept can cost your business money in the long run.

Many tools can help you effectively deal with spam, including Postfix.

Postfix SMTP server on CentOS/RHEL allows blocking email spam before it gets to the inbox. 

Let's look at what spam is and how to stop it with Postfix on CentOS/RHEL.

​Understanding Spam

Email spam is basically unwanted email that the user receives on their email address. Unfortunately, email spam is not a new concept, as it has existed for a while now. There are billions of spam emails that users receive on a daily basis.

Email spam is often sent out to a big group of people using software that automatically generates and sends emails. However, email spam can be spent manually, too.

There are common types of email spam, including:

• Commercial emails. Such emails promote commercial products or services for a commission from the advertiser. Email spam may include links to sites with similar content or offers of goods and services not directly related to your interests.
• Viruses. Viruses are malicious programs that infect the operating system and steal personal information. Email viruses might contain malicious code to infect the system.
• Phishing emails. Phishing involves sending fraudulent emails designed to trick users into revealing their private or financial information so that scammers can use it for their purposes. Phishing emails usually include a link to another website.

Again, spammers often use automated programs (bots) to send thousands of emails at once, meaning that some emails may end up in your inbox even if you never signed up for newsletters or promotions.

Tip #1: Require PTR Records for SMTP Clients

PTR records, or Pointer Records, are reverse DNS records used for DNS lookup.

Domain Name System (DNS) is where the data of registered domains is stored. When you want to look at the registries, you perform a DNS lookup. Browsers usually do that when users input their email addresses, and through that, they get the IP address of a mail server. The result of such inquiry is usually an A record.

A reverse DNS lookup is when, the server gets the domain through an IP-address. The result of such an inquiry is a PTR record.

So why are PTR records vital? On the way to an email inbox, email travels through servers. In that process, email providers conduct the DNS and Reverse DNS lookups. If those do not match, an email is classified as spam. Therefore, email providers require that SMTP clients have the correct PTR records; it's usually the job of an SMTP server administrator.

Now, you can perform a Reverse DNS lookup yourself. For this, query the following command on CentOS/RHEL to get the domain name and IP address:

host <IP address>

Many mail servers have a requirement for valid PTR records matching the IP addresses. If the mentioned case is true, in the Postfix log (/var/log/maillog), there will be the following line if the SMTP client has PTR records:

connect from "hostname" [IP-address]

If the SMTP client's IP-address doesn't have PTR records, there will be "unknown" instead of a "hostname" in Postfix log.

You can filter emails that aren't associated with any PTR records through Postfix. For this, you need to open the Postfix config file with the following command:

sudo nano /etc/postfix/main.cf

Then, in the "smtpd_sender_restrictions" you have to add:

reject_unknown_reverse_client_hostname

Then you going to save and reboot Postfix for changes to apply:

sudo systemctl restart postfix

Tip #2: Implement HELO/EHLO Hostname Restrictions

EHLO procedure allows a client to introduce itself to the SMTP server. The HELO is very similar to EHLO but carries less data to the server.

So, sometimes, there's a non-existing domain name or a not fully functioning domain name provided in the SMTP dialog; this most likely indicates an email from spammers. You'll need to edit the Postfix config file to activate HELO/EHLO restrictions:

sudo nano /etc/postfix/main.cf

For the client to provide a hostname query, the following:

smtpd_helo_required = yes

To turn on restrictions, add:

smtpd_helo_restrictions = 
permit_mynetworks 
permit_sasl_authenticated

If you want to reject clients who provide an invalid hostname, use this command:

reject_invalid_helo_hostname

To reject an email with no records existing, use:

reject_unknown_helo_hostname

To sum up, all instances you can reject, it'll look something like this:

smtpd_helo_required = yes 
smtpd_helo_restrictions = 
permit_mynetworks 
permit_sasl_authenticated 
reject_invalid_helo_hostname 
reject_unknown_helo_hostname

Then save the file and reboot Postfix:

sudo systemctl reload Postfix

Sometimes, even legitimate mail servers may need to meet HELO/EHLO standards. To avoid errors with Postfix, you need to put those servers into a whitelist using:

check_helo_access hash:/etc/postfix/helo_access

Then create the /etc/postfix/helo_access file with:

sudo nano /etc/postfix/helo_access

The example of whitelisting can look like this:

optimus-webapi-prod-2.localdomain      OK
va-massmail-02.rakutenmarketing.com    OK

Once you have added the servers to the list, create the /etc/postfix/helo_access.db file:

sudo postmap /etc/postfix/helo_access

And then reload Postfix:

sudo systemctl reload Postfix

Tip #3: Verify A Records for SMTP Client Hostnames

Spam servers often don't have valid A records to their IP addresses. You can filter IP addresses with no A records out by editing the Postfix config file as in the previous examples.

Add the following commands to the "smtpd_sender_restrictions" section:

reject_unknown_reverse_client_hostname reject_unknown_client_hostname

Save the configuration file and reboot Postfix.

Remember that the two mentioned commands do not reject the fraudulent HELO/EHLO hostnames.

Tip #4: Reject Emails with Inadequate MX or A Records

MX stands for "Mail From" address, which also goes by the name of an "envelope from" address.

Sometimes, email spam is sent from non-existent domains in the Mail From address that doesn't have any records at all. If the sender's domain has no records, Postfix won't be able to send email to that domain, so you might as well reject it. 

To block this kind of email spam, you need to again edit the Postfix config file in a way similar to the one described in previous tips.

To reject email from the domain name from the address that has neither MX or A records, add the following to the "smtpd_sender_restrictions" section:

reject_unknown_sender_domain

It will reject the domain name of the address with no records. 

It can look like this:

smtpd_sender_restrictions = 
permit_mynetworks 
permit_sasl_authenticated 
reject_unknown_sender_domain 
reject_unknown_reverse_client_hostname 
reject_unknown_client_hostname

Then save the file and restart Postfix.

It's better to place the reject_unknown_sender_domain above all other "reject" commands to avoid issues.

Tip #5: Deploy Greylisting with Postfix

Greylisting is an email spam rejection technique that rejects any mail server foreign to the greylisting feature. If the sending server is not fraudulent, it'll resend the email. However, most spammers don't resend the email. Thus, the spam gets blocked. Through greylisting, servers that do the email resending will be added to the list and won't encounter interruptions in the future; greylisting won't allow the servers that don't resend emails to continue their activity. 

To deploy the greylisting feature with Postfix, you need to access the Postgrey service. For CentOS/RHEL users, Postgrey installation is available from the EPEL repository. When it's installed, enter the following command with:

sudo systemctl start postgrey

and start it:

sudo systemctl enable postgrey

Then, you'll need to edit the Postgrey config file for it to use the greylisting server:

sudo nano /etc/postfix/main.cf

In "smtpd_recipient_restrictions", add the following:

check_policy_service unix:postgrey/socket

Save and reboot Postfix.

This way, Postgrey will decline access from the new sender IP address, sender email address, or recipient email address. Sending fake email addresses may not stop randomly generated addresses. However, spammers with fake addresses never resend emails; this way, greylisting might come in handy. 

​Tip #6: Utilize Public Realtime Blacklists

Sometimes, fraudulent emails can pass through greylisting, with hostname and records checking out, but can still be email spam. The following email spam rejection measure in such cases would be creating blacklists. Real-time public blacklists imply that these blacklists are constantly updating.

You can use several blacklists to block email spam. For this, you need to see which blacklists are blocking the domain name of the spammers and use them. To query which blacklists contain the domain names of email spammers, you can go to MXToolBox and Debouncer websites.

To utilize blacklists, to the /etc/postfix/main.cf file, add the following:

smtpd_recipient_restrictions = 
permit_mynetworks 
permit_sasl_authenticated 
check_policy_service unix:private/policyd-spf 
check_policy_service unix:postgrey/socket 
reject_rhsbl_helo … (the blacklist)
reject_rhsbl_reverse_client … (the blacklist)
reject_rhsbl_sender … (the blacklist)
reject_rbl_client … (the blacklist)

For spammer using Google mail server "reject_rhsbl_helo" won't be effective. For most cases, "reject_rhsbl_sender" will be enough.

Tip #7: Enhance Security with OpenDMARC

Domain-based Message Authentication, Reporting, and Conformance, DMARC for short, is an Internet standard that prevents email scammers from using other people's domains for spam.

For setting up OpenDMARC you need to have DKIN verification and OpenDKIM. The further steps describe the installation and configuration of OpenDMARC on CentOS/RHEL.

First, you need to install OpenDMARC, which you can do from the EPEL repository:

sudo dnf install epel-release
sudo dnf install opendmarc

Start OpenDMARC (1) and make sure that it running (2):

(1) sudo systemctl start opendmarc
(2) systemctl status opendmarc

Next, open and edit the configuration file:

sudo nano /etc/opendmarc.conf

Change the: “# AuthservID name” to “AuthservID OpenDMARC”.

In the following line put in your Postfix hostname:

TrustedAuthservIDs mail.yourdomain.com

Then find the following line and change "false" to "true":

# IgnoreAuthenticatedClients false

In the following lines, do the same:

# RejectFailures false
# RequiredHeaders false

Save the file and restart OpenDMARC for changes to apply.

Speeding Up DNS Lookups with a Local Resolver

Postfix will perform a lookup of DNS records, and this process might take a while. To speed it up, you can run a local DNS resolver (since most DNS lists have query limitations). This example will use the bind9 DNS server.

Install bind9 DNS server:

sudo dnf install bind

And run it:

sudo systemctl start named

Enable auto-start at boot time:

sudo systemctl enable named

Configuring the Default DNS Resolver for CentOS/RHEL Mail Server

The default DNS resolver can vary, but you need to set it to 127.0.0.1.

First, you need to know the name of your network using:

ip addr

Next, you need to edit the configuration file and put the name of your network:

sudo nano /etc/sysconfig/network-scripts/ifcfg-name of your network

Then, find the DNS parameter and change it to 127.0.0.1.:

DNS1="127.0.0.1"

Save and restart the NetworkManager.

Disabling IPv6 in BIND

To avoid errors with the BIND log, it's better to disable IPv6 if your mail server doesn't have a public IPv6 address.

First, open the config file.

sudo nano /etc/sysconfig/named

To the end of the file, add the following:

OPTIONS= "-4"

Save the file and restart:

sudo systemctl restart named

Run the following command:

sudo netstat -lnptu | grep named