| |||||||||||||
|
| |||||||||||||
That much trouble?That much trouble?Posted Sep 6, 2004 2:59 UTC (Mon) by paulj (subscriber, #341)In reply to: That much trouble? by jamesh Parent article: Debian rejects Sender ID
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!
(Log in to post comments)
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.
|
|
||||||||||||