On Feb 26, 2009, at 10:47 AM, Alessandro Vesely wrote:
Douglas Otis wrote:
3) Separate SMTP clients share the same IP addresses.
(Unfortunately this is also a common practice. Brazil, Poland, and
other places have many ISPs that expect hundreds or thousands of
customers to run outbound SMTP services that NAT to a single or
small number of IP addresses. It is also common for VPS services
to run servers out of common IP addresses.)
The domain that operates the NAT is responsible for letting their
users connect to port 25. Operating through a NAT may disrupt an
inner site's activity, if some of its co-NAT sites behave badly.
Again, recipients can mark this weak authentication characteristic
by domain name.
Alessandro,
Tens of thousands of domains might use the same NATed addresses
offered by a network carrier. For authorization mechanisms, if the
SMTP client IP address was included within the Authentication-Results
header, then messages emerging from known NATed addresses could be
easily identified, and appropriately they would not receive
annotations as having originated from an authorizing domain. The
proactive protections afforded by inclusion of the SMTP client IP
address would be substantial.
There are hundreds of thousands of legitimate SMTP clients in
comparison to hundreds of millions of domains. This sizable
difference makes SMTP client based annotation assessment a thousand of
times more comprehensive. It is already very difficult to detect
spear phishing events. Basing assessments only upon events evidenced
by the domain, rather than by the SMTP client IP address, means this
insidious activity is more likely to go on unabated.
4) Authorization results that are based upon a virtual record when
no SPF record is found. (Injecting SPF mx/24 record mechanisms
whenever no SPF is discovered is also a common practice.)
That's totally bogus. I may accept a bug in my ISP's SPF checking
software, but 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. They will be asked to enter the name of their provider
into the MUA while being unaware of any underlying SPF record
guesswork. Allowing the MUA a means to check the status of the SMTP
client reduces risks created by authorization guesswork or a
provider's acceptance requirements. Judging whether to annotate is a
much different decision from deciding whether to accept a message.
...
It can only be said that a domain *authorized* the SMTP client.
Yes, the client is authorized to say it sends on behalf of that
domain: it is a user of that domain by definition.
This statement is not correct. This is why it is so wrong to confuse
*authorization* with *authentication*.
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. In addition,
an authorization of Fred by Sam should not be considered a guarantee
that Fred always checks sender identities against the return
addresses. An authorization only means packages delivered by
unauthorized carriers should be considered suspect. This philosophy
is often the basis for publishing SPF records when dealing with back-
scatter. The reputation most relevant as to whether a return address
might be valid is that of the carrier Fred.
...
I doubt that displaying "192.0.2.3@xxxxxxxxxxx" will make the
recipient safer.
The alternative might be "HR@xxxxxxxxxxx" is used with a message
asking you to complete your W2 form at a specific web-site.
Unfortunately, the MUA is unable to check whether 192.0.2.3 has a
recent history of spoofing domains. Employees of example.com may
be unaware of the limitations imposed by their outsourced email
service, or may have created records intended to help ensure
message delivery. Bad actors can now leverage any "righteous"
assumptions that border MTAs might make to produce extremely
convincing socially engineered attacks. See items 1- 6. These
attacks are made easier whenever *authorization* is erroneously
elevated into being considered *authentication* without adequate
safeguards being provided. Safeguards based only upon a domain
will not isolate the services culpable for domain spoofing and will
inhibit an effective response to SMTP client exploits.
With the possible exception of some guys of the IT department, I
think no employee of example.com can tell if 192.0.2.3 is or is not
the IP address of their ESP.
Per the draft, the MUA is expected to check the reputation of the
"authenticated origin identity" (this would be the SMTP client IP
address). When this address represents that of a NATed IP address,
the message should not be annotated as being from the authorizing
domain. This has nothing to do with the reputation of the domain,
where look-alike attacks should be blocked by the border MTA anyway.
A decent ESP should ensure that spoofed messages claiming to
originate from within the company itself are rejected right at the
SMTP level, e.g. restricting mailers to use authenticated SMTP with
strong encryption. Failing that, all what a MUA can do is to mark
messages originating from example.com as not trustworthy, given the
annotations that can be done on that domain name.
ESP are sensitive to complaints from customers about not receiving
their messages and may base acceptance upon the SMTP client being
authorized. In addition, an authorized SMTP client does not mean
other domains do not use the same IP address.
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. 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.
When Authentication-Results headers cause a consolidation of added
headers, SMTP client IP address may no longer be available when
processing *authorization* mechanisms. The Authentication-Results
header can occur at subsequent MTAs which does not help identify
which Received header can be trusted. In addition, not all
Received headers include the IP address of the SMTP client.
That seems to be questioning which MTAs' headers one trusts. Of
course, it is the boundary MTA who can produce interesting results.
Thus, recipients are better off choosing one that they can trust.
Agreed. But effective protection still requires the border MTAs to
capture the IP address of the SMTP client.
What's wrong with processing local macros?
During a spam campaign, by varying local-parts (which is already
normally done), any macro driven transactions may just expend the
recipient's DNS resources, and target any otherwise innocent
domain. This provides an otherwise free method to attack while
spamming. Any method to combine the user namespace with SMTP
client authorization is likely to require a substantial amount of
recipient generated DNS traffic.
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.
I agree that if no local macro has been processed one can safely
consider the local part as not having been validated. However, the
converse statement does not hold.
A) It might be painful for innocent third-parties when recipients
process local-part macros.
That's true. Perhaps, sensible implementations should check that the
local part is not the terminating part of the name to be queried. In
any case, sites that publish records intended to play DoS attacks
should be considered responsible of what they do. (MX records lend
themselves to similar exploits.)
SPF local-parts can also reference MX records and MX record targets
for additional amplification. Bad actors also often publish SPF
records from compromised hosts, where the force of the attack is
generated by their recipient's DNS resolvers.
B) There is no output specified by the SPF mechanism to indicate
what portion of a local-part, if any, plays a role in the
authorization.
True. I interpret it as leaving it up to the site admins to decide
their policy. The net result should be that any local part from an
authorized sender is reliable as much as the authorizing domain is
trustworthy.
Agreed. Why bother to check a local-part, especially when these
checks might prove painful to innocent third-parties?
...
Only the IP address of the SMTP client offers a practical means to
track IP address sharing. Attempting to track IP address sharing
by domain will be fairly impractical since tens of thousands of
domains might authorize the same IP addresses, but SPF does not
offer a reverse namespace. Marking a domain as "unsuitable for
annotation" that never issued abuse is likely to incur expensive
support calls and involve the SMTP client providers anyway. Not
including the SMTP IP address will produce more victims for
confidence artists and make defending an authorization mechanism
more expensive.
Those are all good ideas for reckoning reputation. However, as you
point out, they are meant to be rolled out as services, not tasks
that each MUA carries out on its own.
The draft clearly indicates that the MUA is obligated to check the
reputation of the "authenticated origin identity" prior to making
annotations.
Such services may run on downstream MTAs who need more coordination
with the border MTAs, or at third parties' sites who need to know
the IP address of the SMTP client as a parameter. As far as I can
tell from having read a fair amount of this topic, in neither case
the IP address is considered an authentication result: it is the
parameter for obtaining an authentication result.
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.
It seems rather obvious why the ESP community wishes to avoid having
their SMTP client behavior directly assessed. Unfortunately, holding
authorizing domains accountable for the actions of the SMTP clients
they authorize will fail at providing comprehensive protections.
Misdirected assessment will thwart practical efforts aimed at curbing
abuse. Again, this header is about what results are safe to annotate.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf