An unsurprising discovery about spammer behavior

December 15, 2006

Here's a recent, not entirely surprising discovery about spammer behavior: some spammers are really slow to pick up DNS updates.

We changed MX entries to point to our new SMTP frontend on late Monday afternoon. Our MX entries had the standard 24 hour timeout and our secondary servers had updated to the new zones by Tuesday morning at the latest, so by now it is more than two days after our old MX entries were required to have been purged from caches, even if they were gotten from a secondary using the old zone a mere millisecond before it updated.

And, you guessed it, spammers are still sending spam to the old MX.

(Since the new MX does spam tagging and the old one does not, this is vaguely irritating. If it was not a Friday, we might be doing something clever about the situation.)

I have to speculate about how the spam software behind this works. Clearly it doesn't do DNS lookups at the time it sends stuff, but does it do DNS lookups earlier and cache the results, or does it have a frontend that precomputes things all the way down to IP addresses? (The latter might be more useful, since it lets you use open relays too.)

Also, not all spammers and spam software does this; some spammers started hitting the new MX more or less the moment we published it, much faster than the places that send us legitimate email. (Which is not surprising; places that send us real email pretty much send us email regularly, which means that they have our MX entries in their DNS cache. A spammer's machine is probably not sending us email regularly, so is unlikely to have our MX already cached.)


Comments on this page:

From 206.168.172.26 at 2006-12-16 02:11:47:

Supposition regarding why some spamware uses old MXes:

1) It's trying to avoid 'too many MX lookups for a residential cable modem customer' monitors on Cable ISP DNS servers, so the spamware/botnet client comes with MXes cached.

2) Akin to the preference of some spamware for backup MXes (because the odds are the backups don't have as aggressive spam filtering as the primary MXes), it's trying to use former MXes to dodge newer filtering boxes.

3) The spamware is intended to send fast fast fast, such that DNS lookups noticeably slow it down.

Of course, the real reason is likely something entirely different...

Written on 15 December 2006.
« Fedora Core's memory problem
Weekly spam summary on December 16th, 2006 »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Dec 15 11:22:32 2006
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.