Douglas Otis wrote:
ESPs optimize profits by reducing their
support calls. To do this, they might reduce erroneous rejections by
tweaking SPF to make guesses. As such, it is not safe to assume that
because the ESP accepted a message from an authorized SMTP client, that:
A) the SMTP client was actually authorized, and
B) that this authorization verifies an authorizing domain emitted the
message.
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.
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.)
[...]
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?
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.
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.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf