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