On Sat, 6 May 2006, Hector Santos wrote:
I don't disagree with the need for a fix. I disagree with the low ball SWAG
of 10 limit for lookup mechanisms. It is too low IMO and I would venture a
PERMERROR is premature for many older SPF large organizations records. For
all intent and purpose it places an artificial limit on the total domains
(10) a large site may use.
The SPF results must be deterministic. PERMERROR means the record cannot
be evaluated - either because of syntax or a semantic error unlikely
to go away on its own, e.g. missing SPF for included domain or too
many DNS mechanisms.
The DNS limit does not limit the meaning of SPF records. Any
SPF record can be replaced with a record containing only IP4 mechanisms.
This is called "compiling" the record. The TTL of the compiled record is the
minimum of all DNS TTLs encountered while compiling. A large domain
could published the compiled record, refreshed within the TTL. hotmail.com
appears to do something like this (whether manual or automatic is unclear).
An EXISTS clause usually has a low TTL - but another way to avoid the SPF DOS
limit is to simply use your EXISTS server to define the result. There
are no limits on what it can do.
I would think, that if I was in the loop when this was being decided, I
would suggested that the end result should be the same. If other words, if
the complete exhausted result is a SOFTFAIL, then the cut off would be a
SOFTFAIL as well.
The default (all) result is definitely NOT a good result for too many lookups.
It fails miserably for reverse logic records. There needed to be
a deterministic result distinct from any normal results. The result cannot be
determined from the record - because the record "can't" be evaluated. SOFTFAIL
would have been a deterministic result - but already meant something very
different. PERMERROR (formerly called "unknown") is the RFC deterministic
result for records that cannot be evaluated. If the record does not stay
within the (admittedly arbitrary) DOS limits, it cannot be evaluated, and the
intended result is unknown - i.e. PERMERROR.
That said - remember that the RFC determines what the SPF *result* is.
It does *not* determine what you do with your mail. You are perfectly
free to accept mail with a PERMERROR result. What I do in case
of PERMERROR is to apply some heuristics to "guess" the intended
result.
For instance, if it hits the 10 limit, I record PERMERROR as the official
result, but keep evaluating until it hits 40. If the evaluation terminates
within the (equally arbitrary) limit of 40 - that is the "guessed" result, and
I treat the email accordingly. The Received-SPF header field records the
official result. I add an additional X-Guessed-SPF header to record the
guessed result.
So, for instance, I would not reject mail from microsoft based on SPF -
but they would get a warning DSN alerting them to the PERMERROR.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com