In today's draft, section 2.3 manages to increase the overstatements
regarding path registration. A path registration process is NOT an
authentication process! The term Authorization should be included
whenever describing path registration methods. An impasse remains.
Once a domain has authorized an MTA, there will be those who want to
consider an email-address as having been authenticated, whether
located by a proprietary PRA algorithm or by the MailFrom, whenever it
matches against an authorizing domain. Why does this draft repeatedly
describe authorization as being authentication? Does repeating this
lie over and over again in the draft somehow make it true?
This flawed logic puts recipients at significant risk. Negative
reputations necessary to defend against abuse MUST be applied against
authenticated identifiers. The PRA or the MailFrom are NOT
authenticated, and thus will not safely block abuse. Although some
providers may disagree, the IP address of the SMTP client is the
identifier that can be safely assigned negative reputations in
conjunction with path registration exploitation. The issue is not
about the method used to determine reputations, only that the IP
address of the SMTP client is absolutely essential for vetting the
results obtained from path registration.
The deliberate exclusion of the SMTP client IP address was likely done
to ensure this header, in the case of path registration, misleads
recipients into trusting messages more than would be safe. Lacking a
means for MUA plugins to locate the SMTP client IP addresses, there is
no recourse to properly deal with path registration exploitations.
There is no reason why the _only_ authenticated identifier intimately
associated with path registration, the _authorized_ IP address of the
SMTP client, should be excluded. The header is called Authentication-
Results and not Authorization-Results.
Stating Sender-ID or SPF as the method applied does not sufficiently
define the scope of the path registration. There was never an
agreement reached as to the scope of the SPF record. The
authentication-results header fails to return an implied or expressed
scope statement that may have been deduced from the path registration
records, or that remains in an unknown state. Without an implied or
expressed scope, a process can not know what an authorizing domain
intended to ensure, the MailFrom or the PRA. When the scope is
expressed as being for the MailFrom, it would also be dangerous to
conclude the authorizing domain also ensures they control what the
authorized address space emits. Their motivation may have been to
squelch bogus NDNs from other sources as a thrifty solution, without
also going through the expense of imposing specific MailFrom
restrictions on the MTAs being used. In other words, only a negative
result of path registration would be of limited benefit. :^(
An average person examining the authentication-results header is
unlikely to have read that this draft has stipulated that only filter
and annotation programs should view this information. Nothing said in
the draft will remedy the misleading header in the case of SPF and
Sender-ID, especially while it also fails to provide any assured means
to determine the SMTP client IP address. One should ask, why does
nearly every MUA offer a simple means to view email headers if users
are not expected to view them? Apple allows users to select any
arbitrary header for display. Unlike other trace headers, where there
might be dozens, there should be only a limited number of
Authentication-Results headers per message. As such, it might become
common to have this header displayed if it proves helpful in
identifying messages likely to be bogus. No plugins would be needed.
While path registration may indicate a message is from a suspect
source, it remains dangerous to speculate what a positive result might
imply. It does NOT imply authentication. There is nothing in this
header to inform recipients, filters, or MUA annotation plugins what
speculation might be safe, and whether it might be in regard to the
MailFrom or the PRA. The misleading header label and missing SMTP
client IP address information, in the case of SPF or Sender-ID,
represents a dangerous and misleading overstatement as to the value of
this header's results. Do not regard authorization as being
equivalent to authentication.
If this header is not to be viewed by average users, where the label
and contained terms are currently misleading to anyone who understands
the meaning of authentication, this can be repaired in simple
fashion. Dave Crocker's concern as to what is meant by "fail", rather
than "neutral", can also be resolved in a similar way. Use result
codes rather than English terms. It would make this header more
internationally understood, easier for a program to interpret, and far
less misleading to average users. Safety first.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html