Advertisement
Interested in hardware, diags, validation, Linux, C, ARM, Microcode and low level programming and blazing networks?
| |||||||||||||
|
| |||||||||||||
That much trouble?That much trouble?Posted Sep 5, 2004 19:16 UTC (Sun) by philips (guest, #937)Parent article: Debian rejects Sender ID
I cannot get it: piece of software proved to be ineffective causes that much trouble?
Why just not try to develop another protocol and finally retire POP3/SMTP/IMAP?
Why cannot open source developers try to come up with some simple protocol? - and implement
P.S. ssh did not need years to come up with ways to detect identity forgery - why it takes that
(Log in to post comments)
That much trouble? Posted Sep 5, 2004 19:29 UTC (Sun) by philips (guest, #937) [Link] [Follow up]
Sorry - we need to retire only SMTP. POP3/IMAP are already support authentication.
If we will draw a parallel with IP addresses - e-mail addresses are not much different.
When we build a new house - it takes time for post office to assign new address. Probably e-
e-mail assignment must be slow and complicated process. So if someone tries to make up a
P.S. Maintenance of registry will cost some money - that's true. But if every one will pay one cent
Umm... I hate to take away your last example Posted Sep 6, 2004 1:26 UTC (Mon) by Ross (subscriber, #4065) [Link] But please google for SMTP authentication. SMTP auth exists and is supportedin all the major MTAs. Getting people to use it is another issue.
Umm... I hate to take away your taking away of the last example Posted Sep 6, 2004 16:55 UTC (Mon) by gwolf (subscriber, #14632) [Link] It does not solve the problem. SMTP authentication makes it necessary for you to authenticate with a server in order for it to accept your mail and relay it. It does not, however, require anything from you in order to deliver you a message created somewhere else for a local user.The problem with spam is that it is too easy to set up a simple SMTP server. It is so easy that hundreds of people do it even without knowing. It is also an important problem with viruses/worms: You might not even know you have a SMTP client in your machine happily sending mail everywhere it can!
Umm... I hate to take away your taking away of the last example Posted Sep 7, 2004 1:10 UTC (Tue) by Ross (subscriber, #4065) [Link] I basically agree with your first paragraph. SMTP authentication doesn'tprevent receipt of spam, but it does prevent anonymous sending of spam.
You lose me in your second paragraph. Spammer's don't need to run SMTP
That much trouble? Posted Sep 5, 2004 20:29 UTC (Sun) by nigelm (subscriber, #622) [Link] > Why just not try to develop another protocol and finally retire POP3/SMTP/IMAP?
Well its only SMTP thats an issue here. And the problem is that its a hard problem, and you have an installed based of many millions or maybe billions of installations - and you want to just sweep this away?
You can only do end to end identity management of email if you have a close user group of some sort. Now of course MS could provide that (and AOL used to) - and leave the rest of the world on the outside.
As for the comparisons against ssh, well yes, if you only want the small number of people who can ssh into your boxes be able to email you, then thats fine. I personally need to email people I have never had previous contact with. And I get legit emails from a lot of other people that I have had no previous relationship with, and not even any link to the ISP or company.
If I really wanted full end to end management I might use X400 - but there are reasons thats damn close to dead.
That much trouble? Posted Sep 5, 2004 21:32 UTC (Sun) by khim (subscriber, #9252) [Link] ssh did not need years to come up with ways to detect identity forgery - why it takes that much time to implement it for e-mail? Hmm... Good question... Especially since we had a solution for this problem for almost 10 years: RFC1847, RFC2015, etc. Way before spam become real problem. Yet... there are still this nasty spam problem and nothing is solved. Why so ? Easy. Problem is with users, not with SMTP. What mail users demand is the following: That's all. Since there are no sane way to implement both 1. and 2. simultaneously we end up with all this mess like SenderID and such. That's all. As usual there are no technical solution for social problems: people should either accept spam and live with it or they should accept lack of anonymity. You can not have both.
That much trouble? Posted Sep 5, 2004 22:17 UTC (Sun) by doogie (subscriber, #2445) [Link] pgp-mime has nothing to with allowing one to send mail. It's only for making sure it isn't modified in transit, can't be read by unknown third parties, and that the sender is who they say they are. It has no bearing on mail routers in the middle, nor the mail routers on each end point.
That much trouble? Posted Sep 5, 2004 22:36 UTC (Sun) by khim (subscriber, #9252) [Link] And what SPF/SenderID is ? Easy: it's try to reject mail from someone who's pretending he/she is now what he/she is. pgp-mail does is way better then any patented scheme. Yes, it needs some changes in end-user agents, but SPF/SenderID needs these changes as well! Of you can add proxy in the process. The same as with pgp. If you say: "SenderID is different solution" I'll agree. If you say: "SenderID is better solution" then I want clarifications. It's pretty easy to add "reject non-pgp signed mail" rule to senmail or other MTA - it's just deemed "too intrusive". Thus instead of good and tested solution we're stuck with bunch of half-backed "extensions" and stupid "authentification schemes".
That much trouble? Posted Sep 6, 2004 16:03 UTC (Mon) by TwoTimeGrime (guest, #11688) [Link] > Easy: it's try to reject mail from someone who's pretending he/she> is now what he/she is. pgp-mail does is way better then any > patented scheme.
pgp-mail requires you to receive the entire email before making a decision. SPF does not. That saves bandwidth.
SPF isn't covered by a patent. You can use it. It's working now to stop joe-jobs. See this link for a good overview: http://yro.slashdot.org/comments.pl?sid=119211&cid=10...
> Yes, it needs some changes in end-user agents, but SPF/SenderID
SPF does not require a change in end-user agents. It can and does work at the MTA level.
"It's not a bug ... it's a feature" Posted Sep 6, 2004 18:42 UTC (Mon) by freemars (subscriber, #4235) [Link] pgp-mail requires you to receive the entire email before making a decision. SPF does not. That saves bandwidth. The bandwidth costs the spammer (or the major ISP which doesn't block mail from zombied computers) as much as it costs you. You can do your part to drive the cost of spam up. Think of it as a tarpit. Further downthread people are saying how PGP'd spam would do more to hurt encryption than spam; they're probably right (imho).
That much trouble? Posted Sep 5, 2004 23:02 UTC (Sun) by Russell (guest, #1453) [Link] It may be possible to satisfy both 1 and 2.
1. Satisfied by only accepting mail from a list of authorised. Use signatures to do this. We then need only protect the keys from viruses. That is a problem programmers can solve ( not a social issue ).
2. Allow people to send spam. ( Nobody will be listening anymore )
That much trouble? Posted Sep 6, 2004 1:36 UTC (Mon) by khim (subscriber, #9252) [Link] Right, but... Try to think about it again. When I talk about 2) I do not talk about professional spammers! I talk about normal lawful internet citiziens. They do want to send anonymous mail to this or that website and/or to this or that mailing list. All the time. It's not some obscure twist - a lot of peoples become very nervous if you'll suggest some theme when mail can be easily tracked to physical person. This is good and all, but... if you can not trace back "normal" sender (who never even seriusly attempted to to cover tracks!) how the hell can you ever hope to trace back professional spammer ? This is what I meant above: people somehow think magic SenderID or something can make spammers easily trackeable but still will not affect anonymity of "lawful citiziens". It's impossible. And if you'll trink about it pgp-mail does exactly what you're proposing. It was around for more the 10 years. It's still not widely used. Why ? Since pgp-mail (once you'll demand correct signatures with keys registered on few well-controlled key-servers) will "greatly affect privacy - and we do not want it". But if you got privacy then why can not spammers get privacy the same way (no matter what authentification scheme is in use) ? Think about it...
The expectation of anonymity issue Posted Sep 6, 2004 5:33 UTC (Mon) by eru (subscriber, #2753) [Link] Why so ? Easy. Problem is with users, not with SMTP. What mail users demand is the following:1. I do no want to get spam (== mail from unknown anonymous recepients). 2. I must be able to send spam (== anonymous mail via unregistered ISP). I'm certain most users would be very happy to compromise on 2 if it would ensure 1. Until some years ago, most ordinary users actually assumed that "from" e-mail addresses are reliable and messages are traceable. It did not deter them from using e-mail. Only the spam catastrophe has made people more widely aware that the "from" field is just an arbitrary text that may have no relation to reality. Set up an alternate e-mail system that has no anonymity, but no spam or viruses either, and I think a lot of users would be interested.
That much trouble? Posted Sep 6, 2004 10:23 UTC (Mon) by ikm (subscriber, #493) [Link] The truth is, people WANT to live with spam. Because they tend to accept the offers from the spam letters. No one would ever send a spam otherwise, because it just would not help advertising.
So, it is actually a possible scenario, where people can both 1) have a possibility to send the spam and 2) never receive any spam at the same time... but not on that planet, or at least not today or tomorrow. The possible social solution against the spam in that manner would be for the mail filters to get each detected spam message through, but with the banner attached to each message explaining why all the spam should be ignored regardless of the offering in it. But it is really hard to change people that way.
That much trouble? Posted Sep 5, 2004 22:25 UTC (Sun) by neilbrown (subscriber, #359) [Link] Why cannot open source developers try to come up with some simple protocol? - and implement it for exim/postfix/sendmail. After all, this packages route crucial amount of post on internet - and all of them are open source.They did. It's called "SPF". Lots of people have said how flawed it is, but as long as you have your expectation set right, it does a completely adequate job. By "expectation", I mean it doesn't defeat spam, and it doesn't defeat phishing, but then it cannot as those are both very much human-factors problems. It can defeat forging, and this is an essential input to any automatic tool which could help attack spam and phishing. As far as I could see, SPF was pretty much on track right up until IETF got involved....
That much trouble? Posted Sep 6, 2004 1:38 UTC (Mon) by jamesh (subscriber, #1159) [Link] I cannot get it: piece of software proved to be ineffective causes that much trouble? What makes you say that SPF and/or SenderID are ineffective? If you are referring to things like the recent Register article, then you are missing the point. SPF is about authenticating that a piece of mail came from where it says it came from. The fact that you can authenticate that a message comes from the sender does not mean that it is not spam. However it might prove that the spam came from a domain owned by a known spammer, which might be useful to your spam filter. Authentication will also mean that if you get a message from your bank, it will have come from your bank rather than a phisher. And it should virtually stop the spread of mass mailing email viruses that forge the sender address (something that should please people not using Windows ...). Of course to be effective, any of these protocols need wide adoption. The Microsoft patent could very well make Sender ID ineffective, which is what this article is about. However, it looks like SPF does not have this problem.
That much trouble? Posted Sep 6, 2004 2:59 UTC (Mon) by paulj (subscriber, #341) [Link] SPF in providing a check that a mail comes from an MTA which is authorised to send for that domain, breaks many common email setups, forwarded SMTP accounts being the big one. Do i have to go configure my MUA to connect to different SMTP servers for each address I have hosted at different places? What if my ISP blocks SMTP? Ah, use MSA.. what about when ISPs start blocking that?), while doing absolutely *nothing* to solve spam. Indeed, Spammers have enthusiastically adopted SPF and at present the majority of email with valid SPF is spam! SPF: breaks many valid and common SMTP uses and has 0 effect on spam. Yay for SPF!
That much trouble? Posted Sep 6, 2004 6:33 UTC (Mon) by neilbrown (subscriber, #359) [Link] This is a common misunderstanding of SPF.
SPF doesn't break anything and is not expected to prevent spam.
SPF simply provides a score - PASS, FAIL, UNKNOWN, ERROR (or something like that). What you do with that score is up to you.
This score is *not* a measure of how likely it is spam (though there is a correlation today, it is dropping). But that is not how you use the score.
I currently use the score like this: If it isn't PASS, and the mail contains a potentially executable attachment, drop the mail. This kills all mass-mailer viruses at very little cost.
If I ever implement a challenge-response system, it would use the score to say "Only send a challenge if the score is PASS", otherwise you might be spamming innocent people with your challenges. If the score is not PASS, and the address isn't on my white list, then I probably don't read the mail, though a very, very low spam assassin score might let it get through to me.
SPF doesn't address spam *at*all*. It addresses forgery. Once you have eliminated forgery, then other anti-spam measures like challenge-response and white-lists become must more useful.
The "breaks forwarding" is a very common misconception. Rejecting all SPF-fail messages would break forwarding, but such behaviour is not rational. Presumably you know everone who you expect to forward mail you. These sites can be whitelisted (if you trust them) or discontinued (if you don't).
That much trouble? Posted Sep 6, 2004 7:50 UTC (Mon) by khim (subscriber, #9252) [Link] It addresses forgery. Yeah, right. There are 3 millions .com domains. God knows how many in .XX for different countries and so on. More then thousand of new domains are created each day in .com. And I'm not even talking about domains of 3-4-5 level. And the only way to track someone with SPF is to ask domain owner (often - not real person as well). The sad truth is that you can not trace sender with SPF: it's too weak to be used as court argument, for example. Any scheme where you can easily track physical sender will be rejected by masses (we already had one for more then 10 years - PGPmail or S/MIME) and if you can not do it then it'll be useless against spammers. Just like SPF is useless and will become even more useless if the future.
That much trouble? Posted Sep 6, 2004 10:35 UTC (Mon) by neilbrown (subscriber, #359) [Link] I think your understanding of "forgery" must be different to mine.
I mean "sending mail claiming to be from the address of some person, but not really being sent by that person".
It doesn't matter how many new domains there are every day.
It also doesn't matter whether I can track down who actually sent the forgery or not.
It just matters whether I can tell if a mail item is a forgery or not. That is the point of SPF and it does a very adequate job.
That much trouble? Posted Sep 6, 2004 13:44 UTC (Mon) by khim (subscriber, #9252) [Link] I think your understanding of "forgery" must be different to mine. Hmm. Are you sure ? If mail is sent from domain where are no real users at all are registered (just SPF records and some cracked SMTP server) it's forgery or not ? I mean "sending mail claiming to be from the address of some person, but not really being sent by that person". Hmm... What about "mail sent from god knows where and by god knows whom" ? That's the real problem with spam, right ? It just matters whether I can tell if a mail item is a forgery or not. That is the point of SPF and it does a very adequate job. No, it does not. If I'm concerned about my regular correspondents PGP does much more adequate job. And when I'm concerned about others it does not make much difference to me if it's mail from joe@somewhere.com or joe@someplace.com if both joe@someplace.com and joe@someplace.com can not be traced back to physical person. Domain names are meaningless - you need to stop real physical person or you'll fight windmills forever.
That much trouble? Posted Sep 6, 2004 15:20 UTC (Mon) by jamesh (subscriber, #1159) [Link] Hmm. Are you sure ? If mail is sent from domain where are no real users at all are registered (just SPF records and some cracked SMTP server) it's forgery or not ? I wouldn't call that a forgery. The SPF records tell you that the message was sent from a server authorised by the domain name holder. It doesn't tell you whether you can trust the domain name holder though (and has never claimed to).
That much trouble? Posted Sep 6, 2004 15:26 UTC (Mon) by khim (subscriber, #9252) [Link] I do not ask you "is it forgery from SPF point of view". I ask you "is it forgery or not". I know what SPF does. It's just what SPF does is useless: it adds new hoops for "honest" people and adds very small protection against type of forgery used by spammers.
That much trouble? Posted Sep 6, 2004 18:10 UTC (Mon) by marble (subscriber, #2719) [Link] You wouldn't say that when you're treated to thousands of bounces, hatemailsetc, cos some spammer has decided to send email from your address. This happens, SPF offers a solution. SpamAssassin already does a fairly decent job of filing spam away in the bit bucket so with widespread adoption of SPF, I'd be happy. (Yes, it has happened to me.)
That much trouble? Posted Sep 6, 2004 19:42 UTC (Mon) by paulj (subscriber, #341) [Link] But you can protect against bounces with outbound-envelope-cookie schemes like SRS. Further, with SRS, you protect *yourself*, you dont rely on other people to check SPF first before sending a bounce to you.
Unlike SPF, outbound-cookies dont break, the very common, use of SMTP forwards.
SPF! It "authenticates" (cough) mail from my domain, Yay for SPF!
/me uninstalls gnupg
That much trouble? Posted Sep 6, 2004 20:30 UTC (Mon) by rdowner (guest, #3960) [Link] A few months ago I was "joe-jobbed". A spammer, for several weeks, was sending out spams forged to appear from my domain. The invalid email addresses were, of course, bounced back to *me* -- several hundred *a day*. If those mails servers processing the received mail support SPF (and if I had an SPF record on my domain), I would not have bombarbed with the "shrapnel" -- the receiving mail servers would have realised that it wasn't me sending the e-mail and would not have even accepted them for delivery. This would have saved me the problem of suddenly getting hundreds of messages in a short period of time, desperately reconfiguring my mail setup trying to stem the flow of bounces, and inevitably losing some of my valid mail in the process
No, SPF will not solve the spam problem, cure all disease or bring about world peace. But it will solve *some* problems, such as the problem I've just described. There is money to be made in spam and there is no doubt that the professional spammers will find new ways to get the spam delivered. However, today, I believe there is value in SPF - it will stop a class of spam attack (assuming SPF is widely adopted). It doesn't add "hoops" for the vast majority of people, as ISPs will simply need to update their DNS records with info on their mail servers and their end users need take no action (it has been remarked that "mobile" users may have some issues but there are workable solutions to that too.)
regards,
That much trouble? Posted Sep 6, 2004 9:08 UTC (Mon) by jamesh (subscriber, #1159) [Link] The mail forwarding issue is known to the SPF developers, and they have a solution (SRS and whitelists). Getting the solution implemented is part of the problem of getting the system adopted. As for the article you linked to, it is about the same survey as the one I linked to. The results are not that surprising either. If you expect an SPF pass to mean that a message is not spam, then you will be disappointed. One thing that the survey didn't touch on is whether any of the spams received claimed to come from their customers and passed the SPF checks. I'd guess that the answer would be no. As a comparison, would you deploy a spam filter that let through all messages that had a valid PGP signature? I bet that if such a filter was developed, spammers would start generating PGP keys and signing all their spam. If this happened, would you consider PGP to be useless? I wouldn't, since none of the spams would be signed with my key.
That much trouble? Posted Sep 6, 2004 10:08 UTC (Mon) by ametlwn (subscriber, #10544) [Link] I bet that if such a filter was developed, spammers would start generating PGP keys and signing all their spam. If this happened, would you consider PGP to be useless?I would consider pgp to be useless as anti-spam measure. The same way many people consider SPF to be useless as anti-spam measure (except for very short term). I wouldn't, since none of the spams would be signed with my key.None of the mail I receive is signed with my key either, I rarely correspond with myself. ;-) But more seriously, GPG/PGP's functionality indeed would not suffer at all if spammers used it, I'd still be able verify the authenticity of mail signed with a key which I have trustpath to.
That much trouble? Posted Sep 6, 2004 10:41 UTC (Mon) by khim (subscriber, #9252) [Link] The fact is: with PGP you know who to trust and wuth SPF you do not. You trust some random DNS server - and there are literally thousands of points where you can add your server without much checking. SPF is designed with the stupid idea in mind: you should trust any server with valid SPF information. That's absurd. PGP, on the other hand is designed to live in hostile environment: it's not enough to have valid PGP signature in mail. You somehow should be in trustpath. Plus you need to sign each and every outgoing mail - just add requirement to sign From: and To: lines as well and voila - great strain for initial sender (==spammer). Relay do not change signature at all so they are not affected.
That much trouble? Posted Sep 6, 2004 13:29 UTC (Mon) by arafel (subscriber, #18557) [Link] If receiving servers are expected to verify that a PGP signature is valid, that's quite a lot of work added to the machine. If they're not expected to verify it as valid, then what do you gain? You've still received the spam.
Basically, I don't think I understand your point. A mail being PGP signed proves absolutely nothing except that the sender had a copy of PGP. (Or GPG, if you're being picky :)
That much trouble? Posted Sep 6, 2004 13:52 UTC (Mon) by khim (subscriber, #9252) [Link] Argh. Of course receiving servers do not need to verify PGP signature - they do not even need to check if it's there or not. End-user mail agent will do it. And as for "simple PGP signed (by unknown key) mail" being not better then normal mail - it's not. It's harder to create and you can not generate 1'000'000 different PGP keys with ease. Plus if you can not find key on public keyserver - it's reason enough to reject mail. If it's there - you can see about who'll signed it. Read PGP documentation - there are a lot of information about trustpath and such. The fact is: with PGP you can change policy easily and you need only deal with 10-20 public signers while in case of SPF you're forced to trust god knows whom.
That much trouble? Posted Sep 7, 2004 12:19 UTC (Tue) by arafel (subscriber, #18557) [Link] >Argh. Of course receiving servers do not need to verify PGP signature - they>do not even need to check if it's there or not. End-user mail agent will do >it.
Then it doesn't accomplish what SPF is trying to do. A spammer I've annoyed before has used my domain as the 'source' for one of his spam floods. If SPF had been deployed, I wouldn't have received the 100,000 bounces or so that I got.
How do you propose that PGP signing of email would help with that? Because I can't see how it would make any real difference.
Bear in mind that the aim is to drop the mail before it even really enters the system, not to post process it. We can already do that.
>And as for "simple PGP signed (by unknown key) mail" being not better then
So all the spammers will do is use their zombie machines to generate keys and submit them to keyservers. Congratulations, we now have another wrecked resource.
That much trouble? Posted Sep 6, 2004 15:16 UTC (Mon) by jamesh (subscriber, #1159) [Link] None of the mail I receive is signed with my key either, I rarely correspond with myself. ;-) But more seriously, GPG/PGP's functionality indeed would not suffer at all if spammers used it, I'd still be able verify the authenticity of mail signed with a key which I have trustpath to. This is the point that I was trying to get across in my previous message :). A valid PGP signature on its own doesn't prove that a message is legitimate. All it does is prove that whoever sent the message holds the private key. You need something extra to prove that (the web of trust in the case of PGP). Similarly for SPF, a pass only proves that the mail came from a server approved by the domain holder. You would need to combine that fact with other information to determine if a message is legitimate. Both PGP and SPF help prevent third parties sending mail that claims to come from you though, which is their primary purpose (in PGP's case, one of its primary purposes). If you expect either to get rid of spam on their own, you will be disappointed.
POP and IMAP Posted Sep 6, 2004 2:16 UTC (Mon) by Ross (subscriber, #4065) [Link] One thing I never understood is why POP and IMAP never supporting sendingemail, only receiving it. If they had implemented a single protocol to handle both, which included user authentication, then most people wouldn't need an open SMTP server at their ISP to send email. This would have allowed more places to turn off unathenticated SMTP and we wouldn't have as much of a problem with SPAM from home user's systems (we would at least be able to track it down to the correct account).
|
|
||||||||||||