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
