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, especially the section about updating /etc/postfix/postgrey_whitelist_clients. You can add a basic two line file to /etc/cron.monthly or /etc/cron.weekly:
wget -q -N http://postgrey.schweikert.ch/pub/postgrey_whitelist_clients -O /etc/postfix/postgrey_whitelist_clients
/bin/systemctl condrestart postgrey.service
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.
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 SMTPS on port 465 rather than SMTP on port 25.
Open the Incoming Firewall
to the SMTPS service if you want to send mail from the internet.
Fixed devices on your LAN
should either use SMTPS on port 465 (preferable) or add your LAN
(s) to the Trusted Networks in the SMTP Server
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. If you want to use this instead, add a line to /etc/postfix/master.cf:
submission inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject
or, to allow TLS encryption:
submission inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may -o smtpd_client_restrictions=permit_sasl_authenticated,reject
or, to enforce TSL encryption:
submission inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=encrypt -o smtpd_client_restrictions=permit_sasl_authenticated,reject
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/main.cf:
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 spamhaus.org Reputation Block List
spamhaus.org 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 spamhaus.org in this way add:
to the smtpd_recipient_restrictions parameter in /etc/postfix/main.cf
You can test this by adding
warn_if_reject reject_rbl_client zen.spamhaus.org
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/main.cf which I have found to be effective:
These have been found to be very effective and are best added before the Greylist checking parameter:
Again you can test this by adding
before each parameter then monitor you mail log. e.g.
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 zen.spamhaus.org
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/main.cf
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 example.com and you receive a lot of spam from senders such as firstname.lastname@example.org, email@example.com etc, this is easy to stop.
If you follow the recommendation Reorganise how you send mail from your clients then no one from example.com 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:
Run the command:
This command has to be run any time you change /etc/postfix/access.
Then add to /etc/postfix/main.cf:
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