On Feb 27, 2009, at 1:12 AM, Alessandro Vesely wrote:
Douglas Otis wrote:
There are hundreds of thousands of legitimate SMTP clients in
comparison to hundreds of millions of domains.
My understanding is that recipients are only interested in a few
domain names: their company, their banks, their customers, their
providers, and the like. While they are probably interested in
knowing about such site reputations, they don't want to know how
often those domains' servers change their network settings. Good
domain names last longer than their IPs.
Alessandro,
The recommended change does not eliminate the presence of the
authorizing domain in the authentication-results header, but
supplements it with that of the SMTP client IP address. The SPF/
Sender-ID mechanism might be intended to only modify the DSN handling
of messages not from authorized SMTP clients. Although both RFC 4406
and RFC 4408 make non-normative comments about what might be deduced
from an authorizing domain's reputation in respect the validity of
email-addresses, there is no mandate that ensures an assumption of
validity. Some incorrectly expect a domain that has authorized SMTP
clients, will have only authorized SMTP clients that enforce the
exclusive use of their domain within either the PRA or Mail From.
Assessing the reputations of SMTP clients indirectly by the
authorizing domains significantly limits the protections that might be
achieved whenever domain spoofing is detected. Targeted phishing is
already difficult to detect, where many attacks now leverage
information from social networking sites to determine which domains
are known by the victims. While the SMTP client authorized by some
domains change over time, the protection of the domain within either
the PRA or Mail From is still a function of the SMTP client, and is
not directly that of the many many more authorizing domains.
deliberately falsifying the data requires that "trusted-isp.com"
be removed from my set of trustees.
Customers of such providers will still desire their email to be
annotated.
The consistency of requiring perfect reputation of happy-fraud.com
is questionable. If that's my bank, I should probably think about
changing.
This misinterprets the concern. 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).
A package delivered by Fred bearing Sam's return address where Sam
references Fred as being *authorized* does not represent an
assurance that the package is really from Sam. Only when Fred has
a reputation of always checking sender identities against return
addresses can there be any assurance that the return address is
valid.
Trusting the return address is only relevant at the transport level,
MUAs should not provide means to issue bounces.
Having the Authentication-Results header include the IP address of the
SMTP client provides a means to better determine what is safe to
reveal to the recipient.
Besides, IMHO, it is Sam's reputation that the recipient should be
interested in, not Fred's. We apparently differ slightly on this
subject, but I'd defer it, as it is not the most relevant point.
Holding Sam accountable for an SMTP client run by Fred assumes Sam has
established agreements with Fred stipulating PRA or MAIL FROM
exclusivity. Will omission of the SMTP client identifiers morally
obligate Sam to establish exclusivity service agreements? Such
agreements would not be a prerequisite when Fred is held accountable,
but might be seen as revenue stream by ESPs. In addition, when Fred's
security is breached, the PRA or MAIL FROM for any domain delivered by
Fred should not be trusted until Fred's breach has been mitigated.
Not being able to determine whether a message was delivered by Fred
makes comprehensive annotation protections impossible.
When Fred delivers email for tens of thousands of domains, how will a
breach be reported? Instead of reporting the range of IP addresses
Fred uses, adjustment to annotations will need the tens of thousands
of domains that Fred handles. Does anyone really expect Fred to
report the domains of all of his customers during a security problem?
[...]
As for tracing spoofing attacks, a MUA sees too little traffic to
be able to do such activity.
It is reasonable to expect the MUA will check the reputation of a
few hundred thousand IP addresses prior to applying annotations.
Here is where I don't follow you. I, for one, don't have a few
hundred thousand messages in my mailbox. In addition most of the
messages I have come from a minority of IP addresses.
Qualifying annotations based upon the IP addresses of the SMTP clients
with a reputation for protecting authorizing domains requires a small
and comprehensive list as compared to a list by the domains. The
alternative of guessing which domains have established exclusivity
agreements with their email providers will result in more victims
being given a false sense of security.
There are techniques that dramatically reduce the size of this
list. The alternative requires much less effective and indirect
checks of many million authorizing domain names.
I must understand you're not talking about a process running on the
MUA, correct?
MUAs should obtain an IP address list of SMTP clients vetted by either
an organization or a community. The overall size of a comprehensive
list could be reduced to about 30 KB, or about the size of a small
HTTP graphic image.
[...]
The limit on the number of lookups should be low enough to dim DoS
attacks.
The limit of even 10 DNS transactions (without going into how this
might be extended) still represents an attack that does not consume
_any_ additional resources of the attacker.
Consuming the attacker's resources is not relevant since they can
outsource them for free.
The DDoS attack would be directed through legitimate DNS resolvers
that, in conjunction with MTAs, doubly obscure attacking sources. A
direct attack would expose the compromised systems. SPF local-part
macro reflected attacks would not expend a compromised system's
resources when targeting any victim with reflected MX, TXT, A, or AAAA
transactions. Since this attack would not expend additional
resources, the attack would be free for the attacker.
Results obtained after inputing the *authenticated IP address* (by
way of TCP interaction) of the SMTP client into mechanisms, such
as SPF or Sender-ID, will be whether or not the SMTP client has
been *authorized*. Only when this SMTP client has a reputation of
ensuring the Mail From or PRA originates from the user of that
domain (perhaps with click-through validation associated with the
access account), would it be safe to annotate a message as
originating from the *authorizing* domain. Attempting to
indirectly assess SMTP clients based upon the authorizing domain
makes the assessment orders of magnitude less effective and more
expensive.
I may agree on that even if you didn't specify what techniques would
be used. However, it seems that, even using those optimizations, the
implied volume of data is not what a typical MUA has in its
mailboxes. Thus, it has to rely on an external service. I ask again
the same question: what is the result that such external service
delivers?
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.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf