Frank Ellermann wrote:
Hi, there's an interesting discussion about SPF in the
former MARID list http://dir.gmane.org/gmane.ietf.mxcomp
Today the first serious problems with draft -01 were
detected: Some people don't know that SPF offers HELO
tests. Others know this, but have no clear idea what it
means, e.g. how to separate MAIL FROM identities from
HELO identities (and why that's unnecessary).
Finally the result of the combination of MAIL FROM and
HELO tests is not generally understood, there was the
notion of testing MAIL FROM before HELO, or that a PASS
for MAIL FROM overrules a FAIL for HELO.
That's messy. Senders need a clear understanding of the
SPF matrix:
| MAIL FROM
HELO | PErr | FAIL | Terr | S.F. | N.N. | PASS |
-------------+------+------+------+------+------+------+
PermError | | | | | | |
FAIL | | | | | | |
TempError | | | | | | |
SOFTFAIL | | | | | | |
NEUTRAL/NONE | | | | | | |
PASS | | | | | | |
The "receiver policy" mantra has its limits. E.g. if
folks like Carl Hutzler, Andy Newton, Terry Fielder, etc.,
who normally know "how stuff works" are confused, then the
Thanks, I think :)
Be advised I would have been more clear if I had written my own SPF
library, I have not. But the confusion (at least on my part) is because
we constantly hear "how things should be" in different opinions, and
sometimes I confuse suggestions with the realities.
next draft should make this as clear as possible. IMHO no
"receiver policy" stands for "no funny MUST or SHOULD".
It doesn't stand for "do what you like, maybe try a random
generator". Something like a MAY is not only possible, it
is required. For all 6*6 slots i the SPF matrix.
Here's what I think "how stuff works", or more precisely
here's what I thought how it works, apparently that's not
more completely clear in -01:
| MAIL FROM
HELO | PErr | FAIL | TErr | S.F. | N.N. | PASS |
-------------+------+------+------+------+------+------+
PermError | 5xx | 5xx | 5xx | 5xx | 5xx | 5xx |
FAIL | FAIL | FAIL | FAiL | FAIL | FAIL | FAIL |
TempError | 5xx | FAIL | 4xx | S.F. | N.N. | PASS |
SOFTFAIL | 5xx | FAIL | 4xx | S.F. | N.N. | PASS |
NEUTRAL/NONE | 5xx | FAiL | 4xx | S.F. | N.N. | PASS |
PASS | 5xx | FAIL | 4xx | S.F. | N.N. | PASS |
That's an excellent grid. Can we put that into the docs? Or something
like that if certain cells have alternative responses (don't get mad
Frank, recall we are documenting what SPFv1 *is*, not necessarily what
we would like it to be)
Two simple rules:
1 - PermError is always 5xx, FAIL is always FAIL.
2 - All other results for HELO can be ignored.
I've aked the Council in two articles to consider the
simple PermError rule:
http://mid.gmane.org/42904317(_dot_)1574(_at_)xyzzy(_dot_)claranet(_dot_)de
http://mid.gmane.org/42904B3F(_dot_)70EC(_at_)xyzzy(_dot_)claranet(_dot_)de
I've asked for a confirmation that they read this in:
http://mid.gmane.org/4294E2E9(_dot_)6CD0(_at_)xyzzy(_dot_)claranet(_dot_)de
I even bothered Wayne with a mail during the meeting.
Maybe he never saw the "source route" explanation, or
the RfC 2828 source for the definition of "authorize".
During yesterday's meeting two Council members had not
the faintest idea what the old "source route" problem
is about, nevertheless they voted on it. That case
might be irrelevant enough to be no problem, unless
somebody reads it in the same way as I did, i.e, as a
proposal to ignore RfC 2821, or as confusing at best.
But the result stuff is not funny. If senders get a
feeling that SPF is evaluated in arbitrary ways with
no clear meaning, they are better off without SPF.
I simply disagree, senders are still better off with SPF provided they
are OK with either alternative(s) where applicable for situations.
Doesn't necessarily have to be only one way for it to be useful.
Terry
Bye, Frank
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
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
--
Terry Fielder
terry(_at_)greatgulfhomes(_dot_)com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085