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?"
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.
No sig
Someone had to to make the pun...
"Oh drat these computers, they're so naughty and so complex, I could pinch them." --Marvin the Martian
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?
A large portion of spam gets sent out under real email addresses that do not belong to the spammer.
On top of that fatal flaw, this system still has all the major problems of other systems:
Would require huge infrastructure and deployment efforts
Not everyone will get on board, either on the receiving end or sending end
Most email users do not control their own domains and would depend on their ISP for any finger servers
Most people still accept spam as a 'fact of life' concerning the internet.
Even now I still tell people that they will just have to accept the spam, though some filters help. It's simply not worth most people's time to fight it yet.
I wish we didn't have to use any legal measures, but the reality is that any technological measures will be overcome quickly. Laws exist to prevent such 'arms races', and in this case neither party (spammer/user) is willing to back down from their position.
-Adam
What you're describing is more like identd.
Anyone noticed a trend in "Ask /." lately? Usually looks something like this
/. can come up with a solution. Thanks!
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
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:
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...
that's not a good solution. sorry. see above ...
I don't see why I can send mail from, for example, president@whitehouse.gov
This is ASTOUNDINGLY easy in UNIX systems
hostname whitehouse.gov
useradd -m president
su - president
mail -s 'How are you gentelmen???'
Buttsex.
The VRFY command is for the client to check wether the user exists on the server it is delivering to (and to get some additional information which is the reason it is deactivated on most servers).
It is NOT for the server to check back politly with the client wether the email is originating from a valid user.
Anyway, what is a "valid user"?
Edgar
"I'm a real girl...finger me and I'll prove it to you!"
I'm starting to think this isn't the best place to promote my Anti-Sig Campaign.
Not only spam, another problem with VRFY is that it give blackhats a pretty easy way of finding valid systemaccounts (given that many still use email -> systemaccount)... VRFY doesn't leave as many traces as most other ways of finding valid accounts
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;
Online Form hj:uqlm;ndiure;c cf;ikjc:
455fe10422ca29c4933f95052b792ab2
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
I always take the time to metnion that spam exists because SMTP is intrinsicly flawed to allow it.
And you're wrong.
Spam exists because the sociopaths that do it don't think they're doing anything wrong.
Spam is a social problem. It doesn't matter if SMTP is "intrinsically flawed" (which it isn't) or not - any system you can think of can be abused. Come up with a better solution, and I bet that I can come up with a way to spam through it in under 5 minutes. And if I can, you can bet that spammers can too.
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: <>
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.
"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.
--
Time is on my side
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).
I did read your post, but you seem to have misread mine. You are suggesting a switch to a new protocol based off the finger protocol for email, I am saying that sticking with SMTP and modifying it is probably a better idea since upgrading an existing and installed protocol is much easier than implementing an entirely different and new protocol in its place. Completely switching protocols is a bit more complex than just updating an existing one.
Unfortunately, the finger method solves the wrong problem. As mentioned by others the system provides spammers with the capability they need to defeat it and a more efficient way of checking if their 1000000000 e-mail addresses are good and valid still.
The problem is veracity of the sender, not existence of the sender.
Public/private key schemes, rewrites of SMTP are all interesting and all, but standard SMTP is ubiquitous, and any solution that doesn't fit well with SMTP as it is is likely not to amount to much, at least not unless there is no harm from switching, ie: loss of ability to receive e-mail from old SMTP users.
In reality, I think a tremendous help would be individual e-mail message verification rather than address verification.
One possible good fix would be a SMTP extension to verify the message-id. The validation and recognition of validation would be completely optional; however, a SMTP server would have some way to indicate it has this capability, and then clients could attempt to validate the message.
A possible method of implementing this would be to use an EXT VRFY message of some sort, ie: EXT VRFY message-id, and any mail server the message passed through would respond with a message indicating one of the following replies:
And possibly also:
Support for the feature could be added by adding a special tag to the message header that is added by each relay the message passes through (the one that includes the message-id)
SMTP servers could also be setup in some fashion as to perform recursive lookups similar to DNS across the relays to verify that the message truly originated with the sender, and relays could be equipped to perform this validation before even accepting the message for relay [connect back].
Being considered valid by a trustable uplink in the relay chain implies validity; however, clients can make their own decision if they don't trust the relay (to prevent spoofing)
If the backwards verification process were done just upon delivery, the the information about the messages could be expired quickly of course: within short duration after the validation process, message-ids could be stored in a hash table, and ordered in such a manner that a fixed number of them are remembered by the server, and the status of the oldest message ids is erased to make room for newer ones.
The reason to seek an implementation like this is because it's simple. It doesn't prevent legitimate mail systems from being hijacked but it helps prevent spoofing.
Public/private key pair systems are nice to think about, but they are only effective to the degree that you can trust the signers & their verification processes.
They are excellent for verifying that a mail server is the same as the one you first saw when you recorded their public key, but they are lousy for verifying a mail server's identity at time of contact: if you n