Michael Wolf
Projects and thoughts from Cincinnati San Jose Oakland an undisclosed location in Grass Valley
Home Projects Photos Github Mastodon Nullbrook RSS
Getting Dovecot to Play Nice and Procmail to Stop Calling Me Bogus
Last edited - 08/15/18

Running your own email service seems to have the reputation of a Herculian effort, unnecessary in the era of free email services and social media. I've come across legends of unstoppable spam attacks and undeliverable mail, ISP clampdowns and botnets. But I feel like it's an important step in regaining personal control of your data, identity, and privacy. Running your own mail server can provide a technical understanding of the protocols underlying the Internet as well take a small step toward re-decentralizing it.

I don't plan on this post being a comprehensive guide to setting up a server, but more of a log of my experiences

As with many Internet-connected service setups, Digital Ocean helped get me started with their article. I used Linode's guide as well, but I really got the most help from a blog post written by Cullum Smith . Even thought it was written for FreeBSD, his writeup provides an intricate explanation of all of the important facets of Postfix are covered.

In my endstate I have postfix and dovecot running on a Debian box in my apartment with iptables re- routing requests from non-standard ports as they hit the system. After paying the small price for the full Aquamail client, I couldn't be happier with the setup (except for when I move).

Tools Used Permission Denied

After the initial setup of my mail server, I most certainly ran into issues. Many of the problems were pretty verbose in the mail logs, but others seemed to occur without warning. One such example was that after a certain amount of time, I would no longer be able to query my inbox, getting a permission error. In tracing the mail log I was able to see a log line from procmail looking at the inbox, declaring it bogus, deleting it and recreating it with different permissions. What the hell! That's a destructive cron job. Eventually I was able to finally just fix the permissions of my mail system, unifying the owner of the directories so that each of the components of the mail system acted kindly to requests to load the inbox.

Getting Out of Spam-Filter Hell

One of the pitfalls I was made aware of almost immediately when I began sending emails out of the nullbrook domain was the difficulty of getting messages to actually arrive at their destination. Gmail was no problem, but pretty much every other provider figured I was selling ED pills before I took some steps to clean up my new domain's reputation.

I was fortunate enough to come across which is a phenomenal and free website for testing the reputability and configuration of a personal mail server. It does have quite a bit of tracking software embedded in it, though. With the assistance of this service, I was able to sort out the DKIM, the SRV records and certificates required to allow traffic from the nullbrook domain to flow freely into AOL, Yahoo, and Microsoft inboxes.

Despite some concerns that messages from my server were being dropped or blocked, I've been using the server as my primary inbox for about a year now and no known failures in delivery have occurred.

iptables Rules

I've had some less-than-stellar experience working with iptables in the past, but after enough reading I have been able to put together the iptables configuration my system needed to ward off automated scans.

iptables -A PREROUTING -t nat -i $INTERFACE -p tcp --dport $STARTPORT -j DNAT --to-destination $HOST:PORT
iptables -A FORWARD -p tcp -nat -s $HOST -o $INTERFACE -j MASQUERADE

Next Steps