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...

Re:no.

[cyb97]

Or even easier...

sendmail -fpresident@whitehouse.gov spamrecipien@dot.com

Hello dear...

.

OR from any OS

telnet blahblah.example.org 25
mail from: president@whitehouse.gov
rcpt to: my favourite spamrecipient...
data
blahblah

.

Re:VRFY works, but may be shut off...alternatives.

[Electrum]

MAIL FROM: postmaster@myhost.mydomain.tld

Do not do that! What happens if the other machine then connects back to you to check if postmaster exists? It will create an infinite loop. You need to use a null envelope sender:

MAIL FROM: <>

Re:no.

[Quixote]

This is ASTOUNDINGLY easy in UNIX systems

Why blame Unix? As long as you have the ability to open a telnet to the outside world (port 25, to be more precise), you can do it from any connected machine.

Heck, I remember telnetting to the victims' MX servers and typing in the message by hand. It wasn't too difficult.

Re:Don't just edit SMTP, Replace it

[TeddyR]

"Oh yeah, it should have an option to start a chat directly between two IP addresses, just like ICQ used to be able to do (before they broke their protocol). "

I dont really consider it "breaking their protocol". More like a better security feature. This way the persons you are chatting with dont need to know your IP address {and may not show up in the local network traffic sniffs} unless you are transferring files.

The reasons for this were due to some ICQ specific hacks/programs that were able to trick ICQ clients into giving out more info than the user wanted to give out.