wiredfool

I’ve had my own domain for nearly 10 years now. Somewhere early in it’s life, I did some things with email and spam control that were a reasonable idea then, but have now turned into something of a non-standard nightmare. Because of some early choices, it’s now nearly impossible to host my domain on shared hosting (i.e., someone else’s admin work) without completely changing all of the email addresses that I’ve given out over the years.

Along the way, I’ve had throwaway addresses for posting on usenet. (that accidentally leaked my real email out one time when I wasn’t careful). The throwaway emails turned out harder to throw away than I’d hope, due to the software that I was using.

So, enter new software, and I implemented a recipient delimiter scheme. Base-extension@domain.com. Only, what I should have done, but didn’t, was use the default delimiter of my MTA of choice (postfix) instead of a non-standard one. Even then I didn’t have a really good way to bounce the ones that should have been killed long ago. Like the -tw extension for Time Warner, used once, spammed incessantly. That error of not using the standard means that I’ll have to host this domain myself until I’m willing to change every one of those extensions.

A catchall email address fell to a dictionary attack where I was getting 3000 pieces of email an hour overnight, and 50,000 before I gave up on the concept.

The final straw was the recent power outage. So now I’ve got a virtual private server running the inbound mail for the domain using a standard debian stable install of postfix, forwarding to Dreamhost to provide user accounts, POP, IMAP, and outbound service if necessary.

There are three important bits of configuration: virtual aliases, control of the recipient delimiter, and an easy way to blacklist the extensions lost to spam.

Virtual aliases are implemented in the standard manner, a set of address destination pairs. All addresses served by this machine are listed here.

To prevent the server from sending to Dreamhost using the – recipient delimiter, the virtual map had to be removed from the propagate_unmatched_extensions parameter.

And finally, the spam victim recipients are culled using the check_recipient_access map, which allows for pairs of the form: user-extension@ REJECT message to be used to reject email to that extension.

A main.cf fragment.

virtual_alias_maps = hash:/etc/postfix/virtual

# prevent dreamhost from getting the recipient extensions.
propagate_unmatched_extensions = canonical

# recipient filters. 
smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/client_access, 
     permit_mynetworks, reject_unauth_destination

Useful configuration links: Propage Extensions, client access map, different bounce messages

The best takeaway here is that when you’re doing something non-standard because it’s better, sometimes the world moves faster than you have time to evolve.