Dan,
In my view, just as the responses so far as shown, you are going to
get a mix bag of opinions. What is particularly interesting is the
how the definition of "DKIM" seems to keep changing.
In any case, if it was me, what I would do is approach this from what
has been deployed using various non-standard approaches, including
proprietary which I lump together as DKIM-SSA (Special Signing
Arrangements), with what are proposed standards. I would cite any
stats, provide some theory with empirical observations. In short -
INFORM.
DKIM - RFC 4971 raw DKIM signing protocol
My personal definition (don't use it. <g>)
A free for all, message "DNA" stamping technology with an
obscure "responsibility" clause allowing any MTA to
absolve all previous single or collective responsibility.
The main point here would be that it isn't quite useful with "helper
technology" and you can site how its being used now and what are the
standard proposals:
Non-Standard Augmented technology:
DKIM+SSA - DKIM + Special Signing Arrangements (i.e. YAHOO)
DKIM+REP - DKIM + Reputation Scoring (SpamAssassin),
Certification methods
Proposed standard (IETF DKIM WG documents) Augmented technology:
DKIM+ADSP - DKIM + Author Domain Signing Policy/Practices
DKIM+MLM - DKIM + Mailing List Management Guidelines
There might be some I-D proposals or non WG RFCs out there that are
related to DKIM, so I would look for those as well.
I personally would touch base with two employment aspects:
DKIM-SENDER-POLICY (or AUTHOR POLICY)
DKIM-RECEIVER-POLICY (or LOCAL POLICY)
The two seem to be one basis for the conflicts here. But I would not
discuss it from the conflicts POV, but how the two are being
considered by different implementations.
The DKIM-SENDER-POLICY is about what the AUTHOR DOMAIN is trying to
get others to do about his mail, including filtering the unexpected.
The DKIM-RECEIVER-POLICY is about what how the receiver is going to
handle the verification and final disposition of DKIM signed mail.
This has less regard for DKIM-SENDER-POLICY considerations (the conflict).
Anyway, good luck. :)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
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
> * Combined with ADSP=discardable it can filter email at ISP gateways without
> too much fear of unduely lost email
> * BUT otherwise its useless in its current state.
>
> 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
> * 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)
>
> Benefits:
> * A recipient may through good design manage to pass good signatures and drop
> bad signatues while allowing mailing list mail through.
>
> 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
> * Adding AR headers (that a user or their MUA may never work out how to use
> effectively)
>
> 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
> themselves.
>
> is rather defeatist and limits the encouragement for DKIM-Friendly lists.
>
> 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.
> 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.
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>
>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
