Building a stronger edge infrastructure for email
Published by Mumineen.org Team October 2nd, 2005 in Gotchas, MailServerqmail has a lot of quirks due to its design of small compartmentalized daemons. One of the issues which impacts us a lot is its delayed-bounce behavior. An out of the box qmail installation only rejects mail for recipient domains not in ‘rcpthosts’ and from senders listed in ‘badmailfrom’.
That means if someone sends a mail to you for a non-existent user at your site, qmail will happily take the mail in, say “250 Ok” to the sender, then figure it has no user to deliver to, generate a bounce and send it back. Now assume someone sends a 5 MB mail: qmail accepts 5 MB in, and tries to send a 5 MB bounce out: 10 MB wasted.
Even worse, if the sender address is forged, qmail may annoy the wrong site with the 5 MB bounce, or it may not be able to deliver the bounce at all, and it may happen that the bounce sticks in your queue until its lifetime is expired.
There have been many patches to qmail (which are not endorsed by the author Daniel Bernstein or djb as he known in the MTA community) but it takes a lot of effort to layer various patches to qmail to give it features which other MTA’s such as Postfix or Exim have out of the box.
As such a few years after we started our site and the spam problem reached an intolerable level, volunteers setup Postfix as our edge-MTA. Postfix has a lot of features particularly in anti-spam capabilities and is actively developed.
In Postfix parlance, we configured Postfix to accept email to a bunch of domains as ‘relay_domains’ with ‘relay_transport’ set to our qmail/ezmlm box (this box had been configured to only accept email from our Postfix box). We also setup a list of valid recipients (after stripping out verp encoded suffixes) so that invalid recipients were rejected at the SMTP transaction phase. We also reject those senders who we would rejected as unknown recipients (reject_unlisted_sender).
We are also grateful to a large mail provider who gives us access to their DNS block-list which blocks a lot of IP’s connecting to us. We have a list of bad sender domains, we reject email from domains which have no DNS A or MX records (you can’t send them a bounce) and we do a decent amount of HELO/EHLO checks
Postfix also has the ability to reject/discard email based on header and body of the email via the use of perl compatible regular expressions and we use this capability to reject pretty much everything except plain-text email. This cuts down a lot of viruses and spam to us and eases the tasks of the moderators as well as the mail admins
Advice to our readers. Don’t use ‘catch-all’ email addresses. If you have your own domain name - they are typically configured to allow ‘anyone’@your-domain-name.com. This is convenient ‘initially’ you may not know which email addresses you want and it also has the benefit of catching mis-spelt email addresses.
But spammers love it - they can send to anything-they-like@your-domain-name.com and you will receive it!. So we would recommend you do it the other way around - instead of receiving everything - specify just the email addresses you want to receive and reject everything else.
4 Responses to “Building a stronger edge infrastructure for email”
Leave a Reply
You must log in to post a comment.







Thanks for the tip about not using a “catch-all” email address. I was using it for our jamaat domain “fatemi” and was looking at the brighter side you have mentioned.
The draw back didn’t hit my head until this one. Have changed the setting to fail for all domains. Hope this will reduce my headache of spam as well.
I am assuming that the relevant section of the Postfix FAQ is here, but am having trouble figuring out which filtering FAQ after that. I want to understand the relay_domains and relay_transport thing you mentioned above but am probably not looking in the right place.
You need to get the zen of Postfix address classes
looks like I need to get the zen of the VIRTUAL_DOMAIN readme file first…