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.
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.
-wayne