Alex van den Bogaerdt wrote:
On Thu, May 04, 2006 at 06:28:55PM -0400, Terry Fielder wrote:
Unless the IP actually DOES can change for the mail server, read on...
[...]
It can be an indication that the domain owner recognizes that:
1) currently the IP for their mail server is static, so they can save
you a DNS lookup by giving an IP ref
2) the IP for their mail server might change e.g. in an ISP outage and
they cutover the mail server to their redundant connection
So for a remote possibility that may happen in a distant future,
thousands of mail receivers are asked to waste resources?
If they are switching over to a redundant connection this means they
are going to alter their A records into something else; why not alter
the SPF record at that moment as well?
Caching is a real issue here. The scenario:
1: I receive mail from them. I lookup their A records.
2: something bad happens, they switch over to their alternate connection.
3: I receive mail from them. I use the cached records pointing to
the previous (now wrong) location and reject their mail.
Sorry, no. The whole point of putting the IP in the SPF record is that
prior to the cutover to redundant connection the IP is a match, so you
never do a DNS lookup on the A record (you return SPF pass or whatever
mode assigned)
NOW pretend critical failure happens, and cutover to new IP
New mail and now the IP is NOT a match, so NOW you proceed to get a
match on the balance of the SPF record, thereby doing an A lookup and
now the A record is pointed to the new IP. (Caching can still present a
problem if a cached stale lookup exists from some other query, e.g.
anti-spam reverse and forward lookup checks etc)
If they want to have a minimum amount of problems at switch over time,
their A record must NOT be in my cache so it must not be in their record.
Even then, I am probably going to use my cached copy of their TXT record
and things are not what they expect.
The cached version of the TXT record presents ZERO problems, because the
A part was not looked up until after the failure that caused cutover.
The solution: have the ip address(es) of their redundant connection in
the record as well. Most likely something like "ip4:192.0.2.0/24" but
change the ip address range in something appropriate.
Doesn't work for those whom the second connection is allocated as
needed. Hence you don't know the IP in advance. Most good secondary
connections are truly redundant. But not all.
But your point is true for those whom know the redundant IP's in advance.
Terry
Alex
-------
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 subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Terry Fielder
terry(_at_)greatgulfhomes(_dot_)com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085
-------
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 subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com