On Oct 24, 2008, at 9:10 AM, Murray S. Kucherawy 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?
Because of the existing installed base of code doing this work,
splitting the header field into two (one for authentication and one
for authorization) seems like it would work but something easier
could be done.
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?
Are there other suggestions?
Since this header represents assessment results being made at a
"border" MTA, perhaps the header labels could be:
border-check:
Such header label terminology is less likely to mislead the average
recipient which might make them prone to various confidence schemes.
Change the label to method neutral terminology. The term
"authentication-results" along with an email-address contained within
the header may mislead recipients into believing the source of an
email-address has been authenticated when it has not. There is a
significant difference between a method that authenticates the origin
of an email-address versus a method that "authorizes" an SMTP client.
With the draft's current structure of header-label and result terms,
this difference is not apparent at all. Calling the header
Authentication-results: along with arcane mnemonics, an email-
address, and the word "pass" will mislead many recipients into
trusting a message more than is safe. This can happen whenever they
examine the headers of a message that they may question.
In addition to changing the header label, the rather method neutral
terminology "pass" does not clarify what basic method has been
applied. Do not expect recipients to understand the meaning of arcane
mnemonics, especially when the draft explaining this header provides
an incorrect overview of the methodology. Rather than the term
"pass", method specific terminology could be used which should better
inform the recipient. "Pass" could be replaced with "MTA-Authorized",
"Domain-Authenticated", "MTA-ARPA-Match", and "Recognized" for SPF/
Sender-ID, DKIM/DKIM-ADSP, IPrev, and AUTH respectively.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html