[Top] [All Lists]

[mail-vet-discuss] Risks when annotating email-addresses contained within Authentication-Results header.

2008-11-13 17:51:18

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  

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  

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  

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  


NOTE WELL: This list operates according to 

<Prev in Thread] Current Thread [Next in Thread>