In <4296CF73(_dot_)7006(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
william(at)elan.net wrote:
[HELO vs. MAIL FROM]
They are not serious problems with a draft, they are problem
with people not reading the draft and not being properly
educated on how SPF is supposed to be used.
IBTD. One very old state was "MAY test HELO" just because it
has to work anyway for an empty MAIL FROM. That was changed
to "SHOULD test HELO". That a HELO FAIL is an overall FAIL is
a part of the game, otherwise why "should" you test it first ?
Again, the overall FAIL was not a required part of
draft-mengwong-spf-*. As for why you SHOULD test HELO, I believe it
is a useful thing to do, but we can't require it because it wasn't
required in draft-mengwong-spf-*. SpamAssassin gives separate scores
for HELO checks and MAIL FROM checks, which is fine since it deals
with individual messages, often after the SMTP session has ended.
Forcing them to have to follow an algorithm would be unworkable.
But such stuff has to be communicated, it's really bad if Carl,
Andy, or Terry don't know it.
I know that Andy knows about SPF/HELO checking. I talked with Carl
about SPF/HELO checking last November, I'm guessing he just forgot.
The strong point of SPF was always FAIL. After hard fights
Wayne managed to add PermError for a reliable error handling.
PermError has always been a part of the SPF spec, although in
draft-mengwong-spf-* it is called "unknown". I'm not sure what you
think I added.
But now it's going backwards in the wrong direction, HELO FAIL
unclear, and PermError is something between NEUTRAL and FAIL,
quite literally a SOFTFAIL at the moment, that's wrong.
PermError is not quite literally a SoftFail. The language in -01 says
that it should be treated similarly, but that doesn't mean the same.
As per the last council meeting, that language will change.
Again, we are constrained by what mengwong-spf-* and current
implementations do.
receiver should not be required to test both MAILFROM and
EHLO
That doesn't reflect "SHOULD test HELO".
SHOULD does not mean REQUIRED. Those are different RFC2119 terms.
"v=spf1 =all" means "oops", the identities don't matter, and
it should be reported as "oops" in an SMTP error code.
Unfortunately, PermError was designed back when unknown mechanisms
were allowed for extending the semantics of SPF. When you hit an
unknown mechanism, the SPF result was "unknown". It was important to
make sure that, if the implementation couldn't understand the
semantics of the unknown mechanism, to continue as if there was no SPF
policy.
The "unknown" result was also used for various syntax errors and such.
Since I could find zero uses of deliberate unknown mechanisms in
deployed SPF records, and since the libspf2 implementation has always
considered them an error no matter where they occurred in the record, I
removed the support for unknown mechanisms from the
schlitt-spf-classic-* drafts.
I suspect that receivers will start rejecting on PermError more and
more now that unknown mechanisms have been removed, but we can't go
back in time and change things.
-wayne