In <317301c5591f$17caebc0$0600000a(_at_)john> "Chris Haynes"
<chris(_at_)harvington(_dot_)org(_dot_)uk> writes:
Doing the SPF policy look-up at some time after the SMTP phase can get
totally wrong results, if the policy has changed.
This issue has been discussed before both here and on the MARID list
without a clear consensus about what to do. Both the mengwong-spf-*
drafts and schlitt-spf-classic-* drafts are moot on this issue.
There are kind of two ways to look at this:
* SPF checks done a "long" time after the email was first attempted
to be delivered by the sending MTA run the risk of getting an old
SPF policy.
* Changes to SPF policies run the risk of causing legitimate email to
be rejected unless both the new and old policy remains in effect
until all of the email has cleared the SPF checks.
In practice:
* There are people checking SPF records a "long time" after the SMTP
session finishes.
* There are people changing SPF policies without waiting long enough
to make sure email has cleared, maybe not even cleared their own
MTA, let alone post-SMTP SPF checks.
So, I can see us doing any of the following:
1) remain moot on the subject.
2) Try and retroactively define a strict cut-off time that SPF records
MUST remain valid for X hours/days/weeks and that SPF checks MUST
be done within those X hours/days/weeks.
3) Put the blame of any legitimate email being rejected on SPF checkers
who check "too late".
4) Put the blame of any legitimate email being rejected on SPF
publishers who don't make sure the old policy is still valid for a
"long enough" time.
5) Put some sort of vague warning about this in the draft and let the
publishers and checkers blame each other.
I'm personally leaning toward option 5), but I'm not sure where to put
the warning or what to say...
Maybe add the this to Section 2.3 "Publishing Authorization":
When changing SPF records, care must be taken to ensure that there
is a transition period so that the old policy remains valid until
all legitimate email has been been checked.
And, in the last paragraph of Section 2.4 "Checking Authorization",
add:
3) Legitimate email may fail because the sender's policy may have
changed.
-wayne