Using qpsmtpd and Amazon EC2 to provide SMTP-DDoS protection

Like a few other anti-spammers, I found myself under a hitherto-unprecedented level of spam blowback this weekend. Disappointingly, there are still thousands of SMTP servers configured to send bounce messages in response to spam.

Even with the anti-bounce ruleset for SpamAssassin, the volume was so great that our creaky old server had a lot of difficulty keeping up — once the messages got to SpamAssassin, the load issues had already been created. Also, Postfix’s anti-spam features really weren’t designed to deal with blowback.

While attempting to take some shortcuts in the setup on our server to deal with this, a great idea occurred to me — why not come up with an app that uses Amazon EC2 to flexibly provision enough server power and bandwidth to pre-filter the SMTP traffic for an MX under attack?

I’m basically thinking of qpsmtpd, with SpamAssassin and/or other antispam blobs active, running in an Amazon EC2 server image. Multiple images can be brought up, and added to the attacked domain’s MX record at an equal priority, to take load off the main (overloaded) MX.

Now to cogitate a little — details to follow…

This entry was posted in Uncategorized and tagged , , , , , , . Bookmark the permalink. Both comments and trackbacks are currently closed.


  1. Devdas Bhagat
    Posted November 29, 2006 at 15:56 | Permalink

    Why not just temporarily block all bounces?

    smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/blowback

    and /etc/postfix/blowback contains

    <> 550 Bounces rejected due to blowback

  2. Posted November 29, 2006 at 21:15 | Permalink

    As discussed by IM, I think doing this via CNAME records instead of MX (and pointing spamc at the CNAME round-robined spamd cluster) would be a more flexible way of providing potentially other under-load-create-new-instance-and-auto-add-to-DNS anti-slashdotting of a wider set of services. Consolidating the data is probably not much of an issue in many of these cases, since the load is by definition abnormal, and so you probably don’t mind tossing out anything those temporary nodes “learn” in things like bayes DBs etc. So you don’t need a common (synchronized) data store for them.

  3. Posted November 30, 2006 at 15:12 | Permalink

    Devdas — I am doing that. unfortunately that means I miss legit bounce messages, too :(