On Sat, 2004-09-04 at 21:45, Stuart D. Gathman wrote:
Python Milter SPF gets it right:
$ python2.3 spfquery.py -ip=212.56.100.58
-sender=dist(_at_)mcivta(_dot_)city-fan(_dot_)org
pass
spfquery: domain of mcivta.city-fan.org designates 212.56.100.58 as permitted
sender
Received-SPF: pass (spfquery: domain of mcivta.city-fan.org designates
212.56.100.58 as permitted sender) client-ip=212.56.100.58;
envelope-from=dist(_at_)mcivta(_dot_)city-fan(_dot_)org; helo=None;
It looks like libspf2 might not be using the correct domain for the
redirect. However, the final SPF record depends on PTR - and I can
suggest another posibility from bitter experience. About every
3 months, our ISP deletes all our PTR records ("What - who uses those
these days?"). I have learned to avoid using ptr in SPF under those
circumstances. If that happened, then all the implementations may
be right - some just don't have the PTR cached anymore.
I've changed the ptr to an ip4 mechanism for the time being at least and
libspf2 is now returning the correct result (I may change it back when
libspf2 is fixed and some time has elapsed to allow for deployment).
I'm not terribly concerned about the stability of my ISP's nameservers;
I've never had a problem with them so far (touch wood). I originally put
the ptr mechanism in for the sake of brevity (it's shorter than a
matching ip4 mechanism, and doesn't need changing if I add hosts to the
domain) but the ip4 mechanism is admittedly more efficient from a DNS
usage perspective.
Paul.
--
Paul Howarth <paul(_at_)city-fan(_dot_)org>