wayne wrote:
In <2ffe01c55889$d5df4430$0600000a(_at_)john> "Chris Haynes"
<chris(_at_)harvington(_dot_)org(_dot_)uk> writes:
I thought this had been discussed and agreed _long_ ago!
This is not my recollection. I went poking around the SPF archive and
the MARID archive and I couldn't find a general consensus on this
issue. However, I could easily have missed some discussions, so if
you can point me to a thread where this issue was resolved, please let
me know.
For what it is worth, this issue of "delayed checking" can be more
than just an issue of MUAs doing checkings. If you send email through
a smart host, and the destination can't be contacted, there can be a
delay of up to a week or two. Similarly, things like greylisting can
cause delays. Some organizations may have a border MTA that then
redirects the emails to various departmental MTAs. These departmental
MTAs can know which Received: headers can be trusted and so they can
accurately do SPF checks, but there may be an arbitrarily long delay
between accepting at the border MTA and the departmental MTA.
Secondary MXes are very similar to the boarder/dept MTA problem.
I guess my point here is that even saying something like "SPF checks
MUST be done during the SMTP session" is far too vague. An email may
go through many SMTP sessions, from the original submission to the
final delivery, and each hop can introduce a delay. If we place all
the burden on the receiving side to do the checking within one DNS
TTL, then that also life hard for senders who use any smart hosts for
any of its email.
Only if the final MTA stays down for longer then the TTL. Do you think
that happens often? Most people running an MTA either have it on a
stable connection (even if it is say cable or DSL), and/or are aware of
the lost mail risks of running an MTA on an unreliable connection that
stays down for extended periods.
I think we could end up with a lot of complicated language trying to
nail all different cases down, when in reality what most people want
is for the probability of a false reject to be very small and that can
be done by both the sender and the receiver trying to do minimize the
problem.
I see the discussion on what to do about policies that change with time.
And I am a proponent of SPF only during SMTP time.
But to keep the others (e.g. SA) happy, how about:
When you evaluate SPF post SMTP, any DNS record you use to determine the
senders policy can only be used if its TTL means that the DNS lookup
could have occurred before the timestamp the message was received by MTA.
I realize this is not perfect, its possible at SMTP time the TTL on the
DNS record was set to say a few minutes, and then a few hours later when
the MUA gets the email the ISP could have finished a migration and have
put the TTL back to say 2 days.
However this is a rare case; generally the lookup result changes more
often then the TTL (the "winding down" example seen earlier as someone
prepares to migrate being the noted exception). But generally when one
is prepared enough to "wind down" for a migration, one is prepared to
have an interim policy that handles the old and new MTA's. Hence no
problem.
Just a thought: shoot it out of the water if that is what it deserves. :)
Terry
-wayne
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
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