[ietf-dkim] marketing dkim
dhc at dcrocker.net
Fri Aug 20 10:24:58 PDT 2010
Daniel, et al,
Persistent misunderstanding of DKIM is a significant problem, and worthy of
efforts to make corrections.
To that end:
On 8/18/2010 6:59 PM, Daniel Black wrote:
> I've got a presentation slot for DKIM at APNIC next week to a bunch of ISPs.
> My current plan for a talk is:
> * DKIM is a really well developed standard for signing email
As noted, "signing email" is not DKIM's goal. Attaching a verifiable label that
can be used for assessment is DKIM's goal. The difference is not merely
significant; it is fundamental.
> * Combined with ADSP=discardable it can filter email at ISP gateways without
> too much fear of unduely lost email
The utility of ADSP is not yet established and is clearly controversial. That's
another way of saying that it's utility is risky.
> * BUT otherwise its useless in its current state.
1. It can be used in exactly the same way an IP Address is used, for
establishing statistical reputation. Except that it can't be spoofed and it's
better suited to this task than is a topology-dependent label. More stable.
Not shared. Etc.
2. It permits attachment of multiple labels, by different actors. You can't
really do that in an unspoofable way with IP Addresses. The benefit is a richer
basis for reputation assessment.
3. It permits stream differentiation; you can't do that conveniently with IP
4. It enables verifiable accountability, such as is already used for feedback
> * Product deployment and DKIM training and documentation for staff
> * Trying to work out why some outbound streams of email get lost (when there
> is no IETF guidance for the receiver)
Researching "lost email streams" (whatever that actually means) is an existing,
generic cost that has nothing specific to do with DKIM.
> * Fixing/changing mailstreams by destination (draft-ietf-dkim-mailinglists-02
This is not a DKIM problem. It's an ADSP problem. As noted, it's important not
to confuse the two.
> * A recipient may through good design manage to pass good signatures and drop
> bad signatues while allowing mailing list mail through.
This is not a DKIM problem. Broken signatures are supposed to be treated as no
> Given likelyhood of benefits are signficantly lower that costs I'm not seeing
> a benefit for a signer.
The benefits are significantly higher when the costs and benefits are more
accurately defined and assessed.
> Cost/benefit to verifier:
> * software deployment training and documentation
> * increases concurrancy of email processing waiting for DKIM keys OR post
> processing where rejection could result in backscatter.
This one is confusing, but sounds silly.
There's no indication that DKIM processing slows mail down, and there's quite a
lot of experience processing DKIM mail. There has also been some direct
research on DKIM overhead and it was deemed negligible.
If DKIM processing had a significant performance effect, we'd have heard about
it by now. But we haven't.
> * implement some filtering scheme based on RFC5863
"based on"? That sounds as if the document specifies filtering schemes. It
doesn't. It discusses them. The difference is fundamental in terms of type,
granularity and intended utility of the topic.
> * rejecting ADSP=discardable messages with missing or broken signatures
Whether that is actually a benefit is not yet established, particularly since we
already have demonstration of false positives due to signer errors.
> * Adding AR headers (that a user or their MUA may never work out how to use
There is no particular intent and certainly no guidance about using
Authentication-Results for end-user consumption. There is even less basis for
asserting that it will provide end-user benefit.
> Again, the likelyhood of benefits are signficantly is lower than costs.
> So DKIM is at a state where there is no offering of filtering advice beyond
> the theoretical discussion in RFC5863. The current mailing list approach:
> MLM behaviors are well-established and standards compliant. Thus,
> the best approach is to provide these best practices to all parties
> involved, imposing the minimum requirements possible to MLMs
> is rather defeatist and limits the encouragement for DKIM-Friendly lists.
First, you seem to be placing quite a lot of emphasis on mailing list issues.
While that's a topic worthy of pursuit -- which is why the working group is
doing it -- it has not been demonstrated to be a fundamental aspect of DKIM
success and there is pretty good indication that it isn't. Of all DKIM-signed
mail, a relatively small percentage goes through mailing lists.
> So for DKIM, filtering is painful as it requires end user specific knowledge
> of what lists they subscribed to.
No it doesn't. This is simply inaccurate and appears to be predicated on a
logic sequence that is convoluted or not yet validated. (Choose your poison.)
> This is hard enough at small end user
> organisation let alone an ISP. The end user is left with an AR header field,
> invisibly hidden by the MUA, to try to filtering out forged mail.
DKIM has essentially nothing to do with the task of identifying forged mail,
nevermind the impossible task of having the end-user doing it.
> For reputation service providers the assumption that mail serivce providers
> are going to deploy DKIM for the benefit of reputation service providers seems
> a little hopeful considering their costs.
And yet it is being deployed. Nicely. This suggests rather clearly that your
conclusion is wrong.
> Don't misunderstand me, domain
> reputation has a role in spam reduction and DKIM contributes to this, there
> just needs to be more benefit to the sender/receiver without it.
> At the end of the day the future I currently see for DKIM is the same as SPF.
Then you do not understand the superiority of DKIM in
a) labeling to distinguish organizations and fine-grained mail streams
b) stability of labeling
c) ability of the signature to survive MTA relaying and alias-type forwarding
> Some will deploy it but at the end of the day there will be no-one filtering
> on its results because of its deficiencies (MLM).
You think that having an author-related signature survive mailing list
re-posting is critical to the acceptance of DKIM??? I hope you have some
industry-derived research data to support that assertion, because there's no
indication that you are correct.
> The progress of deployment
> will stagnate in the same way as spf because there is no filtering:
> (compare http://web.archive.org/web/20080130150257/http://spf-all.com/ and
After watching folks make these kinds of predictions for a few decades, my
observation is that the most reliable prediction about them is that they are
wrong. Folks making predictions usually have far too little information or
insight for making serious predictions.
Your prediction falls into that category, especially since it is based on such a
problematic assessment of what DKIM does and how it is intended to be used.
More information about the ietf-dkim