Comments on spam

qmail was the first major MTA to prohibit relaying by default. But it doesn't check whether sender addresses are at nonexistent domains. Some people have asked why not. This page is my answer.

Understanding spam

Spam is a denial-of-service problem. Spammers are consuming your resources: disk space, computer time, modem time, and most importantly your time. Spammers are preventing you from using these resources the way you want.

Bogus ``solutions'' to spam

Many people react to attacks as follows:

Look at what happened in the attack: what the attacker's computer did, and what our computers did in response.
Change something, anything, on our computers, so that the same actions by the attacker will fail in the future.
Declare that the change is a ``solution'' to the attack.

The problem is that attackers aren't going to cooperate. If the change becomes popular enough for them to notice, they'll simply modify the attack to dodge the change.

For example, once upon a time, typical spammers used nonexistent domains in their envelope sender addresses. Many people reacted as follows:

Look at the spam. Observe that the envelope sender address is at a nonexistent domain.
Change our SMTP servers to reject messages with envelope sender addresses at nonexistent domains.
Declare that the change is a ``solution'' to spam.

Eventually this change became popular enough for the spammers to notice---and suddenly it became practically useless. The spammers simply started using real domain names in their envelope sender addresses. (As of March 2000, roughly 95% of spam uses real domain names.) We're left with slower, less reliable SMTP servers, and more spam than ever.

A tremendous amount of time, effort, and money is wasted on this type of ``solution'' to denial-of-service attacks and to other security problems. The first people who try each ``solution'' find it remarkably successful; but the ``solution'' stops working as soon as it becomes popular.

The changes we need are changes that the attackers can't dodge. This is an essential feature of a true anti-spam system, and any other security mechanism.

Most proponents of ``anti-spam'' mechanisms don't seem to understand this. For example, here are some of the mechanisms that I've been asked to add to qmail:

Reject messages whose sender address is a nonexistent local user.
Reject messages addressed to Friend@public.com.
Reject messages with X-UIDL header fields.
Reject messages whose dates have time zone comments not matching the numeric time zones.

Spammers can easily dodge all of these ``anti-spam'' mechanisms, and will quickly do so if the mechanisms become popular.

There are some people in the world who have managed to reduce the spam in their mailboxes by 50%, 90%, even 99%. A few of them advertise their filters as ``solutions'' to spam. I'm sure their ``solutions'' work well as a niche product. But my mail system handles mail for tens of millions of people. On that scale, the ``solutions'' simply do not work.

How to eliminate spam

``There are lots of interesting remote denial-of-service attacks on any mail system,'' I wrote in the original qmail documentation in 1995. ``A long-term solution is to insist on prepayment for unauthorized resource use. The tricky technical problem is to make the prepayment enforcement mechanism cheaper than the expected cost of the attacks.''

Banks will have to set up cryptographically protected Internet debit systems. The Internet mail architecture will have to be redesigned accordingly. Computer security problems will have to be eliminated so that attackers can't launder their mail through an innocent third-party computer.

This won't be easy. But, unlike most ``solutions'' to spam, it will work.