On Oct 23, 2008, at 12:17 PM, Murray S. Kucherawy wrote:
Douglas Otis wrote:
The sender-auth draft provides a mechanism for use when ADSP
records are discovered, the From header field can be captured
within an Authentication-Results header. The purpose of the
Authentication- Results header is to convey to MUAs the results of
various message "authentication" checks. Because the Author-
Signature definition limits what is allowed within a compliant
DKIM signature, neither ADSP, Sender-ID, or SPF can properly be
described as providing an authentication of the From header field,
PRA, or the MAILFROM email- address respectively. The Author-
Signature definition prevents a complaint signature "on-behalf-
of" value from indicating a From header field has not been
authenticated.
I'm afraid I'm missing how the definition of Author-Signature, which
is a property of the ADSP specification, alters what SPF or Sender-
ID can claim.
This draft incorrectly describes methods as offering
"authentication". Unfortunately, this mischaracterization also
includes DKIM-ADSP because of the broken Author-Signature definition.
In addition, the path registration process of Sender-ID and SPF
only authorize an SMTP client. An authorized SMTP client will not
safely convey an assurance that the corresponding email-address
was authenticated to represent the author or even being a valid
use of the email-address.
A consumer of the data presented in this header field would be
expected to understand what an SPF "pass" or Sender-ID "pass"
actually implies before acting on it. There's text covering that in
the draft already as well, in the "Header Position and
Interpretation" section.
A security mechanism should not recklessly abuse the term
Authentication. The term Authentication is _dangerously_ misleading
for most methods logged by this header. The term "Authentication"
should be replaced by a neutral term "method" within draft where
possible. It would not be too misleading to use the terms
"Authentication or Authorization" instead of just "Authentication"
within a few sentences. A header label "Source-Results" would be
less deceptive in respect to the nature of the results obtained. The
term Authentication is being misused more than 60 times through out
this draft (ignoring the title and header labels). Admittedly the
word "authorized" is buried in the definition of some results, but
this term will _never_ be evident to the user. Do you see the danger
using the header label "Authentication-Results:"? The draft's
introductory statement does not help much either:
"At the time of publication of this draft, [AUTH], [DKIM],
[DOMAINKEYS], [SENDERID] and [SPF] are the published e-mail
authentication methods in common use."
Authentication methods? Really?
It is _dangerous_ and _misleading_ to suggest that an SMTP client
_authorization_ method results in the "authentication" of the PRA,
MAILFROM, the valid origination of the message as stated in this
draft. An _unauthorized_ SMTP client MAY be an indication of the
invalid use of a MAILFROM or PRA, however an authorized SMTP client
must not be assumed to indicate the valid use of an email-address, as
suggested by the overused term "Authentication" through out this
draft. Describing an authorization method as being an authentication
method results in a dangerous misrepresentation of the results
produced for most of the methods currently defined methods, even for
DKIM-ADSP at this time.
Get rid of the sales hype describing everything as "authentication".
Security is no time for muddled or misused terminology. There is no
reason to mislead recipient any more than they already are.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html