Simon Leinen wrote: > > When they have solved it, > > Maybe there's nothing to solve here...
What about fixing the documentation (eg http://spf.pobox.com/mechanisms.html#ip6) and then also all the tools using it ;) Claudio Jeker wrote: > On Tue, Nov 09, 2004 at 11:38:56PM +0100, Peter Keel wrote: > > * on the Tue, Nov 09, 2004 at 08:49:25PM +0100, Claudio Jeker wrote: > > > Porbably you did not notice but SPF is dead. > > > So let it rest in peace. > > > > Standards aren't made just because some working-group decides on it > > (or not). Besides, Wasn't it Sender-ID that was killed? Explain. > > > > First of all it is broken or breaks many valid applications. e.g. > forwarding does not work correctly and user that are forced to use some > smtp proxy will have issues too. Indeed everybody doing some kind of forwarding will have to suddenly adjust to SPF. Major providers have, at least they say, already done so apparently: $ dig +short aol.com txt "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all" "spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all" $ dig +short msn.com txt "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf- c.hotmail.com include:spf-d.hotmail.com ~all" $ dig +short hotmail.com txt "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf- c.hotmail.com include:spf-d.hotmail.com ~all" $ dig +short gmail.com txt "v=spf1 a:mproxy.gmail.com a:rproxy.gmail.com a:wproxy.gmail.com ?all" This at least makes it somewhat impossible to send fully automated spam from those domains, saves some of the junk ;) > Additionally it is useless. Currently 90% of SPF verified traffic is spam. > SPF does not prevent spam it is a user verification system and it does > that very bad. Use crypto instead. The trick with SPF is that you at least know where the spam originates from. Thus that the domain doing SPF is also the source for the spam or virusses etc. Thus this at least limits spammers/virusses abilities to send a spam with your from/return-path etc. Nevertheless this indeed does not solve some spamcorp setting up 10k domains, nicely with SPF records and spamming all the way... But they don't claim that anywhere either. That is where some crypto stuff could come in, would be neat to have a (computationally) expensive signing method that is very light to verify. I'll stick to sending PGP signed mail. The SPF docs mention that there could be a mechanism for this, thus 'accept only PGP signed and verifyable mail from this domain', but this has not been specified yet, I think it also has to do with the distribution of pgp keys, then again, upload them to pgp.mit.edu and it should become quite available. Maybe something like a '_pgp._tcp.<domain>' SRV record pointing to the pgp server for that domain could help there though. Would save on quite some backscatter from misconfigged antivirus stuff, but then again people who don't maintain those boxes don't update to support SPF nor anything else and that is where the problem lies, next to the 'the law doesn't follow the spam money' Also... http://www.rhyolite.com/anti-spam/you-might-be.html Greets, Jeroen
signature.asc
Description: This is a digitally signed message part
