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