Chris Haynes wrote:
My assertion is that, if checking is to be done after SMTP
time, that late checking MUST however be done with a copy of
the SPF policy taken _during_ the SMTP transaction.
Short reality check for this assertion:
"v=spf1 a mx include:isp.example -exists:%{ir}.bl.example ~all"
The later results for q=a, q=mx, q=spf etc. are not necessarily
what they would have been at the time of the SMTP session.
Doing the SPF policy look-up at some time after the SMTP
phase can get totally wrong results, if the policy has
changed.
True, but storing the actual policy string is only a nice try.
I would argue that you would have to add some kind of
explicit 'valid-from-until' time stamps within the SPF record
itself
As you said TTLs exist, reinventing the wheel makes no sense.
And for the normal SHOULD mode of operation the worst you get
is a reject (or a bounce behind any RfC 1123 alias forwarding)
You have got to insist that the SPF policy is collected from
the DNS _during_ the SMTP transaction. That's the only way of
ensuring integrity within the overall SPF1 design.
It's not designed this way, what you're talking about is SPF
restricted to ip4 and ip6 (is this RMX ?), not SPF version 1.
But it's certainly a point for a CAVEAT in the SPF security
considerations, and after -01pre6 took the 100,000 bytes limit
breaking the 100 KB barrier is unavoidable. <sigh />
Bye, Frank