Re: Comments requested on recent appeal to the IESG

On Feb 28, 2009, at 4:14 AM, Alessandro Vesely wrote:

> Douglas Otis wrote:
> > The safety of an assumption about an authorizing domain originating  
> > a message depends upon the reputation of the SMTP client for its  
> > protection of the PRA and Mail From.  Unfortunately, identifiers  
> > for the SMTP client have been omitted.  It appears ESPs have agreed  
> > not hold SMTP clients accountable to reduce ESP support calls.   
> > Having some of their customer's domains affected by a security  
> > breach is preferred over all customer's domains being affected  
> > (even when it would be appropriate for all domains).
> However, choosing an ESP should involve more thinking. There are  
> several reasons why end users need to trust their ESPs. If your ESP  
> were malicious, they could play any sort of trick, probably also  
> spoiling your bank account. Thus, I think end users should trust  
> their ESPs not less than they trust their banks.
Not including the SMTP client identifiers in Authentication-Results  
header prevents an SMTP client's protection of authorization  
references to be directly vetted by the recipient's MUA.  Without any  
evidence of such annotation specific vetting in the Authentication- 
Results header, trust would be misplaced when expecting that it  
occurred by receiving ESPs.  The Authentication-Results header reports  
the receiving ESP's implementation of authorization mechanisms where,  
due to the issues discussed, these mechanisms may not accurately  
resolve the intended authorizations.  The direct vetting of the SMTP  
client protection of authorization references by the MUA is not prone  
to authorization errors, and therefore better protects users.
> As far as I understand it, users should configure the MUA giving the  
> domain of their ESP and telling it to trust auth-res headers from  
> that domain only. The ESP is obviously responsible to avoid that  
> counterfeit auth-res records "signed" by the ESP's domain are  
> already present in the original headers. (This isn't foolproof,  
> though: users who transfer their mail via, say, gmail's pop3 client,  
> may be tempted to trust their original domain's records, which might  
> be written by malicious authors who send to gmail directly.)
The concern does not involve the filtering of spoofed Authentication- 
Results headers, which of course must be guarded as a new threat.
> > [...]
> > While MUAs might prompt users to enter the domains they wish to  
> > trust, this entry would be rather perilous.  The exclusive use of  
> > the MAIL FROM or the PRA is not the norm, so it would be foolhardy  
> > to assume otherwise.  MUAs should obtain an IP address list of SMTP  
> > clients vetted by either an organization or a community.
> I'm sorry I elided the rest of the discussion, but the last point  
> you make IMHO summarizes much of the misunderstandings about  
> reporting the SMTP client's IP address. Shouldn't users delegate to  
> their ESPs the choice of an organization or community who maintains  
> such vetted lists of SMTP clients?
Receiving ESPs struggle to ensure legitimate email is not lost, which  
includes email where the protection of authorization identifiers may  
not be assured.  The role played by the Authentication-Results header  
is to support the annotation of a message's origination, but it omits  
essential information required to vet the SMTP client's protection of  
the authorization identifiers, especially when authorization  
references are in doubt.  Annotating the origination of a message  
should include the vetting of the SMTP client's protection of the  
related identities.  This vetting goes beyond whether a message should  
be delivered or not, which is the decision normally made by ESPs.   
Without additional specific vetting, messages should not be annotated,  
otherwise this exposes recipients to being deceived by bad actors.
> In case they should, then the whole job of authenticating the SMTP  
> client can be carried out by the MTA, and communicating the address  
> is useless. Maintaining such vetted lists formally (if not  
> semantically) resembles the work of DNSBLs, which is why I thought  
> that an addition like
>   Authentication-Results: example.com;
>     dnsbl=pass zone=zen.spamhaus.org address=192.0.2.3
> would have been equivalent to your proposal.
It is important that the IP address of the SMTP client be included  
with any authorization mechanism to allow essential annotation  
specific vetting.  Annotation vetting goes beyond what is required  
when deciding to accept messages.
The proposal was:

  Authentication-Results: trusted-isp.net;
    senderid=pass 
header(_dot_)from=192(_dot_)0(_dot_)2(_dot_)3(_at_)example(_dot_)com

Rather than the current specifications:

Authentication-Results: trusted-isp.net;
    senderid=pass header.from=example.com

There is no reason to repeat the local-part within within the results  
header since Sender-ID indicates the local-part is assumed valid and  
Mail From allows only a single email-address.  This change should not  
be problematic.  Adding the IP address in a separate mechanism would  
suggest the SMTP client identifier is not essential for annotations  
based upon authorization mechanisms.
> In case they should not, then MUA software needs to be revamped in  
> order to accommodate that functionality. That IP address will have  
> to be communicated to MUAs, obviously. However, it is still  
> questionable that the auth-res header is the proper place for doing  
> that. In addition, a new protocol (possibly over http?) has to be  
> standardized in order to allow MUAs to deploy the vetting service  
> that you mention.
The annotation of messages will involve changes to MUAs.  Browser  
plugins already obtain similar allow/block lists.  When it becomes  
known that an ESP does not protect authorization reference  
identifiers, such as the Mail From or the PRA, this lack of protection  
alone is unlikely to result in the messages they issue being rejected,  
nor would that be a desired outcome.  It should not require tens of  
thousands of domains using this ESP to have had their domain spoofed  
before protection is realized.  It is not safe to assume that because  
a known domain authorized the SMTP client, that this means any message  
containing the authorization reference had originated by that domain.
One can trust the origination of a message based solely upon the  
reputation of the SMTP client, which might be bolstered when the  
client is authorized by the originating domain.  One should not trust  
the origination of a message based upon the purported authorization of  
a unknown SMTP client.  Such misplaced trust will fail to hold the  
SMTP client accountable, and will leave users exposed to convincing  
fraud.
-Doug




_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf