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

More RBL needed?

[secolactico]

Pretty soon somebody will set up a finger server that will simply respond to every query with a "valid user" response.

Then you'll have to blackhole those servers.

Not an uncommon sight

[Wrexen]

Anyone noticed a trend in "Ask /." lately? Usually looks something like this


Dear Slashdot,

I have a great idea for fixing a problem that's been plagueing us all. By simultaenously implementing IPv6 world-wide, converting the US to metric, adding mass transit to rural areas, teaching everyone Esperanto, and making Linux ready for even the most stubborn grandmother, all the worlds problems will be solved. There's just this problem of implementation, i.e., how do I do it? I'm sure some clever /. can come up with a solution. Thanks!

Re:Not an uncommon sight

[clambake]

Dear Slashdot,

I have a great idea for fixing a problem that's been plagueing us all. By simultaenously implementing IPv6 world-wide, converting the US to metric, adding mass transit to rural areas, teaching everyone Esperanto, and making Linux ready for even the most stubborn grandmother, all the worlds problems will be solved. There's just this problem of implementation, i.e., how do I do it? I'm sure some clever /. can come up with a solution. Thanks!

Response: I have a Simpson's quote that might help you out, will that be enough?

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

kids and spam..

[zcat_NZ]

This makes me angry.

I set up email for my 8yo daughter. The address has only ever appeared on kid-oriented websites. Here's some of the subject lines from messages spamassassin has caught recently;

• Subject: RE: About your request of No.1 Teen Hardcore Site
  
• Subject: Chick love with beast 0464jjIM9--9
  
• Subject: she wanted to do it
  
• Subject: SHEMIKA'S pics
  
• Subject: Information Requested Please
  
• Subject: Improve your Sex Appeal!
  
• Subject: Wife wants you to have this Bigger Erection
  
• Subject: Make her scream use this
  
• Subject: DVD-Teens_About 15 GIGs of BEST Hardcore sex!
  
• Subject: See Results Immediately! Enlarge your Penis Today!
  
• Subject: Women: Revolutionary Climax Product Will Astonish You..........qzyrkvv
  
• Subject: Women: Revolutionary Climax Product Will Astonish You.......qzyrkvv
  
• Subject: Private-Viewer Pro provides secure Password Protection for all of your Adult Content.
  
• Subject: A New Stimulating Sensual Lubricant For Women (Discount Code #7181835)
  
• Subject: CHAROLETTE'S pics 0123IjOv9-354-12
  
• Subject: How to Boost Your Penis Size & Confidence username@ourISP.co.nz lpx
  
• Subject: [Men Only]
  
• Subject: username@ourISP.co.nz Valiumm-Viagraa-Xanaxx No Exam Needed!Simple
  Online Form hj:uqlm;ndiure;c cf;ikjc:
  

The problems with this, and my counter-proposal.

[wowbagger]

The fundemental problem with this is that it gives a spammer a way to insure a user is valid, thus allowing him to continue to spam the user. Thus, it not only does not solve the problem, it makes it worse.

Here's my counterproposal:

1) Create a new system, called "Verified Mail Transport System" or VMTS.
2) A VMTS server has a public/private keypair. The public key is listed via DNS, the private key is held by the server.
3) Several revocation lists exist - for example, a list of servers known to propagate spam, or to accept mail from non-VMTS servers and send it as though it had come from a VMTS server.
4) Failure to comply with the rules of VMTS is sufficent cause to be blacklisted - the server's administrators will be given 1 week after notification of violation to correct the problem, and if the problem persists, they are blacklisted. It does not matter whether the server is ittybittyisp.cm or uunet.net.
5) All servers are REQUIRED to validate the identity of anyone originating mail on that server - this validation can be done by a public/private keypair system similar to the one used between servers, or by RADIUS, or any other means that allows for tracing a given message back to the (l)user who sent it.
6) The user's machine shall sign the mail with the user's identity, or the user's mail server shall sign the message with its key if the user's system cannot do so. This signature shall be placed in the mail system headers of the message, along with the user's ID (NOTE: the user's ID does not have to be the user's email address or name, just some identifying number).
7) When a mail server handles a piece of mail, it shall compute a signature of the headers it adds AND the signature of the previous mail server's headers, add place that signature in the headers. That signature shall be based on the mail server's keypair.
To make this clear, given the following headers:
1) From: server foo
2) For: joeblow@bar.ex
3) Priority: highest
4) Prev_hdr_sig: 0xf238ace1
5) From: server narf
6) For: joeblow@bar.ex
The receiving server need only check headers 1-4. Header 4 covers header lines 5 up.

8) A mail server shall validate the headers from the previous server by looking up that server's public key, decoding the signature, and verifying the signature matches the headers.
9) Upon getting a failure to match in step 8, the server receiving the message shall stop the transfer and drop the message. It MAY also blacklist the sending server, notify its postmaster, or whatever other actions are deems needed.

NOTE: since all each server in the chain needs to check is just a very small number of headers, this shouldn't add a HUGE load to the server (less than spam filtering does). Since the keys are distributed via DNS (perhaps as TXT records, perhaps as a dedicated record), they get cached, so that the load of getting them is reduced.

When I, as an end user, get my mail, I can still get SMTP and VMTS. I can then read my VMTS mail first, then worry about the SMTP.

Now, how does this fight spam?
1) No unintentional mail servers/relays. Since you have to set up a DNS record to be valid, you won't see accidental open relays.
2) Intentional spam relays get blacklisted, since that is a part of the rules of the system. The big backbone providers like UUNET can and will get blacklisted if they don't comply, so they cannot play host to pink contracted spammers.
3) If I want to fully authenticate a message, I can independandly check each header block. If the headers are forged the signature won't decrypt properly (since the forger won't have the private key needed to encrypt it), and I immediately know where the message came into the system (thus, who to blacklist).
4) If I wish to identify the particular (l)user who sent the message, I could send the originating mail server a message with the following information:
4a) the signature I've computed for the message
4b) the signature heade