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.
<note warning>The more you bolt your system down to reject spam, the more you risk rejecting legitimate e-mails</note>
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.
See the Security Considerations section of the SMTP server docs. Simplified, it comes down to:
If you don't do this, you may have to add “permit_sasl_authenticated” to some of the smtpd_client_restrictions restrictions below.
<note>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. </note>
<note tip>This is quite a good standalone tweak.</note>
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. <note warning>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!</note>
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
<note tip>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”</note>
There are more restrictions you can add to smtpd_recipient_restrictions in /etc/postfix/main.cf which I have found to be effective:
reject_non_fqdn_hostname reject_non_fqdn_sender reject_non_fqdn_recipient reject_invalid_hostname
These have been found to be very effective and are best added before the Greylist checking parameter:
<note tip>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”</note>
<note info>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.</note>
<note warning>Do not use
as I've seen mis-configurations by a big company (EE) and this would reject valid e-mails.</note>
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.
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.
<note warning>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.</note> Add a line to /etc/postfix/access:
Run the command:
<note tip>This command has to be run any time you change /etc/postfix/access.</note>
Then add to /etc/postfix/main.cf:
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/access
<note warning>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.</note>
<note warning>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</note>
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