ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] marketing dkim

2010-08-19 12:41:13

On Aug 18, 2010, at 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

It's not really for signing mail. It's for attaching a persistent non-IP
based identifier to the mail. The signing is just an implementation
detail.

* Combined with ADSP=discardable it can filter email at ISP gateways without 
too much fear of unduely lost email

I wouldn't claim that too strongly, as it's something that's likely to
turn out to be false.

* BUT otherwise its useless in its current state.

That's not really so, for ISPs who are already doing mail filtering based
on sender reputation. It provides an identifier to plug into their existing
reputation engines that's a lot better than an IP address.


As a consultant this isn't going to get me lots of work but as an engineer 
sticking to ethics it more important.

My rational is what cost / benefit can I give to a domain that wants to sign:

Costs:
* Product deployment and DKIM training and documentation for staff

Yup. Though in many cases that'll be just checking the "use DKIM" box
on one configuration screen and deploying some DNS records.

* Trying to work out why some outbound streams of email get lost (when there 
is no IETF guidance for the receiver)
* Fixing/changing mailstreams by destination (draft-ietf-dkim-mailinglists-02 
4.1)

I don't believe either of those are actual costs if you're talking about
DKIM. DKIM will not cause outbound streams of email to get lost,
nor will you need to fix or change any mailstreams. I'm not sure why
you think either is true - can you explain?


Benefits:
* A recipient may through good design manage to pass good signatures and drop 
bad signatues while allowing mailing list mail through.

No smart recipient will either pass good signatures nor drop
bad signatures. They'll ignore bad signatures and use good
signatures as part of a reputation decisions.


Given likelyhood of benefits are signficantly lower that costs I'm not seeing 
a benefit for a signer.

Cost/benefit to verifier:
Costs:
* software deployment training and documentation
* increases concurrancy of email processing waiting for DKIM keys OR post 
processing where rejection could result in backscatter.
* implement some filtering scheme based on RFC5863

Benefits:
* rejecting ADSP=discardable messages with missing or broken signatures

That's a cost, more than a benefit.

* Adding AR headers (that a user or their MUA may never work out how to use 
effectively)

Yup. There's no sign that that'll be useful in the near future.

Again, the likelyhood of benefits are signficantly is lower than costs.

If they're spam filtering based on sender reputation then the dkim
token is a much more reliable, and cheaper to maintain, token than
peer IP address. It'll make their existing reputation-based filtering
more effective, and reduce the maintenance overheads.

It'll also make them ready for IPv6, where IP based reputation is
going to get somewhat more difficult to manage.


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
  themselves.

is rather defeatist and limits the encouragement for DKIM-Friendly lists.

DKIM places no requirements on MLMs.

So for DKIM, filtering is painful as it requires end user specific knowledge 
of what lists they subscribed to. 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.

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. 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. 

Absolutely not.

ADSP is much the same as SPF, and I agree with everything else you
say, if you're talking about ADSP.

But ADSP is not the same as DKIM. DKIM is a nice, solid way of attaching
identifiers to mail, while ADSP is an SPF-esque bag on the side.

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). 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 
http://spf-all.com)

The solutions (and acknowledged limitations) that may enable an intertial 
mass 
of dkim are in many of the following:
* DKIM-Friendly lists (realising change can be slow based no number and 
incompatible behaviour is driven by MUA)
* MLM that add a dkim signature in a predicatable way (draft-ietf-dkim-
mailinglists-02 4.7) - realizing change is slow for the number of MLM
* MUA that describe verification clearly realising design requires effort
* TPA-Labels realising intergration beween users and DNS needs to occur in 
the 
sender ADMD
* ADSP=discardable for non-MLM participating domains
* ADSP=all for those that really do sign all mail
* Third party signature having meaning on MLM domains though this needs to be 
whitelisting approach is needed on the verifier/receiver ADMD to prevent a 
phishing/spam loophole.
* LDSP for third party signatures

Please tell me where I'm wrong. I don't see nice thing to say to these 
regional ISPs except that DKIM is useless until a clearer policy framework 
for 
filtering is available to everyone.

I think you're wrong in that you're talking about all the flaws of ADSP, while
calling it DKIM. You seem to be spot-on about the operational value of
ADSP, though.

Cheers,
  Steve


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>