Spam is a huge problem. Spam detection is a losing proposition. As spammers get more and more crafty, detection becomes harder and harder. What we need is an upgrade to email, and Internet Technologists agree. Efforts are in progress to draft a proposal, however, everytime I read another one they seem too complex.
I have a much simpler proposal, that we could start deploying right now.
My proposal is to do sender authentication at the SMTP level, with a compatible extension to the implementation.
1) SMTP server receives delivery request
2) SMTP server looks at envelope sender
3) SMTP server contacts "mailkey.senderhostmx.com" to get mailkey
4) If mailkey host exists, SMTP server validates message signature with mailkey and accepts or rejects message. If mailkey host does not exist, SMTP decides what to do based on its own policy.
5) Any time a server sends a bounce message (spam, unknown user, etc) to the envelope sender, it should include a note about how to prevent others from forging their addresses by setting up mailkey.
This proposal is simple because it does not change the SMTP protocol, or mail clients at all. This proposal is incremental, because it does not disturb existing mailflow. Most of all this proposal has viral incentive, because it is within each domain's power to stop others from forging their domain. The additional requirement that bounces to spam messages be sent to the envelope sender assures that an authenticated sender has responsibility for handling the spam they originate, and it assures an unauthenticated sender has incentive and information about how to become authenticated.
Once AOL, Yahoo, and MSN support this, everyone will start
doing it to reject spam mail forged to "allegedly" come from those
domains. Once enough people support it, the big three will only
accept mailkey signed mail. Once that happens, everyone will only
accept mailkey signed mail.
Of course there will still be spam, because anyone can make a mailkey
host. However, you will be able to catalog complaints against
the actual senders and take action.
There are some other ramafications of this. For example, using SMTP to deliver mail from a mail client will be deprecated. People often make the argument that allowing clients to forge mail and send it through whichever SMTP server is convinent is a required capability. However, this forging is normally the "From:" header of the message, while the system above only authenticates the envelope sender.
Many SMTP servers have already switched to some form of authentication method for incoming clients. However, we should discourage this. Client mail-sending should be rolled right into the client/server mail protocols such as POP3 and IMAP. This assures that the same user-identity and login system is used for sending email as receiving email. Users would no longer be allowed to 'forge' envelope senders from another domain (whether it was their or not) through an email account.
For users who wish to forge envelope senders, I say "too bad". This 'legacy support' backdoor is just backwards thinking in our mentality about SMTP. Just like we stopped allowing SMTP relay years ago, this envelope sender forging backdoor must also be closed.
[One wrinkle, is that mail-forwards are essentially envelope sender forging. Handling these gracefully while implementing the above scheme is the current issue I'm considering.]