Wandering Thoughts archives

2009-10-22

The limits of some anti-spam precautions

In some quarters it is quite popular to do things like refuse email if the sending machine doesn't have valid reverse DNS or doesn't use a valid domain name in EHLO (or HELO). It's also popular to tell people that everyone should do this, for various reasons.

(Sometimes it's even popular to grumble about how all of the laxness of mailers about this sort of stuff has helped enable the spam epidemic.)

Setting aside all of the other reasons why these things may not be a good idea, it is worth pointing out that the only reason that these precautions work now is that not very many MTAs are using them. In much the same way that spammers once used invalid domains in the envelope sender address and now almost never do (because large MTAs started checking that), spammers are perfectly capable of adopting to use valid EHLO names and to only sending from machines with valid reverse DNS, if they actually need to. Indeed, the fact that the spammers don't bother to do any of this is a strong sign that only an insignificant number of MTAs use such precautions today.

(The history of bad domains in MAIL FROMs is a great example of this, in fact. It used to be a great way to get rid of a bunch of spam, until places like AOL (which was then an important spam target) started doing it. The next thing you knew, spammers were using real domains. I wouldn't be surprised if spammers adopted faster than real domains to the new reality.)

Or in short: spammers are lazy, not stupid (at least in the aggregate).

The corollary is that if you find an anti-spam heuristic like this that works for your email, you should not try to get other people to adopt it. The worst thing you could possibly do for your spam load is to persuade a significant number of MTAs to get more picky in what they accept.

(There is probably already an aphorism somewhere that says 'any widely adopted anti-spam measure will be actively defeated by spammers if at all possible'.)

AntiSpamHeuristicLimits written at 23:57:20; Add Comment

2009-10-14

Why 'invite-your-friends' features are spam from you, not your users

Here is at least a superficially appealing question: why is the end result of giving your website an 'invite-your-friends' feature spam from you, as opposed to spam from your users and thus not your responsibility?

(For the moment, let's set aside WordsForWebmailProviders.)

There is clearly a continuum of email responsibility that runs from 'email you send unprompted' (which is clearly your responsibility), through 'form letters that your users ask you to send' to 'you're an email provider and you're sending a message that one of your users wrote from scratch' (note that even this end of things does not absolve you of all responsibility). To me, form letters are on the side of the line where you spammed.

Right now, my justification for drawing the line there is who created the 'bulk' part of the UBE definition of spam. When you create an 'invite your friends' feature or anything similar to it, you created the bulk, not any individual user (well, generally). However, when an advance fee fraud spammer uses your webmail system to email 10,000 people who have unclaimed lottery wins, it is that spammer who created the bulk, not you.

(I say that you created the bulk because, well, you did: you wrote the code that generates and sends all those boilerplate emails, you wrote some or all of the boilerplate, and the emails come out of your system.)

This does imply that it is impossible to create a web application that sends form letters for people without sending UBE spam (unless you can guarantee that your email is always wanted). Given the existence and arguable usefulness of 'mail your elected representative about issue <X>' systems, I'm not sure that I like this conclusion, but it seems inescapable.

WhyInvitesAreYourSpam written at 00:07:36; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.