Re: Comments requested on recent appeal to the IESG

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.from=192.0.2.3@xxxxxxxxxxx

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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]