Slashdot Mirror
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?"
...so instead of rewriting SMTP and all related programs you would have to write new programs and everything to use a new finger like protocol, which would also have to be written. You're better off sticking with what exists and building off of it, it makes backwards-compatability simpler and overall would require far less work. Something has to be done and it's going to take a lot of work, but why make it a more complex problem than it has to be?
this cmd is disactivated on a lot of servers cause it could be/was being used by spammers to find valid addresses.
The same could be said for finger-servers. Nice to DOS and nice to use to find valid addresses.
Wanna fight SPAM? Punish spammers hard, punish and close open relays, implement SMTP authentication (at least for external networks)... you'll never be able to banish SPAM completely, but why make it easy on the assholes?
What you're describing is more like identd.
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
www.eFax.com are spammers
SMTP isn't intrinsically flawed, and more than the phone or FAX are intrinsically flawed.
In the case of the phone or fax, LAWS were necessary to stop sociopaths from setting up automatic diallers that ran 24/7, and from sending millions of junk faxes.
In the case of mail; laws have been proposed. However, what might be more effective is that most ISP's decide SPAM is unacceptable and change their ToS to disallow it. Something like "If you spam, we will disconnect you, add your name to a nationwide ISP blacklist, and charge you a $10-per-email-sent cleanup fee"
And then once most ISP's have this, users have the option of simply blackholing the remaining 'spam-friendly' ISP's.
455fe10422ca29c4933f95052b792ab2
The first thing I did was made a sendmail milter that does exactly the validation of "FROM:".
I ran into trouble in various areas:
1. AO-Hell now has a non-RFC mail server
2. Yahoo "blindly" approves ANY "FROM:" test
3. MSN "blindly" approves ANY "FROM:" test
4. Majordomo may not validate their own "FROM:"
5. Nothing prevents SPAM'r from "assuming" a valid email address (heck, they have 1 billion to pick from... identity theft here, YES!)
6. Any attempt to tie DNS MX to the "FROM:" will break the following:
a. mobile IP
b. legitimate "forwarder"
c. NAT environment
d. valid SMTP-Relay link
e. Backup SMTP server
So, my work is also a work-in-progress, but I see the barriers. This is a stretch but I continue to use it nonetheless because the benefit far outweighs the risks of dropped legitimate mail.
The Finger protocol only protects the end-user against "hit-and-run" spammer (fake FROM:), but not the well-entrenched corporate spammers (real FROM:).
The last trick up my sleeve is the "WHITELIST" with folding cash-hash challenge or "please type what you see" LARGE TIFF images.
--
Hang the Spammer from the highest yardarm!
-- Uncertainity breeds doubts. So, by always assuming, you'll be right most of the time and look like a genius.
"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..."
Stick with SMTP, stop being such utter idiots about spammer abuse. To succeed the spammers have to send a lot of probing packets to IPs everywhere. Quit ignoring those probes.
No new protocol required, nothing centralized, no disruption from a switchover, nothing that makes email a pain in the ass (instead it makes spamming a pain in the ass - to spammers).
It's doable by end-users, it's doable by ISPs. Start today - spam will be devstated in a month.
It's exactly what you want. Stop ignoring spammer abuse. LOOK at the log entries for bounced relay messages, report them to the source ISP and to the destination ISP. Suggest to the destinaiton ISP that the best thing to do, if compatible with their TOS, is to wipe the mailbox and divert future messages from it. As a bonus the destination ISP can find the IP's of the messages to that email address and submit them to an open relay blocklist.
Plus other things that will occur to you once you are rolling - it's not rocket science. In general you want (a) to lie to the spammer whenever possible, (b) to interfere with spam delivery whenever possible, and (c) to notify as many ISPs as possible about the spammer tests and spam.
Open relay honeypots, open proxy honeypots - these are powerful weapons. There's not yet a download for everyone but there are these:
http://jackpot.uk.net
world.std.com/~pacman/proxypot.html
Go get 'em!
First, make sure you have reverse DNS lookup turned on, so that if you're claiming to be from domain foo.com, but your IP address says you're at bar.com, it gets dropped.
For everything else, set up a blacklist. Any addresses and domains in the blacklist do not get dropped, they get returned to the originator with a "no such user at this address" error message.
You'd probably need to build in some logic so that if I'm forging things from "invalid.user@foo.com" you don't start wasting bandwidth getting more bounce messages...
For the rest of it, you'd tests things in the following order:
Personally, I prefer the concept of using spammers as experimental subjects, or perhaps seeing how long they would last underwater without any scuba gear, or something.
Karma: Food Fight (Mostly affected by Date Plate).