CircleID

Attacking the spam problem head on is simply not possible. In its most general form, spam isn't "unwanted bulk mail", but rather "unwanted mail". The most significant sources of unwanted mail operate in bulk, but the "bulkness" isn't the root of the problem, merely an exacerbating factor. The spam problem is solved for subject X when subject X no longer receives unwanted mail: other factors are irrelevant. (I grant if you eliminate bulk-spam, you eliminate the bulk of the problem, but not the whole problem.)

Solving the spam problem directly means producing a system which can determine in advance whether or not a message is going to be desirable or valuable to a given recipient. Trainable filters are about the closest approximation we have to this ideal, but they are resource intensive and don't scale well. Ideally, we would like unwanted messages to remain unsent, rather than be delivered and deleted. That ideal would involve senders having detailed knowledge of their recipients' preferences, and intelligently targeting their messages to match. Even the most friendly and diligent senders lack the means to perform this task perfectly. In practice, some senders do a reasonable job, whereas others are bluntly inconsiderate to the point of active hostility. The hard-core "spammers" of the world are found at the latter end of this continuum.

Introduction systems are not inherently related to spam, but they are a valid defensive tool in the face of a certain kind of spam, namely the unsolicited bulk variety, known and loathed almost universally. Introduction systems work because they create a barrier to sending, either manual or monetary, and it's unlikely that a bulk sender will have the resources or motivation to cross this barrier.

On the other hand, the barrier created by an introduction system is socially inappropriate in situations where communication is actively solicited. Questions asked on mailing lists and newsgroups are one example, mailing list subscriptions are another. Introduction systems are not a general solution, not only because they address a mere sub-class of unwanted mail, but also because they actively impede a sub-class of wanted mail.

I allege that this pattern persists across all known sort-of-anti-spam techniques: they all defeat a certain class of spam, but harm or conflict with other desirable instances of email. This is true of introduction systems, payment systems, accreditation systems, address obfuscation techniques, disposable email addresses, blocklisting, and so on. An email user with a broad range of usage patterns wouldn't want to rely on any one of these approaches.

But that's not to say that any of the approaches must be abandoned; rather, they must be used appropriately. Since no one technique is appropriate to all use cases, different use cases must use different techniques. A use case can't generally be distinguished by the message itself, so individual email addresses need to be allocated to particular use-cases. Many of us do this already, creating email addresses for particular uses, although it's a technique which doesn't have standardised tools and interfaces at this time.

In my view, most of the problems of spam will be solved by empowering recipients with a broad range of techniques; a toolkit, with each tool appropriate to particular use cases. At the same time, we must allow recipients to distinguish their use cases by address, meaning that they must be able to create and expire addresses easily, and attach tools to addresses as appropriate. Tools in such a toolkit don't need to be inherently related to spam, they just need to have uses that address a specific need.

One of the problems of current anti-spam thinking is that we're still looking for the Ultimate Weapon Against Spam, rather than viewing our techniques as tools in a toolkit. The same "Ultimate Weapon" thinking means that some fail to appreciate the benefits of positive architectural changes which tip the playing field back in favour of email recipients. Sender identification schemes, for example, aren't an anti-spam mechanism in and of themselves, but they are the kind of positive architectural improvement that we need.

The combined tools and architectural features may not solve the spam problem generally, but so long as they are close to optimal for their particular use cases, who cares?