London:

In the spam-fighting community there’s the notion of the FUSSP — that’s the Final Ultimate Solution to the Spam Problem. It’s so-called because periodically people pop up proclaiming that spam is now a solved problem, if only everybody would adopt their scheme. So let’s look at the suggestion that have been made to ‘solve’ spam.

Password systems:

In these, you won’t accept an email from an unknown source unless it has your password. But how does someone who doesn’t know your password get in touch? Unless you use a challenge-response system for unknown senders. However...

Challenge-response systems:

These are a phenomenally bad idea. Primarily this is because on almost all spam, the From: and Reply-To: address is nonexistent or forged. So you receive a spam and end up sending a challenge into the other, or to the wrong person. In effect, you are spamming them with your challenges.

Even if spam didn’t forge addresses, by using a challenge-response system you are essentially outsourcing your anti-spam operation to a myriad of third parties. Do you trust all those third parties reliably to accept the challenge? A number of people will automatically junk any challenges they receive — and, similarly, a number of people will automatically reply to any challenge they receive, regardless of whether or not they sent the original message. (That lets spam through to the challenger.)

There’s also the issue of deadlock. Suppose you and I both run a challenge-response system. I send you a message, and don’t whitelist you. You send me a challenge. I send you a challenge in response to your challenge ... and neither one is ever responded to.

Pay-per-email:

When you think about it, challenge-response is the same as pay-per-email, except you pay with your time, not a token. Demanding that others pay to send you email is fraught with problems: who gets the money? What if you charge more than they can afford? It’s not as if having to pay for stamps has stopped physical junk mail, either. At least with challenge-response, each side decides if they’re willing to “pay”.

ISPs blocks on port 25 email:

This is very appropriate action. However, it needs to be carried out in conjunction with a second step — accepting mail submission on port 587, which is designed to require authentication: you have to give a username and password.

So the big ISP-to-ISP type communication can continue on port 25, and individuals would configure their mail program to send mail to their university using port 587, authenticating with his university’s mail servers.

This has still to catch on in a big way, although some of the larger ISPs are moving to support it (in the same way that port 25 blocking is still in relative infancy).

Limiting emails sent per day:

No single limit will be appropriate for everybody. However, two modifications make this more acceptable. First, provide a mechanism for customers to change their limit, possibly subject to review. Start them off with a low limit per day; then let them increase it to some capped value if necessary.

Second, change the granularity, so that instead of messages per day it becomes messages per hour, or similar.

Something that wasn’t covered is better detection of abuse by ISPs, with more help for cleaning customers who have become infected. Botnet traffic patterns are relatively obvious — such as a customer who has gone from sending 20 e-mails a day to 20,000. When this is detected, the majority of the customer’s internet access should be shut down. Attempts by them to browse any website should redirect them to a site at the ISP that explains why their access has been curtailed and allows them to download tools that can help them clean their PC.

Can spam be solved? The tools are all there, but they are being used haphazardly; lack of user education about how to treat spam doesn’t help. You’re still best off getting good filters and ignoring it.