October 27, 2006

Let Them Eat Spam

We recently performed some badly-needed upgrades to our mail-handling infrastructure at work. This gave me a chance to, amongst the swearing and threats to rewire various servers into toasters unless they started doing their jobs, twiddle some spam-handling and have a look at the results. One of the things I'd been curious about was the degree to which our use of blackhole lists affected the amount of spam hitting us, given the recent brouhaha over the Spamhaus lawsuit and various claims from various folks about their effectiveness.

The following graphs are 12-hr snapshots of Upgrade Day. Note that this system is not our primary MTA, but is one of our front-end mail scanners; in other words, it is the first system to see the mail. Furthermore, this system is purely a mail receiver; the 'Sent' messages are those which are accepted into the company and 'sent on' to internal-facing mail handling. This is why Received and Send track so very well.

The time of change is fairly easy to spot.

Message Traffic

There were two changes made to mail handling on this host at the same time, which makes this graph not nearly as clean or useful an indicator. We turned on the use of rbl-xbl.spamhaus.com in the SMTP handshake phase, and we implemented postgrey greylisting at the same time. We had always been doing some fairly aggressive SMTP HELO/EHLO checking. Here's a graph showing what happened to the 'bad' mail over the same time period. Note the scale difference (msgs/min).

Bounces and rejects

Note that 'rejected' takes a sharp, sharp upturn, and bounces (which usually indicate the mail got through the format checking but were addressed to illicit addresses) drop way off. In other words, we start catching that stuff prior to queueing, which is what we wanted - having to do postqueue checks is more expensive by far (I'm assuming, at the moment, that REJECT indicators in mailgraph are prequeue given that that's what our log entries are for - NOQUEUE: reject - and that bounces indicate it was in fact queued before being checked and returned, but I may be wrong). The one thing I need to check is whether the initial greylisting straightarm is caught by these graphs as a REJECT, or if the Defer is handled differently.

So these graphs aren't worth much from a 'make your point scientificially' standpoint. They are enough to make me shake my head at the spamflow in.

Oh, yeah - there's no virus scan done on this particular machine. Also, it's not the only front-end mailscanner/MX, so while any initial dip in traffic could simply be due to the half-hour interrupt causing inbound servers to cycle elsewhere in the MX tree, that should have evened out over time considering that all of them got the same changes at roughly the same time.

Posted by jbz at October 27, 2006 8:43 AM | TrackBack

Post a comment

Remember personal info?