On Tue, Jan 25, 2011 at 10:08 PM, Douglas Otis
<dotis(_at_)mail-abuse(_dot_)org> wrote:
On 1/25/11 5:49 PM, Dotzero wrote:
The triggering question was whether one can make decisions directly
based on SPF, DKIM or a combination of the two. Doug stated that one
could not. My position is that you generally can (combinations) for
domains that have good control over the mailstreams (particularly
abused brands such as financial).
Mike,
Correction. To be clear, may I say one can use the position of stars in the
sky when making decisions.
And if you are navigating at night, that would be a useful thing to do
- particularly if you have a sextant.
However, when making reasonable decisions about how well a provider is
managing their mail resource, SPF pass or fail represents a poor measure.
All SPF does is provide a "link" between the IP address/host and what
the domain (through a DNS record) indicates email for that domain is
emitted. As I have previously said, it is an enabler.
SPF pass offers little upon which an administrator can be judged.
Malefactors are good at offering an SPF pass. Providers that handle
messages where a customer's SPF record ends up failing also does not
necessarily mean the administrator has done anything wrong either.
Context is everything. SPF pass means that the message (transport
layer) is tied to the domain through the DNS record. I'm going to do a
little flip flop here and say that if the behavior of the domain/IP
address is known then then an SPF pass can and does mean something
until the domain/IP address goes bad (the other discussion we have
been having). As far as an SPF fail, it depends on the domain, the
published record and the message itself to determine whether the
administrator has done anything wrong.
Instead,
one must use identifiers that accurately track resources being managed by
the administrator when assessing their stewardship, not how clever their
customers are in deciding which SPF records to publish.
I'm not clear on your distinction between administrators and customers.
We both know
customers are likely to get this wrong. Your statements about some strange
need to use "-all" suffixes in these records does not help the situation
either.
Either you have a confidence in what you are doing and publishing or
you don't. I'll take a -all over a (naked) +all any day of the week.
Secondly, DKIM can be replayed and will not necessarily indicate the
intended recipient of the message. Blindly using DKIM as a basis to assert
a signing domain is responsible for sending unsolicited bulk email may prove
highly unfair when replayed by some malefactor.
I agree that there are some potential issues with replay attacks (for
example the double header issue). But as with your concerns about SPF
and multiple lookup DOS attacks, we haven't seen them. Thee are much
easier abuse vectors.
When mitigating SPAM, both
SPF and DKIM represent poor and often misused tools.
I'm not so sure about the "poor" part but I'll grant you the misused.
Is there any protocol on the internet that we can point to as not
having examples of poor implementations? One slight digression, as we
discuss DKIM, I am only commenting on 1st party signatures, not 3rd
party signatures.
In addition, seldom
are both DKIM and SPF required for message acceptance, which leaves either
mechanism wide-open to abuse. A requirement that both mechanisms pass would
reduce the integrity of email delivery, and make recipients unhappy about
their lost messages.
Don't think of it as a requirement that both pass. For mailstreams
that purport to be from a particular domain, what does a double pass
tell you with regard to the likelyhood that a message with a double
pass originated from the domain it purports to be (At both the
transport and message level).
Use of cryptographic authentication of SMTP clients supported by DANE
resource records can operate within IPv6, and then offer truly effective
tools able to fairly aid in the mitigation of SPAM. Use of third-party
authorization would also permit policies able to cope with how email is
normally used, without loosing track of the administrator's resource
management.
Let's just require everyone to use PKI and certs..... I'm not holding my breath.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg