[Koen Martens]
antianti.nl --A=> 80.126.206.91 --PTR=> sonolo.xs4all.nl --A=> 80.126.206.91
So i'm fine here.
You do not get point.
Current PTR verification propose to start from resolving IP addresses, not from
antianti.nl domain name.
antianti.nl IN TXT "v=spf1 ptr -all"
This record consumer will perform only this:
"80.126.206.91 --PTR=> sonolo.xs4all.nl --A=> 80.126.206.91"
And there will not be any indication if "antianti.nl" name.
To make email sending from 80.126.206.91 possible you have to list
"antianti.nl" in PTR data in addition/instead of
sonolo.xs4all.nl
Or you can freely use
antianti.nl IN TXT "v=spf1 a -all"
and IP check will be performed like:
"MAIL FROM: user(_at_)antianti(_dot_)nl -> Extract domain name -> Obtain SPF
record -> A found -> Obtain all IPs for antianti.nl name ->
Check if currently connected IP in list"
You DNS configuration is no way related to SPF PTR proposal and serve as
additional example against PTR
Even if I had no control, if the A of sonolo.xs4all.nl would not be
80.126.206.91, my ISP has a serious error in their
setup, and I can apply contractual agreement on them to fix it or something.
One more example. Directly from SenderBase.org homepage
http://www.senderbase.org/?searchString=local.customer&searchBy=domain
Do think they will believe you that "local.customer" new TLD is an "serious
error in their setup" ?
LOL
This does not prevent them from spamming effectively.
--
Andriy G. Tereshchenko
TAG Software
Odessa, Ukraine
http://www.24.odessa.ua