Wayne Schlitt <wayne(_at_)schlitt(_dot_)net> wrote:
I presume you are referring to the
draft-kucherawy-sender-auth-header-00.txt I-D.
Which is here BTW:
http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00
I looked at it, and was somewhat disappointed in it. It appears to
have many of the same ABNF problems that earlier versions of the
Received-SPF: ABNF had, and using 15 pages to discuss one header
seemed a little long. Some of the definitions in it don't fit very
well with SPF, for example, the SoftFail definition doesn't really
match. Also, their definition of "neutral" is what SPF calls "none",
and the I-D lacks the SPF equivalent of "neutral". There are no
options to add the equivalent of the Received-SPF key-value-pairs.
Basically, it appears that they have tried to create a generic header,
and as a result, no authentication method will fit exactly. This
doesn't seem like a good idea for authentication results, where clear
and exacting information is required.. If this header was already in
widespread use, it might be productive to use it, but since it is only
an I-D, I don't think we want to tie SPF to it.
I'm not fundamentally disappointed in the "Authentication-Results:" header
spec. The problems it has can be resolved. The ABNF grammar can be fixed
easily and isn't work any discussion here.
Of the specs's 15 pages, only pages 2..10 are significant, which makes it
9 pages. That's not excessive just yet.
I think the "softfail" definition actually does match ours, it is just
worded differently. The point of SPF's "SoftFail" result code is to allow
domain owners to publish a policy of which they are not entirely sure, or
to mitigate transitionary effects of the SPF concept's implications (see
section 9 in the SPF spec). The "softfail" definition in the
"Auth-Results:" spec really describes the same scenario, i.e. that domain
owners want certain messages not to be rejected even though they would
technically not pass the authentication test. In both scenarios there are
messsages which the domain owner _wants_ to be rejected and messages he
doesn't want to be rejected, but for one reason or another he cannot
accurately express which ones are which. (The reasons could be lack of
knowledge of his infrastructure, lack of expressiveness of the policy
language, ignorance of mail senders and receivers, or something else.)
Yes, their "neutral" should be called "undefined", as should our "none".
(Hint, hint!)
Yes, their syntax isn't very expressive or extensible.
But as I said, I think these problems can be resolved.