Douglas Otis wrote:
Received: by SMTP id j2cs23447wfe;
Tue, 24 Feb 2009 09:51:01 -0800 (PST)
Return-Path: <info@xxxxxxxxxxx>
Authentication-Results: trusted-isp.com; spf=pass smtp.mail=example.com
...
--- or ---
Received: by SMTP id j2cs23447wfe;
Tue, 24 Feb 2009 09:51:01 -0800 (PST)
Return-Path: <info@xxxxxxxxxxx> (SMTP Mail From parameter)
Authentication-Results: trusted-isp.com; senderid=pass
header.from=example.com
...
From: The Club<the_club@xxxxxxxxxxx>
Up to DNS reliability, a positive result proves the validity of the
domain name, in the sense that the domain admins have stated that
messages originating from the given IP may righteously claim to
originate from that domain.
Positive authorization results will not safely indicate whether a domain
originated a message (and will not represent authentication) when any of
the following might be true:
1) Publishing the SPF record was intended to ensure delivery or to
minimize backscatter, but was not to ensure source authenticity.
(Ensuring delivery is a common reason for publishing SPF records.)
SPF records with "+all" is like people hand signing blank sheets, they
shouldn't be surprised when someone abuses of their slapdash attitude.
However, recipients can still attach such annotation about the domain
attitude to the domain name.
2) The authorization reference (such as Mail From or From as above) was
not restricted to just the domain's users. (It is a common practice not
to impose restrictions on the use of the Mail From or the PRA.)
I'm not sure if you mean the effect of the SPF record. (In that case,
the previous comment holds.)
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.
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.
5) The SPF Authorization is not intended to be referenced from a PRA
message element. (There may be uncertainty whether a PRA is a valid
reference due to conflicts between RFC 4406 and RFC 4408.)
True. Let's hope someone rewrites the relevant RFC...
6) A domain that employs outside email providers to handle inbound
email, but then inadvertently includes an MX mechanism where the inbound
provider also offers outbound services to thousands of domains from the
same IP address space. (This now will likely be found to be a common
mistake.)
Even if that's a common mistake, I would annotate them as a marginally
trusted domain. Obviously, their policy doesn't provide for checking
their own settings.
Why wouldn't that make up an authentication of the given domain name?
Any common situation from 1 - 6 eliminates any reasonable assurance that
a domain originated the message.
I would regard the message as being originated by "example.com" and
then check if I have any annotation about that domain name.
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.
Assigning reputations to a domain on that
basis is not easily reconciled, nor will marking the domain "unsuitable
for annotation" offer timely protection for other domains that are also
sharing the SMTP client IP address. This is not about blocking
messages, this is about annotating messages.
If I understand you correctly, you're saying that the domain itself
cannot be considered guilty of writing a specific message, but only of
not having enforced enough protective measures. Perhaps, that is
correct. However, a domain can never "write a message" personally,
because it is an abstract entity. It can only authorize other entities
to write on its behalf. That's why annotating its attitude at issuing
authorizations is important.
BTW, I'd like "marginally trustworthy" better then "unsuitable for
annotation". The fact is that the recipient cannot trust it. Sharing a
NAT with criminals might not be the domain admins' fault, but the fact
remains that the domain cannot be trusted.
It is not clear to me what checking would the MUA do in practice.
When annotating a domain as having originated a message is based upon
SMTP client authorization, the reputation of SMTP clients is critically
important. As enumerated by the list 1 - 6, not all IP addresses used
by SMTP clients will restrict a domain's use to just their users.
By "just their users" you mean "the users authorized by the domain"?
In facts, a domain could publish the full list of its authorized
users, then, e.g. because of some of situations 1-6, someone who is
not on that list manages to write a message that gets, say, an SPF
"pass" and the consequent authentication record. Then, either the full
list of authorized users is false, or the domain is not technically
able to issue correct authorizations. In both cases the domain is not
trustworthy.
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. 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.
As for tracing spoofing attacks, a MUA sees too little traffic to be
able to do such activity. Attackers can have such a light footprint
that even DNSBLs with myriads of honeypots might be unable to trace
them. At any rate, if that is your concern, I wonder why you didn't
propose to include the results of looking up some DNSBLs rather than
pass the IP address along in that header. Capturing such information
may obviously be useful for attributing more or less reputation to a
given message...
I know that sudden bursts of spam from otherwise silent IP addresses
defeat the effectiveness of transfer-time DNSBL lookups, thus it may
make some sense to schedule further lookups of the same IP at well
balanced time intervals after a message acceptance, but I don't think
that a manually launched MUA could cope with such precise timing
requirements.
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.
A domain interested in verifying the local part might combine the
"exist" mechanism with a purposely built DNS zone.
The SPF exist() function must combine local-parts with the IP addresses
of the SMTP clients. Using the macro "exists:%{ir}.%{l+_}._spf.%{d}"
will authorize a message that references an A record at "_spf.<domain>"
with labels that comprise reverse octets of the SMTP client IP address
followed by local-part characters, where '+' and '_' characters are
replaced by periods. While the macro capability of SPF offers
flexibility, it also provides bad actors the ability to define any new
sequence of 10 DNS transactions constructed from a single cached SPF
record.
Yup, that's how a domain can be picky on the authorizations it issues
even without forcing its users to use a fixed MSA.
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.
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.)
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.
I'd say that only MTAs whose SPF-checking implementation traces the
use of local macros may conclude that the local part was not
specifically checked, and thence conceal it.
In converse, conditional annotations based upon the use of local-part
macros will encourage the use of this dangerous mechanism.
Agreed, not because of the danger (that should be dealt with by other
means), but because it would be silly to impose mentioning a local
part macro for that sole purpose. Possibly, a domain already has an
MSA that rigorously checks any local part as their only authorized
sender address, but it should include a local macro (perhaps in the
explanation) if it wants its local parts to be validated...?
If such dynamic use of SPF were to become popular, a reputation service
could return A records where the least significant bits encode the
number of second since a problem was noted. It seems unlikely there
will be a demand for solving this issue, but it would not be
impossible. Our service already tracks hundreds of millions of IP
addresses where activity is already measured in this manner.
It is fairly common to accrue reputations over a range IP addresses.
When this range of IP addresses does not spoof domains, revealing
results should be safe. It is also fairly common for ISPs to
transparently intercept port 25 traffic or to force the sharing of
common IP addresses. In this case, it is _never_ safe to assume that
an authorized SMTP client provides even a modicum of proof that a
particular domain originated the message.
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. 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.
Thence, my wonder about why that result --not its parameter-- doesn't
have a Method, a definition, ptypes, and properties as provided by the
Email Authentication Result Name Registry, in order to be included
into the Authentication-Results header, is the same as for the DNSBL
lookup I mentioned above.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf