Isn't it funny to see how network protocol designers like things complicated? Recall a discussion on the IETF general mailing list in May and June about a trusted sender protocol. Hey, if you want complicated, you already have S/MIME and OpenPGP!
I can't for the life of me see how we will stop spam by making it impossible to forge the sender's email address. There may be good reasons to prohibit forging, but stopping spam is not one of them. What about the AT&Ts, the Gevalias, the thousands of other companies out there that think they ought to be able to spam you because what they have to offer is just so darn good? No politician would dare go against "legitimate" email marketing.
Now for something really simple. You pick a password for your outgoing email. I'm not talking about high security here. I'm just going to call it a "password," because I'm going to pretend that I'm explaining it to my mother. You pick your password, then you go to a web form provided by your ISP and enter that password in a web form. Your ISP stores your password and associates it with your email address. Now, you enter the same password in your email client. You're done!
So, what happens behind the scenes? When you send an email, the email client puts the password in a header field in the message. When the receiving client receives the message, it calls up your ISP and asks "Is this the password associated with this email address?" The ISP's server answers with a "yes" or "no." A "yes" answer means that the sender's email address has not been forged. A "no" answer means that the sender's email address may have been forged -- one should interpret it as probably forged. Note that the server's responding with "yes" or "no" means that one can try to guess the password, but that would require some work to accomplish. And decent software could control that by limiting how many guesses are allowed per unit of time.
One of the key requirements to make it all work is a way to associate the verification server (the server that answers "yes" or "no" to a password check) with an email address. It could be accomplished by associating the verification server's hostname with the mail domain name.
This is just one of my ideas for simple, but hopefully effective, control of email. Like my other ideas, it depends on our constantly moving the target. With a moving target, spammers will need to continually re-adjust their aim. In this case, the sender can change the "password" without too much fuss. The spam situation has often been described as an "arms race." I think we should change the description to a "shell game." We should keep moving the shells around and make the spammers guess which one contains the hidden ball. I'm betting that very often they will guess wrong, which means less spam, or at least less effective spam.
I mentioned earlier that authenticated sender techniques would not reduce spam. So, the question must be answered, "How would this proposed 'sender password' system be any different?" My answer is, that it would be a more effective way to implement white lists. White lists don't reduce spam, but they help us to avoid false positives. Without any sender authentication at all, white lists are subject to abuse. What if spammers all start to forge a sender address that's used by Amazon.com?
Of course, this is not what one would call "security." We don't know to what extent spammers will go to continue to spam as the defensive measures are stepped up. Will they resort to malware to hijack broadband-connected computers? I tend to think that once spamming becomes difficult, the amount of spam will fall off dramatically. If a small number of spammers do resort to malware, then we will just have to start paying more attention to computer security (in Windows!), which will pay great benefits beyond reducing spam. (It really doesn't make sense to me to create an anti-spam technology that assumes the use of malware. Just find a way to stop the use of malware! In other words, blame those who are responsible for computer security for that spam!) So, this is not "security," and it doesn't even use any cryptography. What it is, is just a simple way for your mail server to call back my mail server and ask "Did X really send this message?" It's probably as secure as the domain system. When you visit www.ebay.com in your web browser, how do you know that you are really at Ebay's web site? The answer is: you don't. DNS is not high security, but for most uses, it's good enough. When it comes to authenticated senders, I would settle for simple and good enough.
Posted by Doug Sauder at August 27, 2003 08:18 AM