http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-17.txt
Browser and MUA plugins will be created to annotate the email-address
contained within the Authentication-Results header (in the case of
Apple Mail, no plugin is needed).
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."
Only negative reputations for the SMTP client IP address can be safely
compiled. Once again, path registration compliance MUST NOT be
assumed to represent the AUTHENTICATION of a domain. The email-address
of the PRA is NOT assured to represent the originating domain of the
message. This would be like assigning traffic tickets to the owner of
an vehicle rather than the driver. Only the IP address indicates who
was in control (who was driving). As such, only negative reputation
can be safely accrued against the SMTP client IP address. Should
domain owners and providers now be required to implement PRA
restrictions for all email?
An assumption of domain authentication requires an assurance from the
sending domains that path registration restrictions were applied by
the outbound MTA against the PRA. In other words, the term "pass"
does not convey whether JUST SPF records were published. This means a
"pass" does not allow a reasonable assumption that restrictions were
imposed on the PRA by outbound MTAs. This would be assuming that all
providers license the PRA algorithm from Microsoft and impose PRA
restrictions based upon information confirmed out-of-band. Such an
assumption of domain authentication would be based upon an
experimental RFC lacking a practical means upon which to restrict
PRAs, and the general adoption of such restrictions by all responsible
providers.
Section 4.1 Header Position and Interpretation also says:
"In order to ensure non-ambiguous results and avoid the impact of
false header fields, an MUA SHOULD NOT interpret this header field
unless specifically instructed to do so by the user or administrator.
That is, this interpretation should not be "on by default". Naturally
then, users or administrators should not activate such a feature
unless they are certain the header field will be added by the border
MTA that accepts the mail that is ultimately read by the MUA, and
instances of the header field appearing to be from within the trust
domain but actually added by foreign MTAs will be removed before
delivery."
Clearly even making an assurance that the receiving domain strips
authentication-results headers is not enough.
While Section 2.1 says the header field MUST be prepended, Section 1.3
Definitions says:
"Generally it is assumed that the work of applying message
authentication schemes takes place at a border MTA or a delivery MTA.
This specification is written with that assumption in mind."
...
"It is also possible that message authentication could take place on
an intermediate MTA. Although this document doesn't specifically
describe such cases, they are not meant to be excluded from this
specification."
So which SMTP client IP address that was seen at the border must still
be guessed simply because the Authentication-Results header failed to
capture information absolutely essential for checking the reputation
of who originated the message.
The MUA is likely to be making the annotations, so it is also
reasonable to expect that the MUA may want to apply their own
reputation checks prior to making these annotations. Not capturing or
ensuring the location and the existence of the IP address of the SMTP
client within the message makes such checks either impractical or
impossible. This would make conforming to Section 4.1 impossible.
Using the "iprev" method supported by this header to capture the IP
address would be a bad idea in most cases. When running high volume
MTAs, even logging the reverse IP address information has the
potential of reducing performance by an order of magnitude due to the
rather broken nature of this namespace.
To say that because the MTA passed a message for path registration,
but then neglected to include which SMTP client IP address was
checked, that now suddenly the MUA only needs to hold the domain
responsible. This header does not give the MUA much of an option in
this regard. What public reputation service will hold domains
responsible based solely upon path registration as confirmation of
their culpability? Will there then be a mad rush to ensure every MTA
being used applies the PRA restrictions? Is this really what the IETF
wants?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html