Wandering Thoughts archives

There are reasons for stupid anti-spam policies

Every so often, people do silly things in the name of anti-spam work. While we can curse the creators of stupid polices like 'send notification email to the envelope origin address of mail scored as spam' as idiots, people aren't really, and I think it is more fruitful to consider why such policies get created.

(There is a university subdomain in Texas that does this. Really. When we started getting these notices, I almost wrote them a very grumpy letter asking what sort of idiots they were.)

In this case, I suspect that the answer is probably that high authorities are terrified of 'losing' legitimate email to spam rejection, so terrified that they are willing to force really bad policies to be implemented just in case. (And it may not even be the high authorities; the authorities may be responding to pressure from a vocal minority, especially in cases like the Texas university, where the minority may have tenure and grant funding.)

If nothing else, thinking about why these bad policies get created elsewhere gives us a head start in coming up with ways to keep them from getting put into place on our own systems and to have useful conversations with people who suggest them.

(It also gives me a certain amount of sympathy for the people who have to implement these policies and probably read email about them, which makes me glad that I did not send that grumpy letter.)

A depressing thing about phish spam

For a while, my general reaction to receiving phish spam from somewhere is to block it from sending me further email. This habit has led to me discovering something depressing: how many of those places later try to send me more email, often months after the first incident.

This is depressing because phish spam is usually sent from compromised machines. Getting more mail from the same machine is a bad sign; it means that the machine has almost certainly not been cleaned up, and is instead still compromised and being used for another phish spam run. (Or the machines were cleaned up, but then re-compromised.)

(One consequence of phish spammers preferring compromised machines is that greylisting is relatively ineffective against phish spam, since the compromised machines actually are running real mailers. I don't know why phish spammers don't use open proxies, or don't use them more often.)

I suppose it's not a very surprising thing on the modern Internet, once I think about all the forces involved. Either the machine's owners have to notice the problem on their own, or someone has to complain and reach a human. Complaining to the machine's owners require you find them and find some way of reaching them, and complaining to the upstream ISP is usually throwing your mail into /dev/null.

(On the other hand, some major phishing targets have security teams that try to get at least the phish websites taken down; I've seen email from them. But I suppose it makes much less sense for them to try to chase sending sources; given finite resources, taking down websites is more important.)

Why large ISPs like SPF (the cynical view)

One of the peculiarities of SPF and related schemes is that many large ISPs are quite enthusiastic about it, especially free webmail places like Hotmail, Yahoo, and Google Mail. However, this enthusiasm rarely extends to blocking incoming email that fails SPF checks, although they are happy to encourage you to use SPF on your own mail.

The cynical view of this is that ISPs love the idea of SPF because it gives them more control over their customers. With SPF, their customers are not only tied to the ISP for reading their email, they are tied to the ISP for sending email too. This suggests why the free webmail providers are so enthusiastic; all of them show ads on their websites, so the more they can force users to use those websites the more they profit.

This also may explain why people are enthusiastic about SPF variants like DomainKeys that validate the message headers, since it gives them even more control of what users can do. (For most users, what matters is not their envelope origin address but what From: header says.)

Sidebar: the less cynical view of DomainKeys

The less cynical view of why Google and Yahoo are behind signing the From: header instead of the envelope origin address is that they are smart enough to understand that in the real world, no one is using either SPF or DomainKeys to reject email in the MTA. If you're aiming at users instead of MTAs, the message headers are what really matters, and so authenticating them is the important thing.

(And you actually have a shot at persuading MUA authors to include optional DomainKeys checking, or writing plugins to do it for popular MUAs.)