spf-discuss
[Top] [All Lists]

overall HELO FAIL

2005-05-26 16:16:04
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
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 |

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.

                       Bye, Frank



<Prev in Thread] Current Thread [Next in Thread>