Wandering Thoughts archives

Danger signs for mail senders in SMTP conversations

This is another one of those entries that I write for people who are never going to read it, but I don't care; I just feel like pointing out the relatively obvious.

Suppose that you are someone who runs a mailing list service. Like everyone else who offers such a service, spammers will attempt to (ab)use it. Thus, one of the important things that you need to do is detect signs that you have a spammer's mailing list, and these days you certainly can't count on abuse complaints to tell you this.

As I've mentioned before, SMTP time rejections can be an important signal. The corollary of this is that the kind of SMTP rejection matters, and in particular you should really pay attention to MAIL FROM and DATA rejections and consider them a significant warning sign. This is because there are many fewer reasons for rejecting at those stages than for rejecting at RCPT TO time so if your mail is rejected then, well, there's any number of explanations besides 'it's spam'; the user's account could have expired, for example.

(And, let us admit, a disturbingly large number of mail systems have temporary glitches that cause equally temporary RCPT TO failures. This is why real mailing list management software pretty much never automatically removes addresses on a single RCPT TO failure.)

Since they don't have these relatively innocent explanations, mail rejections at MAIL FROM or especially from DATA are often signs of something serious going on. In particular a permanent failure at DATA time almost invariably means that the recipient's system really dislikes the message for some reason; if you're running a mailing list service, the usual case is that it's spam. A MAIL FROM rejection can have more innocent explanations, including a misconfigured MTA on the other side, but it is still more of a danger sign than a RCPT TO rejection.

(A significant volume of RCPT TO failures is still a danger sign, in part because it means that either the list of addresses is old or that the mailing list was badly maintained before it moved to your service. And if a mailing list has a few good mail-outs and then suddenly its RCPT TO failures spike upwards significantly, well, that's a bad sign itself. It could be that a whole bunch of user accounts just coincidentally got expired or filled up, but it's more likely that a bunch of anti-spam systems that reject at RCPT TO time suddenly woke up.)

Of course, all of this presumes that you are trying hard to run a 'clean' mailing list service instead of any of the various alternatives. I'm not convinced that there is or can be any such thing these days, as convenient as it would be for modern web applications if there was.

Some recent Google spam problems

With my anti-spam hat on, I'm not a fan of Google. It's not that they're active spammers themselves, it's that their services are not infrequently used to send spam in various ways and Google is famously indifferent to it, or at least apparently indifferent, and has been for some time.

(I've felt for years that there was basically no point in trying to file any sort of anti-spam report with Google because it would just go into a black hole, assuming that they didn't reject it outright.)

Every so often spammers find a new way to exploit some Google property for spam purposes, and I get to be irritated at Google all over again. There have been two particularly noteworthy incidents relatively recently, one from phish spam and one from a spammer for hire. The phish spam issue is due to Google Docs, as opposed to any of Google's mail-sending properties. Google Docs allows you to make forms and then collect replies to them (in a Google Docs spreadsheet, apparently). Oh, and you can evidently supply a significant amount of styling to these forms if you want. You can guess how phish spammers can put this feature to use, especially since one of the perennial problems for phish spammers is hosting the phish form somewhere reliable and then collecting the results. Given that phish spammers continue to do this, I expect that Google Docs is also reliable in not closing them down.

The second and even more irritating recent spam incident is that a 'spam for hire' outfit in the middle east appears to have worked out how to use Google Groups and other Google services to actually host their mail lists and do their spam mailouts. Google evidently allowed them to import a huge mailing list (over 20,000 addresses), did not make any attempt to confirm addresses, and now lets them send plenty of spam to and through it. Of course there is no 'report this mail as spam' link in the messages and I know better than to bother trying to find any abuse contact for Google Groups.

(I know how many addresses it has because the spam mailing list is a public Google Group so you can see its 'subscriber' count if you look it up. Since the spam list they put me on is helpfully called 'total005', I can also make some decent guesses at the existence of other ones.)

Now that one spammer has blazed this trail, I expect that I can look forward to blocking lots of other Google Groups in the future. (I block them on my end, not by using any Google feature. At this point I have no trust in anything Google Groups might offer to keep me from getting spammed.)