On Oct 30, 2008, at 4:29 AM, Charles Lindsey wrote:
On Fri, 24 Oct 2008 17:10:14 +0100, Murray S. Kucherawy <msk(_at_)sendmail(_dot_)com
>
wrote:
An issue has been raised regarding the name of the proposed header
field. Some of the methods supported by the draft are specifically
message authorization and not authentication (e.g. SPF, Sender-ID)
and
there's a concern that this might mislead some consumers of the
header
field's contents. Do others concur, or is it not something about
which
to be concerned?
Having read all of this discussion, I conclude that "Authentication"
is
actually the *correct* term for what this header does.
"Authentication" is a statement of assurance about some particular
aspect
of the provenance of a message.
"This is an authentic Ebay message"
"It is authenticated that this message came from an Ebay IP address"
"It is authenticated that this message passed through X during
transit"
"It is authenticated that such and such a header was added by X"
You appear to be an example as to why this header is misleading. A
message received from an "authorized" SMTP client DOES NOT MEAN the
message originated from the domain that listed the SMTP client in
their SPF or Sender-ID "authorizations". In other words, it makes NO
assertion regarding the provenance of the message!
These authorizations are commonly applied to SMTP clients shared by
thousands of other domains. It is not reasonable to assume that an
outbound server restricts the use of PRA in all messages that they
relay, nor it it reasonable to assume that no bad-actors have access
to shared servers. It is fairly common to find non-trivial amounts of
abusive email emanate from virtually any large provider. Any
assertion of "authentication" of an email-address in the case of there
only being an SMTP client authorization would be highly negligent and
would expose recipients to significant risk!
The header:
AUTHENTICATION-RESULTS: my-trusted-isp.com; sender-id=pass
header(_dot_)from=jon-doe(_at_)e-commerce-are-us(_dot_)com
This offers no indication what IP address or domain handled the
message. This simply indicates in a very dangerous manner that the
domain "e-commerce-are-us.com" authorized some IP address (which
should have been included in the header) to relay the message.
A much less deceptive header would be:
Border-check-results: my-trusted-isp.com; sender-id=MTA-AUTHORIZED ip-
addr=192.168.200.100 pra=header.from<jon-doe(_at_)e-commerce-are-us(_dot_)com>
All these are saying different things about the provenance of the
message. The only thing they have in common is that the statement
being made has been verified by some technical means.
The results are not always about authentication however by limiting
the method assertion to only being PASS, the typical person, such as
yourself, can be dangerously mislead.
None of them says *anything* about "authorization" (though that may
be implied by secondary information available from elsewhere, such
as ADSP records).
http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-16.txt
Wrong. Although this draft erroneously describes SPF and Sender-ID as
"authentication" mechanisms, the definition of "pass" indicates that
only the SMTP client has been "authorized". An authorized SMTP
client MUST NOT be assumed to be an assertion as to the origin of a
message.
Perhaps this header should be called "exclusion-results" since it
would be a safer assertion to indicate that a non-authorized SMTP
client appears to exclude this message as being from where it
purports. Unfortunately, an authorized SMTP client does not verify
that an email-address originates from where it purports.
Perhaps we could take advantage of a lexical coincidence and rename
it to "Auth-Results", specifying in the draft that it covers both
authentication results and authorization results. Would that work?
No, because that introduced "Author" into the possible
(mis-)interpretations :-(.
Why not border-check-results? The concern about an misinterpretation
regarding authentication should be equally of concern. Do not
overstate what the "technical" method provides.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html