On Thu, May 04, 2006 at 08:40:03PM -0400, Terry Fielder wrote:
But SPF was designed to combat forgery so I think I am not way off
base to assume I actually do need to fetch those A records as the
ip4 mechanism did not match. Once those A records are in my cache,
the domain has a problem as those A records point to the original
(now severed) link.
That's my point, once the link is severed, the A records are updated to
the new IP, so the first time you NEED to fetch them they are already
updated to the new IP. (Which takes advantage of the fact that one
You are missing the point.
Some implementations may process the entire record (and this is
allowed!) even if the first mechanism would match. Some implementations
may prefetch all dns requests. Not necessary but still, allowed.
But let's consider an implementation that does no such thing.
SPF combats forgeries so it is not unreasonable to keep that in mind
when looking at SPF records.
1: a connection comes in
2: the sender claims to be "someone(_at_)example(_dot_)com"
3: I fetch the record for "example.com" which looks like the discussed record
"v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 a:host1.example.com a:host2.example.com
4: I compare the connecting server to the 1st ip4 mechanism. No match
5: I compare the connecting server to the 2nd ip4 mechanism. No match
6: I compare the connecting server to the 1st a mechanism. No match
7: I compare the connecting server to the 2nd a mechanism. No match
8: "all" matches and I return FAIL
There is only one way to do steps 6 and 7: fetch the A record and use
the returned ip addresses. This means "host1.example.com A" and
"host2.example.com A" are now in my cache. They are going to stay
there for 24 hours (assuming a TTL of 86400).
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
please go to