Reviving the Finger Protocol to Fight Spam?

Greg asks: "Some will remember the finger protocol which is barely used now. Although this tool was useful in some case, today this tool would be a nice tool for spammers. However, could such be used against spam? Most spammer use bogus email, and most spam-fighters talk about changing SMTP is to implement a certificate system to make sure the sender is valid. While this is great, it'll require a complete re-write of the SMTP protocol, adoption and re-write of all software using SMTP. Wouldn't it be easier to use a 'finger'-like protocol? When receiving a mail we could check if the sender is valid or not. What people think about this?"

Comments

"We need a new protocol!"

[onomatomania]

I hear that a lot -- "SMTP is old and crusty and if we could just throw it away and start over we could end spam forever." And that is such a bogus argument in my opinion.

First, there's the notion of getting the entire planet to upgrade to a new protocol. There are *still* open relays out there, and SMTP has been around for what, 25 years? And that's just a simple configuration change. You're asking every single organization that uses mail to switch to some brand new, perhaps untested program? What about all those millions of automated applications, web scripts, and embedded applications that send or receive email? What do you do, throw those away? And remember, you can't just say "Well, we'll make it backwards compatible for a while" because otherwise the spammers will just keep sending plain old fashioned spam. Perhaps the most fundamental aspect of why email has been so universally embraced by everyone is that it is simple, easy to understand, universal, and standardized. You risk throwing that all away.

But assuming you can get around the above issue, I still challenge you to come up with a new protocol that satisfies the following requirements:

• Does not break mailing lists and other legitimate bulk email. You may not be a list-junkie but everyone at some point in time has been on a mailing list that was of real value. I think you would find that many organizations would have a major problem giving up mailing lists. And there's plenty of other examples of legitimate bulk email -- order confirmations, notices, CONFIRMED (closed-loop) opt-in (and no other "opt" variety!), etc. I fear that a lot of the "make it hard for a computer to do it" solutions fail on this account. Hashcash is great and all, but how does a mailserver for a large mailing list deal with it? Whitelisting? You assume way too much about end users, they can't even get it straight how to unsubscribe most of the time, how can you expect them to maintain a whitelist? And how does Junis with his Commodore send email and still have the computation-requirement high enough that a spammer with a dual-Xeon can't send with impunity?
  
  
• Does not require a centralized, top-level organization. A lot of the cryptograpic proposals make the common blunder often seen when designing crypographic systems of ignoring the issue of trust and keys. If you are going to make this work then really the only way I can see it is to have some Verisign-like body that issues certificates, and revokes them if proof of spam is found. However, that is a giant can of worms waiting to happen. They would be subject to lawsuit after lawsuit from the chickenboners (small time spammers) and mainsleeze ("reputable" spammers) for all sorts of counts of "impeding business" or other crys of general unfair practice. This organization will somehow need to be funded, which means you have to either start charging for these certificates, requiring deposits, or taxing the entire system to pay the authority. And I'm not going to get into the issue of international law and jurisdictional issues. I hope you can see that this is a HUGE can of worms and if you hate Verisign think of a world where every email you send depends on their competence. You may claim a web-of-trust scenario will work, I say spammers would just create a fake community that all certify each other.
  
  
• Does not make email a pain in the ass. Whitelisting, TMDA, and a lot of things fail flat on their face here. The reason email is the killer application is because it's simple and universal. You will kill that with an overly complicated scenario that involves fees, licenses, governing organizations, international cooperation, etc.

If you have an idea for a completely new system that doesn't suck in the ways above, I'd like to hear it. But I haven't heard of one yet...