Postfix has some great Spam control settings, but they are confusing! Here’s what I think I’ve figured out:
- smtpd authentication is now commonplace, likely using sasl
- sasl authentication takes place at the RCPT TO step, meaning you can easily block a legitimate request if you have smtpd_delay_reject turned off
- based on the last comment, if you do have the delay turned off, you should have most of your rules in smtpd_recipient_restrictions, where the RCPT TO step and sasl authentication happens
- the postfix page separates the restrictions based upon client, sender, and recipient, but the filters do not have to be separate, therefore you can put a reject_rbl_client in the smtpd_recipient_restrictions section.
What follows are my postfix UCE settings in main.cf. There are many alternatives, but I’ve found this setup to work well. I’m going to take these one restriction at a time, followed by an explanation. However, I’m starting with some general settings which affect the other restrictions or are general restrictions in themselves.
disable_vrfy_command = yes smtpd_delay_reject = no smtpd_helo_required = yes address_verify_map = btree:/var/db/verify/verify_db
smtpd_client_restrictions = reject_unauth_pipelining, permit
smtpd_helo_restrictions = permit_mynetworks, check_helo_access hash:/etc/postfix/helo_access, permit
Again, there isn’t too much we can do at this point, but I use a hash table to block spammers from trying common yet invalid helos. For example:
friend 554 Service unavailable localhost 554 Service unavailable localhost.localdomain 554 Service unavailable
grep "NOQUEUE" /var/log/mail/mail.log |sed "s/.*helo=\(.*\)/\1/" |sort |uniq -c |sort -rn | more
Note: Edited for Debian environment and friendly output.
smtpd_sender_restrictions = reject_non_fqdn_sender, permit
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_non_fqdn_recipient, check_recipient_access mysql:/etc/postfix/mysql-rcptbl.cf, reject_unauth_destination, reject_unlisted_recipient, check_client_access hash:/etc/postfix/uceprotect.net-dnsbl-access, check_policy_service inet:127.0.0.1:60000, reject_rhsbl_sender dsn.rfc-ignorant.org, reject_rbl_client dnsbl.kempt.net, reject_rbl_client sbl.spamhaus.org, reject_rbl_client list.dsbl.org, reject_rbl_client dul.dnsbl.sorbs.net, reject_rbl_client dnsbl.njabl.org, reject_rbl_client psbl.surriel.com, warn_if_reject, reject_unknown_client, #warn_if_reject, #reject_invalid_hostname, warn_if_reject, reject_unknown_hostname, check_policy_service inet:127.0.0.1:10000, warn_if_reject check_sender_access hash:/etc/postfix/sender_access permit_mx_backup
After those permissions comes our first big blocker:
This checks the client against a hash table of blacklisted ips, provided graciously by UCE Protect - A Provider of Spam and UCE Defense products and services. My favorite aspect to their offering is the ability to rsync their entire database to your server, hash it, and use it there. As you can imagine, this results in faster results. I’ll explain how I do this later, in the meantime you can check out their instructions on how to setup automatic rsync synchronization with their dns blacklist database. When a spammer tries to send your server a spam message, postfix checks the list, and if they are on it, they are denied.
Next up, another local lookup, but now instead of a hash table, we use a database. I use a database here because of its flexibility, and ease of manual or automatic updates. I use this restriction to block mail for domains I host that have no mx record and receive no mail. Spammers sometimes just send email to an A record of a domain, thinking it will find its way into a catch all account somewhere.
After that, the last of the inexpensive restrictions, and a very good one I might add: greylisting. I use postgrey, and it has worked very well. The concept is simple, delay the mail for a short period of time. Most spammers won’t bother to retry, while any real email server will hold off for a little while, and try again. As many people have said, this is a very effective method of blocking spam. If its so good, why does it come so far into the process? Great question! It is because we have to know the recipient before we can do the testing for it to be accurate. (Note: the default for greylisting in postfix is to continue processing the resrictions even if the message passes the greylisting test - i.e. the message was sent again. This is good as the rest of the tests will be run to see if the message is spam or not.) Here’s another Neohapsis email about when to include the greylisting policy in postfix recipient restrictions.
Next come the blacklist lookups. These are very effective, and take a little time and effort to complete. You should therefore consider running a dns cache of some sort. Remember thes important factors when using dns blacklists:
- DNS blacklists are not always right.
- Many DNS blacklists seem to come and go. Here is a list of dns realtime black lists (dnsbl) and their status.
- Some DNS blacklists are fee based.
- Spamassassin can also access DNS blacklists, so if you are wary about legitimate email getting blocked, you can use spamassassin to flag them instead of block them.
I definitely cannot use this one as ISPs and hosting providers do not always configure their DNS records correctly.
tail -f /var/log/mail/mail.log -n 400 | grep "NOQUEUE\|reject_warning"
I cannot use this one, as many clients and ISPs misconfigure their helo parameters.
Next is another policy server which more people should use. I have it this low on the totem pole because not that many people do use it. This is for the sender polify framework (spf) which is designed to prevent domain spoofing, where unauthorized email is sent from a domain that the sender does not have access to. As more people setup spf records for their domains, this policy will become more useful. Here are some helpful instructions on whitelister (spf policy daemon available on debian). FWIW, here’s the Gentoo Mailfiltering Guide with some information on SPF.
Lastly I include a warning for unverified sender addresses. Here’s what happens, postfix pretends to send an email back to the sender, and if it looks like the address is valid and the email will go, then the email from that address is allowed, if not, meaning there is no address from where the email is coming from, it is rejected. This is an expensive, unreliable, and not generally recommended technique, so I only do this for a subset of commonly forged domains. In my recent experience, the most common forged domain in spam my servers have received is earthlink.com. Ouch for them.
- Gentoo Wiki HOWTO Email: A Complete Virtual System - Refining the Setup
- The Postfix Home Page
- Comprehensive Postfix FAQ
- WSRCC Spam Fighting Page
- Blocking spammers with Postfix HELO controls
- ISP Mailserver Solution Howto - Where I found information on using mysql for storing policy data
- IP Netranges for all countries