Reviving the Finger Protocol to Fight Spam? 113
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?"
More RBL needed? (Score:5, Insightful)
Then you'll have to blackhole those servers.
Re:More RBL needed? (Score:3, Insightful)
Re:More RBL needed? (Score:2)
Re:More RBL needed? (Score:2)
Re:More RBL needed? (Score:2)
Give Spammers the Finger eh... (Score:3, Funny)
i think its already in the SMTP protocol (Score:1)
I know it exists on SMTP on windows servers not sure about non-windows smtp servers.
Re:i think its already in the SMTP protocol (Score:3, Interesting)
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?
Re:i think its already in the SMTP protocol (Score:3, Insightful)
Re:i think its already in the SMTP protocol (Score:2, Insightful)
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
VRFY works, but may be shut off...alternatives... (Score:2)
% 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.tl
Re:VRFY works, but may be shut off...alternatives. (Score:4, Informative)
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: <>
Re:i think its already in the SMTP protocol (Score:1)
someone healthy and active i guess
mail is always going to come from "a valid user" at some point in the trail whether that person is bouncing it off open relays, or using a myriad of other anonymous services. i don't think you can have both privacy of information and full accountability of everyone who might send you
Re:i think its already in the SMTP protocol (Score:2)
You wouldn't (currently) be able to enforce VRFY or FINGER as being required to accept emails, although it could be used as a way to cut down on false positives in spam-filtering. I.E. If you get something that looks like borderline spam, the last check would be to attempt to VRFY the sender. If it succeeds, then classify it as non-spam. If
Why switch protocols? (Score:1, Interesting)
Re:Why switch protocols? (Score:2, Insightful)
I think it's interesting, though useless. (Score:4, Insightful)
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
kids and spam.. (Score:5, Insightful)
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:
Re:kids and spam.. (Score:1)
Re:kids and spam.. (Score:4)
People shouldn't have to make an effort to block this slime, and certainly not the near-heroic effort that is needed to block even 50% of it.
If they catch these asshats, they should charge them with child molestation.
Re:kids and spam.. (Score:2)
Re:kids and spam.. (Score:1)
Re:kids and spam.. (Score:2)
How about a ".kids" domain for email, to which sending such 'explicit' spam is strictly FORBIDDEN?
Re:kids and spam.. (Score:1)
Did i forget to mention the address has only ever appeared on kid-oriented sites?
Oh yeah, I did mention that..
Thanks for playing.
Re:kids and spam.. (Score:2)
However, the spammer has no idea that a specific site only has kids related material. Nobody can classify web sites as to the type of content on them in an automated way. It's why Yahoo had human doing the classification for the longest time. It'd be entirely too much work for the spammer to check all the sites his e-mail addresses come from (so I think the we should require the spammer to do so).
Saying that it's only on kids sites is a red herring, spammers don't read the s
Re:kids and spam.. (Score:1)
Re:kids and spam.. (Score:1)
Also, what's to stop anybody else from signing up for a '.kids' email address in the hope that they wouldn't receive this sort of spam? Unless you can prove that people using it are in a certain age range, you're not going to be able to "forbid" sending of explicit spam to
Re:kids and spam.. (Score:2, Funny)
Re:kids and spam.. (Score:1)
Re:kids and spam.. (Score:1)
Certainly the 6 o'clock news shows like to point out a pedophile contacting a child over the internet (gasp!)* whenever they can.
* as in "Don't you dare think of using the evil internet, or letting anyone you know look at it, instead of watching the sacred television."
Verify the username *and* message-id (Score:2)
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
Re:Verify the username *and* message-id (Score:2)
This would break nearly every major ISP's SMTP setup.
Any large-ish ISP (over 200 subscribers or so) will use different servers for inbound and outbound mail.
Not to mention that it would completely screw anyone who uses email addresses that don't correspond to their ISP. (ie. I send mail from home, using my work email address - how
Re:Verify the username *and* message-id (Score:2)
This would break nearly every major ISP's SMTP setup.
Spam costs ISPs lots of money; I expect most would reconfigure their servers to help stop it.
how is my work mail server supposed to know what the SMTP ID is of a mail it will never see?
The whole point of my scheme is to prevent people using a mail address other than what they are actually posting on; if you want to use your work email address, make it a Reply-To:, and have the From: field contain the address you are really posting from.
Re:Verify the username *and* message-id (Score:2)
It's not a matter of "reconfiguring their servers" - it's a matter of PERFORMANCE.
The whole reason that it's done this way is because one machine would not be capable of handling it.
The whole point of my scheme is to prevent people using a mail address other than what they are actually posting on; if you want to use your work email address, make it a Reply-To:, and have the From: field contain the address you a
Re:Verify the username *and* message-id (Score:2)
--No.
--The solution is to find a spammer that has sent this garbage to children, whether "with intent" or not, and do the following:
o Prove beyond reasonable doubt that this is the guy.
o Drag him by the hair out of his house.
o Call the local news affiliate.
o PUBLICALLY EXECUTE HIM. On Live National TV. (I doubt there's a jury in the COUNTRY that would convict you, esp. if the spammer lives in the South.)
--Set a few graphic examples and watch the in
Re:Verify the username *and* message-id (Score:2)
FROM budgenator@example.com just make sure that the email at least went through example.com. I'm not sure if this would be easier in the pop3 client or the SMTP server. see my journal entry for other ideas I've had on Fighting spam [slashdot.org]
Re:I think it's interesting, though useless. (Score:2)
That is bull... There are plenty of ways to stop automated e-mail guessing/harvesting in ways that really can't be overcome.
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.
With that system, there is no feasable way to build a collection of e-mail addresses. Even if it were, it would probably cost a bit more, and be more difficu
It's identd (Score:4, Interesting)
Re:It's identd (Score:3, Interesting)
Spamming is not a technical problem, it's a social problem.
Here's my suggestion; Most ISP's need to add a clause in their ToS that CLEARLY defines spamming (Bulk unsolicited email, commercial or not) as unacceptable, that violaters WILL be blacklisted and that they will be charged a suitable 'cleanup' fee.
First Amendment; doesn't apply, this is a private compan
Re:It's identd (Score:2)
But you're right -- spamming is a social problem, and there's very little we (sl
Re:It's identd (Score:2)
Re:It's identd (Score:1)
Not an uncommon sight (Score:5, Funny)
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
Re:Not an uncommon sight (Score:2)
Re:Not an uncommon sight (Score:2)
You're forgetting wiring Uganda.
Re:Not an uncommon sight (Score:2)
Re:Not an uncommon sight (Score:5, Funny)
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
Response: I have a Simpson's quote that might help you out, will that be enough?
Re:Not an uncommon sight (Score:1)
Sure, let's hear it!
Re:Shoot them all (Score:1)
Re:Shoot them all (Score:2)
Re:Shoot them all (Score:1)
unfortunatly not helpfull (Score:1)
Edgar
"We need a new protocol!" (Score:4, Informative)
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...
Re:"We need a new protocol!" (Score:1)
Maybe you're right and SMTP can become a spam-free email system. But consider this: Email is universally embraced because of the reasons you listed, but it is quickly losing that acceptance because it is becoming harder to understand, less standardized or plain not worth the effort, largely due to spam and anti-spam measures. Something has to be done.
Does everybody have to switch at the same time? Certainly not. A good system can run in parallel. When people see that they don't get spammed with the new sys
Re:"We need a new protocol!" (Score:3, Interesting)
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 d
Re:"We need a new protocol!" (Score:2)
It's been enough, time after time, to get an ISP to boot a spammer. Including Rizler and Ralsky. It's abuse, too. As abuse it's perfectly within the rights of the owner of the system being abused to not deliver the spam and to give no notice of non-delivery. If you do this on a system with no real email function you will almost certainly never touch any valid email. Only by very strange circumstances should valid email ever come
no. (Score:4, Insightful)
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???'
Re:no. (Score:3, Informative)
sendmail -fpresident@whitehouse.gov spamrecipien@dot.com
Hello dear...
.
OR from any OS
telnet blahblah.example.org 25
mail from: president@whitehouse.gov
rcpt to: my favourite spamrecipient...
data
blahblah
.
Re:no. (Score:3, Funny)
Re:no. (Score:3, Informative)
Why blame Unix? As long as you have the ability to open a telnet to the outside world (port 25, to be more precise), you can do it from any connected machine.
Heck, I remember telnetting to the victims' MX servers and typing in the message by hand. It wasn't too difficult.
Re:no. (Score:1)
Received: from whitehouse.gov ([64.110.8.7]) by
A simple reverse lookup tells the recipient that the sender is bogus.
Re:no. (Score:2)
(And yes, you can turn this off if you really want to.)
New pr0n spam... (Score:2, Funny)
Fingering my mom (Score:1)
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...
SMTP needs to die! (Score:2)
Re:SMTP needs to die! (Score:4, Insightful)
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.
Re:SMTP needs to die! (Score:2)
I duno what planet your from, and I doubt you've read the RFC's regarding SMTP on Earth... cuz the above statements clearly shows your ignorance in the SPAM issue. SMTP can be abused because it is flawed despite what you desire, or perceive, to be true. SMTP is wide open to Spam from an era of wide open, non-security minded protocol design.
In regards to your silly statement about SMTP not being flawed, security wise... I believe Mark Tw
Re:SMTP needs to die! (Score:2)
And again you're wrong. I have written an SMTP server, working from RFCs.
the above statements clearly shows your ignorance in the SPAM issue
No, they show that you have a closed mind.
SMTP can be abused because it is flawed despite what you desire, or perceive, to be true
Then please list the relevant flawed sections. Since you know so much more than me about the RFCs, you should have no problem.
The whole worl
Re:SMTP needs to die! (Score:3, Interesting)
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 blac
Re:SMTP needs to die! (Score:2)
(1) Open relays exist.
(2) Spammers can find them.
The campaign to secure open relays aims strictly at (1). The campaign also ignores RFC 2505, which says this is not the way to stop spam, because of (2).
So if attacking (1) doesn't work isn't it logical to try to attack (2)?
Spammers have an unbelievably easy task when it comes to finding open relays. They just try to re
Re:SMTP needs to die! (Score:2)
The problems with this, and my counter-proposal. (Score:5, Interesting)
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
Re:The problems with this, and my counter-proposal (Score:2)
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 rere
Re:The problems with this, and my counter-proposal (Score:2)
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 Mea
Re:The problems with this, and my counter-proposal (Score:2)
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!"
Re:The problems with this, and my counter-proposal (Score:2)
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.
Re:The problems with this, and my counter-proposal (Score:1)
Ah Ha! So that's where that damned spammer lives!
Should have been obvious, really.
Re:Don't just edit SMTP, Replace it (Score:2, Informative)
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 IC
blah blah blah bye bye e-mail (Score:2)
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
A Simpler Solution (Score:1)
Re:A Simpler Solution (Score:1)
How about... (Score:1)
So what do you need? (Score:2)
ISPs (Score:1)
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
Finger Finds Faked "FROM" 'Fectively (Score:4, Interesting)
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.
I have a simpler solution. (Score:3, Interesting)
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.
The finger&crypto methods (Score:2, Insightful)
Unfortunately, the finger method solves the wrong problem. As mentioned by others [slashdot.org] 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 amo
Spam Problem Already Solved (Score:2)
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 req
That's all well an good but it's not SMTP. (Score:2)
Mail serverd do have these features.
There's a HUGE difference between Mail servers and SMTP servers.
Dolemite
_________________
Re:That's all well an good but it's not SMTP. (Score:2)
Go old school! (Score:2)
Re:SPOOF-NETWORK,e.g. INTERNET problem (Score:1)