More anti-spam and e-mail defence measures

It is possible to make further adjustments to the e-mail system to harden it against spam and attacks through config changes to the command line.

The more you bolt your system down to reject spam, the more you risk rejecting legitimate e-mails

Install the Greylisting app

This is a basic antispam measure, but please read the documentation.

You can also maintain your own whitelist at /etc/postfix/postgrey_whitelist_clients.local. I whitelist Ebay and PayPal as the sender often changes as you do transactions with different vendors or purchasers and it saves having to wait five minutes for each new e-mail.

If you monitor your maillog for “postgrey” messages, you may find more senders to add to the whitelist, especially regular senders who retry too quickly and senders who, when they retry, retry from a different IP address.

I use the following query to look at my mail log to see if I can spot anything which needs whitelisting:

if [ -z $1 ];then

sed -e 's/  / /g' $FILE|grep -i postgrey.*action=greylist.*reason=new | grep -v cleaning| grep -v whitelist | grep -v client_name=unknown | awk '{print $8, $10, $11}'  > postgrey-new.txt
sed -e 's/  / /g' $FILE|grep -i postgrey.*action=greylist.*reason=early-retry | grep -v cleaning | grep -v whitelist | grep -v client_name=unknown | awk '{print $10, $12, $13}'  > postgrey-retry.txt
sed -e 's/ delay=[[:digit:]]*,//g' -e 's/  / /g' $FILE| grep -i postgrey.*action=pass.*reason=triplet | grep -v cleaning | grep -v whitelist | awk '{print $9, $11, $12}' > postgrey-pass.txt
echo New:
grep -vxf /root/postgrey-pass.txt /root/postgrey-new.txt | column -t
echo Retries:
grep -vxf /root/postgrey-pass.txt /root/postgrey-retry.txt | column -t

Reorganise how you send mail from your clients

See the Security Considerations section of the SMTP server docs. Simplified, it comes down to:

  • Turn off SMTP Authentication.
  • Configure any devices (phones, tablets, laptops) which are going to send e-mails via your server from the internet to use STARTTLS on port 587 (preferred) or SMTPS on port 465 rather than SMTP on port 25.
  • Open the Incoming Firewall to the SMTPS or SMTP STARTTLS service if you want to send mail from the internet.
  • Fixed devices on your LAN should either use STARTTLS on port 587 (preferable), SMTPS on port 465 (second best option) or add your LAN(s) to the Trusted Networks in the SMTP Server (easier).

If you don't do this, you may have to add “permit_sasl_authenticated” to some of the smtpd_client_restrictions restrictions below.

Technically SMTPS on port 465 was never a ratified RFC but it is in common use and ClearOS supports it out of the box. The standard which was ratified is STARTTLS on port 587 and this has recently been added to ClearOS 7.6+ as standard.

Stop senders with no Reverse-DNS Record

This is quite a good standalone tweak.

It is a mandatory requirement of the e-mail RFC's that every sending MTA has an IP address resolves to a PTR record (a Reverse DNS record). The PTR record does not have to be the same as the sending FQDN; it just must exist. Typically dynamic IP's may not have a PTR record and, if sending mail, may just be compromised machines. They make good candidates for blocking. These are the postfix/smtpd “connect from unknown” messages in the maillog. To block these from getting any further than connecting (so they can't actually send the message) add a line to /etc/postfix/

smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_reverse_client_hostname

I had to add the “permit_mynetworks” bit recently because of docker images (ClearGLASS) sending e-mails and these have no PTR records in ClearOS.

Even the big boys can get it wrong. I had to contact Microsoft recently about a faulty block of IP's sending mail without a PTR record. This was continually being rejected on my server for days. After they fixed it, and the e-mail came through, it turned out to be a Hotmail message!

Trust the Reputation Block List have some very reliable spam blacklists but please read their pages. You can reject e-mails coming from sources on their blacklists before they even come into your mail system. This means the mail never gets as far as as the anti-spam checking so will never get [SPAM] tagged as it does not get received. To trust in this way add:


to the smtpd_recipient_restrictions parameter in /etc/postfix/

You can test this by adding
warn_if_reject reject_rbl_client

to smtpd_recipient_restrictions then monitor you mail log. Once you are confident of it working, remove the “warn_if_reject”

Other Parameters for smtpd_recipient_restrictions

There are more restrictions you can add to smtpd_recipient_restrictions in /etc/postfix/ which I have found to be effective:


These have been found to be very effective and are best added before the Greylist checking parameter:

check_policy_service unix:/var/spool/postfix/postgrey/socket
Again you can test this by adding

before each parameter then monitor you mail log. e.g.

warn_if_reject reject_non_fqdn_sender

Then check your mail logs to see what would be rejected by the parameter. Once you are confident of it working, remove the “warn_if_reject”

The full line I use is
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
    reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_invalid_hostname,
    check_policy_service unix:/var/spool/postfix/postgrey/socket, reject_unauth_pipelining,
    reject_unknown_recipient_domain, reject_rbl_client

I've split the line to help it to display correctly, but it will work when split like this or as a single line.

Do not use

as I've seen mis-configurations by a big company (EE) and this would reject valid e-mails.

Other useful standalone parameters

The following are standalone parameters for /etc/postfix/


disable_vrfy_command = yes

This stops some techniques used to harvest email addresses.



This may cause problems with home-grown applications that send mail, and with ancient PC mail clients so defaults to “no” but it is worth trying. It may stop the odd spam e-mail.


smtpd_helo_required = yes

This may cause problems with home-grown applications that send mail so defaults to “no”, but should be fine for mail coming from commercial e-mail packages. It is worth trying.

Stopping mail from the internet from fictitious users of your domain

If your domain is and you receive a lot of spam from senders such as, etc, this is easy to stop.

If you follow the recommendation Reorganise how you send mail from your clients then no one from will be sending you email from the internet through port 25 as valid users will be using port 465 (or 587). It is then easy to filter out this offending mail.

Do not do this fix if your users are still sending e-mail from the internet via the server on port 25 or they will be blocked from sending e-mails to your domain. They must be using port 465 or 587 for this fix to work.

Add a line to /etc/postfix/access:		REJECT

Run the command:

postmap /etc/postfix/access
This command has to be run any time you change /etc/postfix/access.

Then add to /etc/postfix/

smtpd_sender_restrictions =
        permit_sasl_authenticated, check_sender_access hash:/etc/postfix/access

Make sure you have “permit_sasl_authenticated” before “check_sender_access hash:/etc/postfix/access” or only people covered by “permit_mynetworks” (Trusted Networks) will be able to send mail.
Make sure you have a carriage return or new line at the end of this section or it may end in tears if you subsequently change other parameters in the Webconfig

Then restart the SMTP server (not reload) through the Webconfig or with a:

service postfix restart             # ClearOS 6.x
systemctl restart postfix.service   # ClearOS 7.x


content/en_us/7_ug_more_antispam_measures.txt · Last modified: 2022/06/01 13:30 by