Postfix 2.9 Upgrade

HowTo: Get Around Comcast Port 25 Block with a Postfix Server 5

Postfix 2.9 UpgradeI run a number of “real” Postfix servers that live “away from home,” in a cozy server cabinet at our colo facility, but I also like to keep a Postfix server handy in the basement, running on an ancient (but rock solid) Dell PowerEdge 2450 running CentOS 5.

I don’t use my local Postfix server for very much: some local ping checks, some minor automation scripts, some testing, some tinkering… but one thing for which I do rely on my personal Postfix box is allowing my APC UPS units to send email alerts to my Gmail account whenever they experience power events. I’m forced to rely on a local SMTP server for these UPS units, since they don’t support SMTP authentication, and therefore need an SMTP server that allows internal addresses (192.168.1.x) to relay mail without a username and password.

Until a few months ago, this worked fine. My local Postfix box (which sat isolated from spammers behind my firewall) allowed unauthenticated local clients to send alerts to my Gmail account… until Comcast decided to block all outbound (and as far as I can tell, inbound) traffic on port 25, requiring that all mail sent through their network do so through authenticated SMTP servers. I understand Comcast’s reasons. The vast majority of spam originates from compromised personal computers sitting on residential networks, spewing out junk mail without their knowledge. I’m sure shutting down port 25 stopped a lot of that malicious mail… but it also shut down mail for those of us who have legitimate reasons for relaying on port 25.

I was trying to figure out some creative way of relaying mail from my local Postfix server via some other port to a remote Postfix server, and then delivering the mail from there. But thanks to Rod K. on the Postfix-Users discussion list, I was reminded there’s a simpler way: just set up my local Postfix box to relay mail through Comcast’s SMTP servers, rather than try to fight my way around them. Facepalm.

Setting this up will take less than five minutes. First, edit your /etc/postfix/ file and add these four lines at the bottom:

relayhost = []:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =

Next, create an /etc/postfix/sasl_passwd file that contains this single line:        USERNAME:PASSWORD

where USERNAME is your Comcast email username, and PASSWORD is your Comcast password. These are the same login credentials you’d use to log into webmail on, so if (like me) you never use your Comcast email and don’t remember your password, you can go to their website and try out a few… or just reset it there.

Once you’ve created that file, lock down the permissions a bit (since it does contain a clear text password) with:

chown root:root /etc/postfix/sasl_passwd
chmod 600 /etc/postfix/sasl_passwd

Finally, convert the text file to a database format for Postfix, then reload Postfix to pick up your changes:

postmap /etc/postfix/sasl_passwd
postfix reload

Test things out by sending an email through your local Postfix server. Check your mail log for any issues.

This approach will also work if you want to use Gmail as your relayhost. You’ll need to use your full email address as your username, and since Gmail requires TLS, you’ll need these two additional lines in your /etc/postfix/

smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Of course, if you keep your certificates file somewhere else, use that location instead.

I’ve also used this TLS-enabled version of this configuration to allow relaying through another Postfix box I control outside of Comcast’s network. Just make sure to put the relay host and submission port (usually 587) in /etc/postfix/, then update your /etc/postfix/sasl_passwd file with the appropriate login credentials (remember to always run postmap and reload Postfix when done editing that file).

Congratulations. You’ve just hacked your way around Comcast’s port 25 block!