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