I had a bit of an epiphany while chatting to Antoin
about the qpsmtpd/EC2 idea. Craig
had the same thoughts.
Here’s the thing — there’s actually no need to offload the SMTP part at all.
That stuff is tricky, since you’ve got to build in a lot of fault tolerance,
quality-of-service, uptime, etc. to ensure that the MX really is reachable.
Since an EC2 instance will lose its “disks” once rebooted/shut down, you need
to store your queues in Amazon S3 — which has differing filesystem semantics
from good old POSIX — so things get quite a bit hairier. On top of that, it
requires a little RFC-breakage; there are issues with using CNAMEs in MX
records, reportedly.
However, if we offload just the spamd part, it becomes a whole lot simpler. The
SPAMD
protocol
will work fine across long distances, securely, with SSL encryption active,
and SpamAssassin will work fine as a filtering system in an entirely stateless
mode, with no persistent-across-reboots storage. (What about the
persistent-storage aspects of spamd operation? There’s just the
auto-whitelist, which can be easily ignored, and I haven’t trained a Bayes
database in 2 years, so I doubt I’ll need that either
If the spamd server is down or uncontactable, spamc will handle this and retry
with another server, or eventually give up and pass the message through, safely
intact (though unscanned).
Given that there’s a cool third-party ClamAV
plugin now available for
SpamAssassin, this system can offload the virus-scanning work, too.
So here’s the new plan: run the MTA, MX, and the super-lean “spamc” client on
the normal MX machine — and offload the “spamd” work to one or more EC2
machines.
Basically, there would be a CNAME record in DNS, listing the dynamic
DNS names of the EC2 spamd instances. Then, spamc is set to point at that
CNAME as the spamd host to use. As EC2 instances are started/removed,
they are added/removed from that CNAME list and spamc will automatically
keep up.
Pricing is reasonably affordable — don’t send over-large messages to the EC2
spamd; rate-limit total incoming SMTP traffic in the MTA; and use the SPAMD
protocol’s REPORT verb to reduce the bandwidth
consumption of mails in transit by ensuring that the mail messages are only
transmitted one-way, MX-to-EC2, instead of both MX-to-EC2 and EC2-to-MX.
That will keep the bandwidth pricing down.
Recent figures indicate that I got about 90MB of mail per day, at peak, over
the past weekend (which nearly DOS’d my server and caused some firefighting) –
68MB of spam, and 13MB of blowback. At 20 cents per GB, that’s 1.8 cents per
day for traffic. Plus the $0.10 per instance hour, that’s $2.42 per day to run
a single EC2 instance to handle DDOS spikes. Of course, that can be shut down
what load is low.
Yep, this is looking very promising. Now when are Amazon going to let me
onto the beta program for EC2?…
Tags:amazon aws ec2 spamassassin spamc spamd
This post was written by Justin, source: SpamAssassin as an EC2 service