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
i thought i saw a cmd called VRFY which is supposed to check if the supplied email is a valid.
I know it exists on SMTP on windows servers not sure about non-windows smtp servers.
...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?
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
Anyone posting over 100 bullcrap E-mails a day, should be herded and culled like the dirty rats they are.
num->num->pineapple
Finger is unfortunatly not helpfull since spammers would be happy setting up some one-time finger server and account to get out their x million spam-emails. Unless of course finger-information would be required to bear a signature. But then we could sign the email in the first place.
Edgar
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.
"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.
Also, don't most sane firewall operators have port 79 blocked already? This would also require all those people that put NAT "firewalls" on their plug-n-play broadband connection to figure out how to open a port (and just one, for all of our sakes) to send and receive email. I think it would be easier to just rewrite the whole shebang...
Every time I see a spam issue mention here on slashdot, I always take the time to metnion that spam exists because SMTP is intrinsicly flawed to allow it. Sure people can implement black-lists, or white-lists, but no such notion exists nativly in SMTP itself. A state can create as many laws as they want, but as long as SMTP is the standard messge passing protocal, spam will exist! This is one of those grey-area's where a law isn't very good to govern technology. You can pass a law into existence to make certain aspects of a technological protocal against the law, or you can simply let the technology be strong, and avoid reactionary law making. We should pass laws preventing the IEEE from introducing bad technology standards before we pass laws to prohibit the free usage of existing standards. A law should ban the SMTP protocal before banning the ability to send bulk email. Anti-spam laws are analogs to walking up to door-to-door salesmen, jsut that its easier to knock on 500,000 doors with SMTP that in real-life, yet the later is allowed! So in my perspective, altering SMTP is a good thing(tm). Forget finger, its considered unsecure, and will not work. What we need is to make SMTP more secure. We need built-in white-lists, we need to turn the "inbox" into a que of requests for being added to a white list. We need to chatify email.
It isn't a lie if you belive it.
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
% telnet mail.domain.tld 25 Trying mail.domain.tld...
Connected to mail.domain.tld...
Escape character is '^]'.
220 mail.domain.tld ESMTP Postfix
EHLO myhost.mydomain.tld
250-mail.domain.tld
250-PIPELINING
250-ETRN
250-XVERP
250 8BITMIME
MAIL FROM: postmaster@myhost.mydomain.tld
250 Ok
RCPT TO: spammer-sender@mail.domain.tld
550 User unknown in local recipient table
So, although VRFY may speed things up a bit, there are ways to validate the existance of an account. You can use this technique to validate whether or not a Sender address, as listed in the email for a local recepient, exists or not. If it doesn't exist, you can drop the email as a 550 error for not having a valid return address. It's all very logical, if not a slight slow down in email delivery.
IIRC, the exim email server can do this, and sendmail and postfix are customizable for such a mechanism. With postfix, you may have to use a custom filter program, but that's do-able.
assert(expired(knowledge));
Instead of patching up SMTP, create a new email protocol that uses public key encryption to determine which mails you want to open, and which ones you don't. Since it would be integrated into the protocol, it would end up in the clients, meaning widespread use of strong cryptography would finally be realized. We've got the math now to make this realizable
This would work because now everybody has at least one metric they can use to decide whether or not to open an email. If it's not from someone you know, and you weren't expecting an email, don't bother with it. Eventually, spammers wouldn't be able to reach the large amount of people, because they know that their emails are just getting deleted by default: they'd eventually stop. When your business relies on getting random emails from people, you'd be at least in the same situation you are now, only you'd have a way to speed up the processing of emails from someone you already know.
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). Since authentication via encryption is taking place here, this is where the instant messenger parts should go. The whole thing should be written in Ada.
Here comes the government to solve the problem. Spam is now the enemy. It must be destroyed.
SMTP v3 or whatever is on its way. The only question is the exact design. Finger protocol or not, it doesn't really matter. The general outline is already known. Real-world verification of identity tied to every e-mail address capable of receiving SMTP v3 e-mail. A transition period where people can sign up for "upgraded" e-mail accounts. A period where these "upgraded" accounts can receive e-mail from other v3 accounts as well as from old, traditional, potentially anonymous SMTP-deliverable accounts. Most/all business and government users transition to v3. Then, an Internet-wide deadline, upon which all v3 e-mail addresses stop receiving e-mail except from other v3 addresses.
The day the Internet died. Sure, it will be more "efficient" then. But it won't be free.
Don't cry about it. It happens to all technology. Those who need anonymous communications will just move to something else. Maybe web-based discussion, for example. Just no more truly private, truly anonymous, or truly free e-mail.
Blah blah blah.
A large portion of spam gets sent out under real email addresses that do not belong to the spammer.
The solution is to use a finger-like protocol that:
Then, if a spammer forges someone's address, they have to know a valid message-id for that user, which is difficult to do.
(One way a spammer might know it is to read on the web mailing list archives to which the user posts; to get round this, the finger-like protocol could also be asked to verify a 128-hash code of the message contents).
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: <>
How about having the SMTP servers to a reverst lookup for those servers trying to send mail. A simple gethostbyaddr() call would filter quite a bit of spam (if who_you_say_you_are != who_your_ip_address_says_you_are then FLUSH). Those pieces of spam that use "legitimate" mail headers would have the ISPs either black listed or not providing service to spamers is short order.
The dogcow says "Moof!"
How about I give you the finger, and you give me my phone call.
why not show a different finger showing different information depending on your domain, trustworthiness, etc ..
Metric is the future!
18:36 26/5/2546
... ... now it's all commercial. the internet got bigger, ... ...
...
TOPIC: SMTP-"flaw"
hi!
i think when SMTP was introduced, everybody knew everybody on the internet. WAY back then
i was the universities, science-labs that where using it
ruder and more chaotic (YEAH!).
So, it's a "senior" protocol, time for retirment. don't just "kill" it, but
one got kicked out off uni, if he "stole" some HDD-space from another Uni.
now i get a 100Megs free on the net
AdvancedSMTP, nope like someone mentioned before, can spoof domain, user and ip-adresse?
so how to securely communicate over such a network?
idea:
the email A wants to send to B is stored on A's SMTP-server, ready for pick-up, but A's SMTP server sends a
"envolope" to B's SMTP server, but no letter contained. it's still on A' SMTP server.
B gets his mail and sees an "envolope" of A.
1)
A tells his SMTP server to go fetch "content".
-OR-
2)
not. (say after 24 hours-> auto-delete((YEAH! plus gray-listed, say we only accept "envelops", but no "letter".
we can still ABSOLUTLY DENY him ->black-list! bad idea, but possible...)
say case 1):
B'smtp-server "tells" A-smtp server it wants the "content".
A'smtp is very happy ; ) and sends the content to B'smtp-server -AND- a counter say: "first "content" deliverd".
this "counter-data" can be used to verify A's SMTP-server is not beeing spoofed.
we repeat this a few times (20 emails?, counter is at 20). everything goes well:
A's SMTP-server is added to B's WHITE-list (e.g. all "envelops" contain a "letter".)
NOW: someone spoofs A's domain/ip-adresse, but he doesn't know how-many "envolops" have been sent.
(counter-data wrong!)
so B'smtp-server goes to the if-part that say "fishy". etc.
now it's up to the RFC community to decide, if we should just bomb the spoofer off the net,
or we start to investigate. say, add a "fishy-bit". (here it gets complicated, because B know's somethings wrong, but
he can't just go ask A. say B defaults back to case 2). we just restart accepting "envelops", but no "letter-content".
IF "fishy-bit" shows up, maybe it would be good to notify "user.A". B could, via ASMTP, send a "human-readable" email to
A and JUST TELL him "fishy-bit" has shown-up
of course i'm not saying it's fool proof, but spammer will have to start rethinking their strategy.
counter-data, could be substituted with a SUM of all "hours.minutes.second" the "envelops" have been sent...
or a random password from a random database, that's different on ALL ASMTP.
-> "i told you the "password" so remember, next time you send me an email."
or a randomizer of the senders emailadresse (randomizer-algorithem would have to be different on ALL ASMTP-servers.
easy "mandelbrot-set(real.imaginery.my.domain) etc. WOAH, what are the chances two ASTMP pick the same mandel-brot.domain?
one would have to attache a database to the ASMTP-server -> work-load UP!
all very difficult, but considering HOW-MUCH garbage.data is clogging the net, maybe a good investment.
bad argument: the network-operators are happy, they are selling Bandwidth, but what a safe of my TIME!
it's still "time", right? multi-user-unix still spells "time", right?
-
thank you for your time!
Just one interesting problem. Let's say I want to spam your ISP, say, escape.com. I can setup my DNS a particular way, spam you directly. "Now it's escape.com's job to say, holy crap, he spammed me, blackwhole the fucker." Now that you've blackholed me, I can buy a new domain for about $8, and use that now. I've switched identities.
Now what if a domain expires? How does the blacklist get updated? When testsomething-001.com gets expired in a registry, we'll never know. Same if someone decides to reregister it.
Not a bad plan, but blacklisting is still a touchy subject. Any ideas for how to fix that?
--
"I'm not bright. Big words confuse me. But Wanda loves me and that should be enough for you." - Cosmo
Another simple solution would be for ISPs to give out good, advanced filters to all their users, implementing most by default and allowing them to set black and whitelists through an easy-to-use (read: newbie friendly) administration panel. That helps in not receiving the spam at all at the ISP level and reduces our bandwidth consumption.
I'm sure blocking it from even entering your mailbox will help a lot, although it may not help in elimination. Apart from the crappy filters on webmail services, I haven't seen an ISP that gives this functionality - directly check against the user's blacklist and bounce/delete the spam off at the inbound MTA level itself.
I don't know if I explained it the way I meant it but I'm in a damned hurry. Good luck to the lets-finger-the-spammers-away dept, although I doubt that'll work out either.
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.
Good questions, actually.
The short answer is that if you are willing to buy domains and spam from them, there is relatively little anybody can do about it with any system.
However, you not only have to register the domain, you have to host it somewhere. Obviously, the current IP based blacklists don't go away, so your IP gets blocked as well.
However, the idea here is to be able to identify WHO YOU ARE - to be able to track the spam back not just to spammer.example, but to Joe Blowe at 1234 Pink Tinned Meat Lane, FL. If I can trace the mail back to your server, I can get your name. Ideally, it should be in WHOIS, but failing that I can file a subpoena and get it.
As for how to blacklists expire - I would propose a geometricly increasing timeout: first offence, blacklist for a week, then 49 days, then 343 days, etc.
www.eFax.com are spammers
Continnuing on the blacklist problem. Even if it is geometric, what if an IP finally gets decomissioned, either via ARIN et al or an ISP for a particular user... now you have the problem of a user/isp having to figure out to talk to ARIN because they are black listed. Who do you trust when an IP should be reinstated?
It's a difficult problem, I know. Any system, for good, or for awesome.. or for evil for that matter, has its exploits you can't get around. Look at the Xbox. "You can't modify hardware!" But alas, you can.
--
"I'm not bright. Big words confuse me. But Wanda loves me and that should be enough for you." - Cosmo
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).
True, but that is no worse than the situation now - for example, my ISP has blacklisted netvision.net.il because they are infected with a virus and won't clean up their act.
They will remain blacklisted ad infinitum, since it is unlikely they will be able to notify us if and when they clean up their act.
However, again the idea is to bring pressure to bear quickly upon the spammers, that they are removed from the system before they make any money, and wither and die.
www.eFax.com are spammers
Postmaster is a special account; as per RFC: any machine running a SMTP server must have a valid postmaster mailbox read by a human, and
therefore: (1) it should be assumed valid, and
(2) attempts to validate the sender of mail directed to a postmaster account shouldn't be made.
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
The US Imperial system is waaay in the past.
Overused Matrix references. Lots of overused Matrix references.
09
My spam problem has already been solved.
Yes, you read that right. No, I'm not full of shit. (Ok, maybe I am, but not on this point.)
Anybody who wants to email me knows that they have to put a certain phrase in the subject line. I've set up the filters in Kmail so that anything that doesn't contain that phrase goes into the void and I only see the stuff with the phrase.
So when I give out my email address to someone so they can write me, or when I reply to somone, I give them instructions on what is required.
I still get about 200 pieces of crap a day, but I am never bothered by them. It's a little drastic because there are times when you want somthing unsolicited. But with 200 items per day that didn't have any value, email was something I just couldn't use.
And there's another point that the spammers just don't get. Of all the people I've talked to, most people don't use email as often as they once did. Some have given it up altogether. Why? Because of the spam. So here you have people paying to advertise and yet they are hitting so hard that the use of the media is decreasing. Spam is self defeating.
Obviously the people with the money just don't get it.
They rarely do.
. Quit playing Monopoly with Bill. Switch to one of many non-Microsoft products today.
Let's all go back to smoke signals! Ooops, nevermind...I'm sure the spammers would find a way to get around that, too. They'd probably start huge fires and call it "marketing."
Mr. Bond, they have a saying in Chicago: Once is happenstance. Twice is coincidence. The third time is enemy action.
SMTP, in it's True RFC sense does not have these features.
Mail serverd do have these features.
There's a HUGE difference between Mail servers and SMTP servers.
Dolemite
_________________
Save the World! Use a Quote!
Scott Adams now requires the word "dilbert" to be in the subject line of all e-mail sent to his AOL address... everything else is trashed, presumably.
DEAR MR. ADAMS,
I am writing to you with utmost urgency from Lagos, Nigeria. This is an investment opportunity that you will not want to miss. Ten million dollars in gold bullion has been discovered in a bank account in my family's name. But due to our current cash flow situation, we cannot afford the outrageous bank processing and legal fees to take possession of this gold which is rightfully ours. I am proposing that your kind self wire me $10,000 U.S. to cover these fees, and in return you will receive one million dollars wired to your account after we take possession of the gold. Please respond. Time is of the essence.
Swinhar
Ah Ha! So that's where that damned spammer lives!
Should have been obvious, really.
This is my
--An Oldie, but a Goodie!