The reason for the Authorization-Results header has been stated in
Section 1 Introduction:
,---
The intent is to create a place to collect such data when message
authentication mechanisms are in use so that a Mail User Agent (MUA)
can provide a recommendation to the user as to the validity of the
message's origin and possibly the integrity of its content.
'---
An important consideration for this has been stated in Section 4.1
Header Position and Interpretation:
,---
An MUA SHOULD NOT reveal these results to end users unless the results
are accompanied by, at a minimum, some associated reputation data
about the message that was authenticated.
'---
This should have been stated as:
,===
An MUA SHOULD NOT reveal these results to end users unless the results
are accompanied by, at a minimum, some associated reputation data
about the authenticated origination "identifiers" within the message.
'===
Authentication is important, but a domain is not authenticated by path
registration. A sender-id=pass does not "authenticate" the
associated domain purported as having originated the message. As
such, there can be no associated reputation accrued nor safely assumed
without either endangering the domain or the recipient. For example,
it is not safe, nor reasonable to assume all MTAs impose PRA
restrictions, in the case of sender-id. Unless compilation of
negative reputations can be automatic, which is possible for IP
addresses of SMTP clients, common attacks by bot-nets can not be
safely squelched by the domain without inflicting a greater level of
disruption than otherwise required. In other words, basing
reputations upon an authorizing domain risks injuring the domain.
When the IP address of the SMTP client used by domain authorization is
not made available in Authentication-Results header, this then risks
injuring the recipient.
The validity of IP addresses known to be have been seen by border MTAs
will not depend upon whether an authorization protocol is supported by
sending MTAs. Problems associated with an IP address can be safely
used to limit annotations. Reputation MUST BE based upon
authenticated identifiers. While the source IP address of a TCP
session will have been weakly authenticated, a domain that authorized
the IP address can not be seen as authenticating the domain as the
source of the message. This would be a gross and dangerous
overstatement.
When MUA plugins decide to apply message annotations, these plugins
MUST BE allowed to apply reputation as required by Section 4.1 rather
than assuming inbound providers will have applied these checks. After
all, sender-id=pass says NOTHING about reputation checks! To apply
reputation checks, the IP address of the SMTP client MUST BE included
within the Authentication-Results header.
It is also unreasonable to assume that an average user understands
that "sender-id=pass" or "spf=pass" within a header labeled
Authentication-Results does not mean AUTHENTICATED, but instead means
that an unidentified SMTP client has been AUTHORIZED. Including the
IP address of the SMTP client and adding the term "authorized-by" will
better ensure this header is less misleading. A misleading
Authentication-Results header benefits confidence artists. Who should
be blamed when a recipient's assumption of authentication proves
wrong? Must all MTAs impose impractical PRA restrictions in response
to this misleading header?
Having the content of the Authentication-Results header read: sender-
id=pass MTA/10.100.200.2/Authorized-by/@example.com should improve
both security and clarity without violating what this string was
previously allowed to contain. What reason is there for not making
this type of change?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html