This is no problem i think, if you do a PTR lookup for the ip, take the first
resonse and do an A lookup on that, you still get the original ip back,
don't you? So no problem there. If you do get another IP, something is
wrong with the dns setup, right?
What is reason to do PTR lookups in SPF ?
What benefits it provide to us ? We no longer use rlogin, rsh-like auth with
/etc/hosts.equiv and .rhosts
But I know at least one ISP (mine) who unable to take control over PTR records
for thier 62.16.0.0/19 zone.
Some unknown problems with RIPE
Will PTR mathing benefit me or result in problems ?
Or you will create expection for situation like mine ?
No PTR record - nothing to check.
Or you never sow common PTR records misconfiguration like Microsoft one ?
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200407/0469.html
IMHO, Using PTR records are evil.
Almost all ISPs list PTR records like (random sampling)
46.86.24.202.in-addr.arpa name = g202-24-86-46.nakanishi.ac.jp
44.135.128.207.in-addr.arpa name = unspec207128.honda.com
44.16.15.151.in-addr.arpa name = ppp-44-16.15-151.iol.it
Does it mean all thouse IP allowed to send email from ac.jp, iol.it or
honda.com domains ?
I do not understand "3. Applicability Statement" section from Unified 4-ptr.txt.
As well 1.1.1 section:
"Mail receivers are NOT REQUIRED to perform the operations described herein."
Using PTR as optional feature will complicate proposed technology without real
benefits.
SPF must provide error-free road to accept "SPF-Status: pass" in near future.
Optional feature like PTR (that can result in "SPF-Status: none") create a lot
of little stones on this road.
Somebody will rely on it and expect to get "pass" status, as result we will be
unable to move all resulting "none" status
emails (becouse of "NOT REQUIRED" PTR checks) to trash can.
Good luck,
--
Andriy G. Tereshchenko
TAG Software
Odessa, Ukraine
http://www.24.odessa.ua