Wandering Thoughts archives

Anti-spam content scanning systems need to scan more

It's long since past the time when anti-spam content scanning systems should decode and scan all the encoded attachments of email messages, especially encoded plaintext ones. Most content scanning systems always been willing to decode base-64 encoded inline text and HTML (it's sort of a basic requirement), but I don't think very many of them scan attachments. The predictable result is that spammers have caught on that attaching their spam in a base-64 encoded attachment works, and it shouldn't.

(And this is not sophisticated spams from sophisticated operations; this is advance fee fraud and the like. I've been receiving an increasing number of these of late, many of which have been getting through the commercial system that we use.)

The sophisticated version of this is to embed the spam in a Microsoft Word .doc file, so pretty soon content scanning systems are going to need to be able to extract text from those too. I'm sure that spammers will try to obfuscate the text, just like they try to obfuscate the text in HTML messages today, but such obfuscation makes a good signature all on its own.

(Yes, accepting random .doc attachments from strangers has its own risks, but in most environments it's probably not politically acceptable to just refuse all of them, however tempting it sometimes is.)

One thing your mail-sending system should do

If you are for some reason absolutely forced to have a system that will send email to user-entered addresses (given the principles of modern email this is not a good idea, but let's imagine that your management forces you), one of the things that you should absolutely do is make your system so that it won't send mail to certain user names. Spamming people is one thing; spamming abuse, postmaster, noc, security, and any number of other administrative user names is just carelessness.

(You may be able to guess what our postmaster alias got today, although it was probably actual spam faking the 'someone requested you be sent information' bit.)

The case for vacation autoreplies is somewhat weaker, but I think that they should definitely not auto-reply to at least postmaster. If you can manage it, the best thing to do probably is to not auto-reply to any administrative address that is not at your local domain. Your local NOC or security people might care that someone is not reading their email; the odds that a NOC elsewhere cares is, well, relatively low.

(These days, postmaster is not even an administrative address; it is a system address that is not used by humans, much like daemon. If you are lucky, someone reads email sent to it, but no one sensible sends email from it any more. Addresses like noc and security are still real administrative addresses, in that real people may send email from them.)

And on a side note, putting the IP address that submitted the web form into your auto-sent-out email message does not make your email any less spammy or abusive, or cause people to react any better to it. That particular well has been thoroughly poisoned by spammers (who forge this information in the hopes of distracting people). However, if you are going to do this please insert the same information into the message headers in some relatively standard format, like X-Originating-Ip:, so that automated systems can pick it up and do something with it (although you should already be doing obvious things like not allowing SBL-listed IP addresses to send out email).

(As a tip to would-be spammers, try to make your forged IP addresses come from actual allocated IP address space.)