...... Original Message .......
On Sun, 15 May 2005 10:17:01 +0100 "Chris Haynes"
<chris(_at_)harvington(_dot_)org(_dot_)uk>
wrote:
"Frank Ellermann" added:
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
Right, Frank.
You are right, you can't take a copy of the (first-level) policy and use it
later. I forgot about inclusions etc.
So my assertion is now that the _only_ time you can, with complete integrity,
collect and elaborate the entire SPF policy is during the SMTP transaction.
Anyone disagree with that contention?
Yes. From this point of view the only time SPF can reliably checked is at the
moment the
message is sent. SMTP time can stretch into days. The point of SMTP time
validation is that
it's easier to get right identities to test against and that you reject instead
of bounce.
If so, please propose the rule we should include in the RFC to define for
how
long after SMTP-time the test will still be valid, and justify your
proposal.
Chris Haynes
A better point might be that it isn't extra-ordinary for an SMTP client to
keep trying to deliver a message that got a 4xx for 4 days. SPF record
publishers need to consider this when modifying their records. This is
likely a much bigger risk than SA checking a second or two after a message
was accepted.
How long after a message is initially sent should it be valid to check SPF
during an SMTP session? Same answer relative to when the message was sent
for post-SMTP checking.
Scott K