The Practice of Code

When I first started running my own mail server about 10 years ago, I really liked the idea of a catch-all email address for my domain. Not only would I receive accidentally misaddressed email, I could make up any email address on the fly, and not worry about having to configure it every time.

Shortly after that, I realized that every time I supplied an organisation with my email address, I could instead provide that supplier with a unique address, something that identified them, so that if I start receiving spam at that address, I could easily identify the source. For example, if I started getting spam at amazon@example.com, I would know it was Amazon that either sold me out, or had a breach.

Unfortunately, after a few years, some industrious spammers decided that rather than sending spam to only known-to-be-real addresses, it was more effective to simply send tens of thousands of messages to every common name at any and every domain. I remember one day waking up to the fact that my mail server was choking on the over 7,000 messages in its queue, addressed to john@example.com, mary@example.com, and every other common name at my domain.

By this point, I had handed out so many unique addresses to legitimate suppliers, that I really didn’t want to disable the catch-all, which was the strong advice from anyone who knew anything about mail servers. The temporary solution I came up with, was to parse the mail log for every address it had accepted that day, put them all into a blacklist, and manually perused that blacklist to remove any legitimate addresses. I then added this blacklist to my mail server, and from then on, every time the server received a message to my domain, it would verify that the recipient was NOT on the blacklist, before delivering it to me. Needless to say, this was time consuming, less than perfect, and far from an elegant solution.

I knew there had to be a better way. And there was.

I decided that from then on, every time I supplied an organisation with a unique address, I’d use their fully qualified domain name, as opposed to a one word identifier. So, instead of amazon@example.com, I would supply amazon.com@example.com. On the mail server, I configured a virtual alias that checked for the period in the user part of the address, insisting that there was at least one character before and after it, and then removed the black list and disabled the catch-all.

To accomplish this using Postfix, I created a new virtual file in /etc/postfix/regexp_virtual, with the following contents:

/[^.]+\.[^@]+@example\.com$/        me

In main.cf, I appended this file to the virtual_alias_maps directive as follows:

virtual_alias_maps = hash:/etc/postfix/virtual, regexp:/etc/postfix/regexp_virtual

So, when Postfix receives a message, it first checks the virtual file for any hardcoded addresses, then it goes on to the regular expressions in the second file trapping for my special addresses. If the address isn’t covered by one of the two, the message is instantly rejected. No blacklist required!

Of course, you don’t need to implement the same pattern I have. I’d say that nearly any pattern you come up with would protect you from the standard name attack, and still give you the added benefit of a semi-catch-all to be able to track where and how anyone uses your address.

Unfortunately, managing spam will always be a never ending arms race, and I’m sure that in the not too distant future, some industrious spammer will identify the pattern in my system and manipulate it to their advantage. By the time that happens, I’ll hopefully have another plan in place or be able to come up with one quickly.