I assume I don’t have to introduce the concept of spam. Fighting spam can be done on different levels. A first line of defense is the mail server receiving them. There are several checks it can perform. Here is my configuration of Postfix.
I chose to leave smtpd_client_restrictions, smtpd_helo_restrictions and smtpd_sender_restrictions blank and do all the checks in smtpd_recipient_restrictions. While it’s possible to reject messages earlier, this setup gives more info in the logs for rejected messages.
Edit: Be careful with this! By pushing all restrictions under a single parameter, the order of the filters become very important! Make sure you understand the warnings described in the postfix manual.
These are the filters that I apply.
First, the local originated mail is allowed:
- permit_mynetworks: Allow local originated mail
- reject_non_fqdn_hostname: Non fully qualified hostnames names are rejected.
- reject_invalid_hostname: Hostnames which have an invalid syntax are rejected as well.
The next phase in the SMTP conversation is identifying the sender. SMTP has an “envelope sender”. This is the address where bounces are returned to. Usually, this is the same as the “From” field, but this is not required. If my mailserver is to accept responsibility to deliver the mail, it should have a way to contact the sender. If the sender address is not usable, we can’t bounce if needed. Don’t accept responsibility in this case.
The same applies for the recipients:
The next statement is very important: don’t become an open relay. Only accept mail for the domains you’re actually responsible for:
The previous tests were local and fast. The mail-server can verify them with minimal effort. But this is not enough to fight spam. Greylisting in particular is very effective. Greylisting will cause every mail to be initially rejected with a temporary failure. RFC 5321 requires sending mail-servers to retry this delivery. On a second attempt, the message is accepted.
- check_policy_service inet:127.0.0.1:10023: The greylisting server listens on this port and keeps the database of seen mails
SPF is another anti-spam technique. This verifies that the sending mail-server is actually allowed to send mail from this email-address. However, this causes problems with standard forwarding of emails, so I don’t use it to reject messages, but I do log the result
- warn_if_reject, check_policy_service unix:private/policy-spf
As a final test, several blacklists are checked. If the sending mail-server is listed as a known spammer, the mail is rejected.
- reject_rbl_client bl.spamcop.net
- reject_rbl_client sbl-xbl.spamhaus.org
- reject_rbl_client dnsbl.sorbs.net
All previous configuration will either accept the mail for delivery, or reject the mail. It will not silently drop mail, which is a very important thing in my opinion. If you really want to, you can chain spamassassin to the end.