"Lars Dybdahl" <ldy(_at_)cohaesio(_dot_)com> writes:
I totally agree. The SPF record should be valid for the time of
receipt, and there should be no significant delay between the receipt
of an e-mail and the SPF check, so this is all not necessary.
I was thinking the same thing earlier and that the feature was primarily
useful for delayed testing of messages in corpora and such, but you
forced me to think a bit more about this.
I concluded that yes, there sometimes may (and perhaps should) be a
significant delay between the receipt of an email and the SPF check.
1. message with indeterminate status (uncertain spam vs. ham,
SpamAssassin score of 4.5, or spam probability of 50%) is put into
purgatory and after some delay is tested again
2. SPF query fails for some reason, may want to test message (including
the SPF result) later
3. user installs anti-spam software and wants to check/filter messages
they've already received
4. any analysis of a spam, virus, etc. after it has been received
Of the above, I've done 1, 3, and 4.
Also, the argument that someone else made about this turning SPF into a
"change history" is completely bogus. Nobody claims the zone serial
number is a change history and yet it is usually pretty much the date.
(No, I'm not proposing a serial number, just proving the argument is not
valid.)
I've already noted that the field would be optional, used to indicate
that messages older than the setting cannot be reliably tested using the
current SPF record. It's there only if a site wants to use it. If you
use SPF as a received and you want to assume now is always now, you can
do that too.
Daniel
--
Daniel Quinlan anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/ and open source consulting