I've spent the weekend configuring Postfix and Dovecot for a small server on Linode for a personal site/email. I feel like I've setup postfix correctly and I'm ready to open up port 25 in iptables and start getting email. I have to admit I still feel a bit fuzzy about some of the setups.

I've configured fail2ban for postfix which seems to work. I've also ran several online open relay testers to verify my server isn't operating as one. I've also got mail filtering through spamassassin.

Is there anything further that I should verify/test before opening up the server to the wild?

I usually point people to the Postfix restrictions and greylisting pages on the CentOS wiki.

The restrictions are a bunch of sanity checks that Postfix has built-in. Those that are generally useful that shouldn't block valid e-mail are reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, and reject_unauth_destination. If you are confident your recipient mapping is set up correctly, you can also put reject_unlisted_recipient into your smtpd_recipient_restrictions.

The check_sender_access is only useful if you want to set up a custom whitelist/blacklist, and reject_rbl_client is only if you want to use one or more DNS block lists. If you do want to use a DNSBL, choose carefully as some of them can be overzealous in what they block.

Greylisting has its proponents and detractors. I am one of the former, as it is the one single measure that most cuts down on spam for me. The downside is that mail from new originators will be delayed, usually 5-15 minutes, but potentially for hours before the message is retried. (The introduction section on the wiki page linked above gives a good quick overview.) Once a CLIENT_IP / SENDER / RECIPIENT triplet is cleared, future messages will not be delayed. If you routinely get time-sensitive e-mail from new senders, then greylisting is not for you. If you get upset when mail doesn't arrive immediately from some new web site you created an account on, again it's not for you.

Note that content filtering (Spamassassin) can consume a lot of CPU and memory, depending on how much mail it has to process. If you run other services on this machine, you may want to keep an eye on it or even disable it. But if your machine is lightly loaded, it's probably worth keeping.

One mailserver I administer has only the Postfix restrictions and greylisting configured. There are no DNSBLs and no content filtering. The amount of spam that gets through is pretty small. Just by doing this and making sure you're not an open relay, you're in a pretty good position.

I had issues with mail server farms and greylisting. Multiple consecutive failures, each originating from a different server in the farm. Sometimes it would be many hours before delivery success. I eventually dropped greylisting because of it. Have you encounter this? Found a way of avoiding it?

_________________
sleddog

This hasn't been a real problem for me personally, but I can see how this would arise depending on what service the senders of mail are using. AFAIK, the only workaround is to whitelist the sending servers; postgrey comes with a whitelist that includes many entries, but you may need to put some of your own into postgrey_whitelist_clients.local.