Subject: [ietf-dkim] marketing dkim

From: Daniel Black <[email-masked]>
Date: Thu, 19 Aug 2010 11:59:48 +1000

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

---

From: <[email-masked]>
Date: Thu, 19 Aug 2010 07:24:33 -0400

Daniel,
DKIM signing clearly defines who takes responsibility for signing an email
ADSP is only useful if it is implemented by draconian senders like financial emailers who really really want all malformed dkim signatures to be dropped regardless of consequences
There is NO filtering usefulness using DKIM as it is not reputation based. It does give one the ability to slow down spoofing. If the signature matches then indeed the sending ISP did in fact send it
Now why would anyone make time to evangelize against a protocol at a conference is beyond me unless it was SPF :-)
thanks,
Bill

---

From: John Levine <[email-masked]>
Date: 19 Aug 2010 16:20:36 -0000

>* DKIM is a really well developed standard for signing email

Right, but emphasize that the granularity is a signing domain -- it is
not and cannot be a way to attribute mail to individual people.

>* BUT otherwise its useless in its current state.

I wouldn't say that.  It's quite useful as is to recognize signed mail
from people you know.  Paypal is the obvious example, their legit
volume is high enough to most places that it's worth whitelisting
their signed mail, which then lets you crank up the phish filters to
catch the unsigned fakes.

Be sure to tell them that ADSP is not useful, according to one of the
authors of the ADSP RFC.  Rather than fooling around with with the
near zero S/N ratio of ADSP, whitelist people you know, perhaps put in
a few special cases to drop unsigned mail from phish targets like
Paypal and Amazon who sign all their mail. (Amazon still signs with
DK, but most filters can deal with that.)

If you're an ISP, signing your own mail is of limited value unless you
exchange a lot of mail with Yahoo and Google, which you probably
do. In that case it helps them to recognize your mail stream, and in
Yahoo's case send back FBL reports when people hit the spam button.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Aug 2010 12:29:35 -0400

> DKIM signing clearly defines who takes responsibility for 

Responsible for what?  Can I get sued when something goes wrong?

> ADSP is only useful if it is implemented by draconian senders 
> like financial emailers who really really want all malformed 
> dkim signatures to be dropped regardless of consequences

Draconian?  Maybe they don't to get sued when the new signer 
ignorantly ignores policy and resigns the mail thus passing the 
responsibility buck.  You know the "You break, you own" pottery 
principle.  PAYPAL was pretty smart to put a official RFC sanctioned 
technological disclaimer out there.

> There is NO filtering usefulness using DKIM as it is 
> not reputation based. It does give one the ability to slow 
> down spoofing. If the signature matches then indeed the sending 
> ISP did in fact send it

But what if it didn't match?  Do you continue sending potentially 
spoofed mail?

> Now why would anyone make time to evangelize against a 
> protocol at a conference is beyond me unless it was SPF :-)

Maybe because for so long everyone heard about how great DKIM is, with 
years of no real proof or payoff shown, and now the conference 
sponsors decided to add an opposing viewpoint or a viewpoint that 
might suggest where there might be a payoff with DKIM.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Aug 2010 10:06:53 -0700

On 08/19/2010 09:20 AM, John Levine wrote:
> authors of the ADSP RFC.

Chairs --

Can I ask for a revision of ADSP where John is stripped out of the document?
It's ridiculous that he presumes to speak for it, and it was a huge mistake
to give him this undue credibility. Especially when he has none.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Aug 2010 10:33:56 -0700

On 08/19/2010 10:23 AM, Stephen Farrell wrote:
>
>
> On 19/08/10 18:06, Michael Thomas wrote:
> You can ask. The answer is that we don't currently have
> a revision of ASDP on our charter and RFCs do not change.
>
>> It's ridiculous that he presumes to speak for it,
>
> John was an editor of ADSP, which is a WG product. I think its a fine
> thing to do editing work even if you don't agree with the content.

Well, I don't. Would you hire somebody to build a bridge that they
think would be fine and dandy if it collapsed?

> I personally wouldn't then deride the WG output, but the RFC is what
> gets read, so I treat remarks like John's as the background noise that
> they are, but I do understand why some WG participants find it annoying.

That's because you have scruples.

>> and it was a huge mistake
> That last is out of order on a list such as this. Please desist.

I'd say I'm sorry, but I'm not. You guys made a huge mistake, and
John's continuing baseless jihad is a disservice to the community.

Mike

---

From: Steve Atkins <[email-masked]>
Date: Thu, 19 Aug 2010 09:59:31 -0700

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

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

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

> * Fixing/changing mailstreams by destination (draft-ietf-dkim-mailinglists-02 

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?

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

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

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.

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

DKIM places no requirements on MLMs.

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

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Aug 2010 10:50:17 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Black
> Sent: Wednesday, August 18, 2010 7:00 PM
> To: [email-masked]
> Subject: [ietf-dkim] marketing dkim
> 

That doesn't sound much like "marketing" to me...

I would focus on the fact that it, in addition to being a mechanism to thwart forgeries, is a framework for providing things like domain reputation.  It's an important layer enabling other very valuable things.  Lots of enabling technologies are by themselves not especially useful, but that doesn't mean they aren't critical.

> is rather defeatist and limits the encouragement for DKIM-Friendly

Accepting the realities of a situation seems to be more practical than defeatist.  The email world is loaded with software inertia.  Working with that as a guideline is the best way to get something accomplished.  If we're surprised by the absence of that inertia, things can only get better.

> just needs to be more benefit to the sender/receiver without it.

I read this as saying "We need reputation for really effective filtering," which is completely true.  I think a positive spin here would be much more likely to draw support; using words like "useless without" will do more to discourage your audience than encourage it.

> (compare http://web.archive.org/web/20080130150257/http://spf-all.com/

Jeez, what's the intent here?  Are you trying to get people excited about DKIM or convince them not to bother?

> filtering is available to everyone.

If I, as someone excited about DKIM and what it can enable, were invited to speak someplace while this was my general disposition, I would politely decline to present anything at all.

-MSK

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Aug 2010 18:23:55 +0100

And everyone else: please don't take up this thread. Let's get the work
we have on our plate done and not get sidetracked again. Generic praise
or criticism of ADSP is currently out of scope.

Stephen. (As chair)

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 19 Aug 2010 10:29:17 -0700

> too much fear of unduely lost email

I wish this were true.  Were it me speaking, I'd suggest that they start looking for ADSP records without acting on them, and draw their own conclusions.

> * BUT otherwise its useless in its current state.

Useless for which purpose?  From the rest of the message it sounds like you're primarily thinking about discussion-type mailing lists, which -- while a popular topic here recently -- are not the only kind of mail DKIM can be applied to.

http://www.maawg.org/sites/maawg/files/news/MAAWG_Email_Authentication_Paper_2008-07.pdf is a very good overview of the theory and applicability of message sender authentication, though some of the terms may be a couple years out of date.  I'd suggest starting there.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 19 Aug 2010 11:18:06 -0700

On 8/19/2010 10:50 AM, Murray S. Kucherawy wrote:
> I would focus on the fact that it, in addition to being a mechanism to thwart
> forgeries, is a framework for providing things like domain reputation.

Sorry, but you have these priorities and foci confused.

dkim's primary use is the attachment of a verifiable label, to be used for
assessment.  The nature of the design of the mechanism makes its ability to be
used for this purpose uncontroversial and very low risk.  The risk, now, is all
market preference, rather than functional. That is, there is no technical risk 
to DKIM's ability to satisfy this requirement.  The extent to which the market 
finds it useful for that purpose is still being established.

The extent to which dkim can also be used to protect against forgeries is, so
far, completely theoretical AND controversial.  We've debated this topic many
times and I'm not trying to claim a certain outcome for that debate.  Merely
noting that it has credible people on both sides and no track record.

Steve Atkins' summary and the Intro to 4871bis have the focus accurate, IMO.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Aug 2010 11:21:18 -0700

> http://www.maawg.org/sites/maawg/files/news/MAAWG_Email_Authentication_Paper_2008-07.pdf is a very good overview of the theory and applicability of message sender authentication, though some of the…

If mailing lists were put out of business by DKIM/ADSP would anybody even notice?
Or care? Mailing lists are from a bygone era, even if we are its fossilized remains.

Mike, not that DKIM would be able to do that, of course
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Aug 2010 11:28:39 -0700

> going to get somewhat more difficult to manage.
IMHO, cryptographic authentication of the SMTP host is needed instead to 
immediately curtail any subsequent traffic.  In addition, DKIM does not 
confirm where the domain sent the message, which makes using DKIM to 
negatively impact a domain for unsolicited email something easily 
poisoned.  Perhaps we should put together an I-D that uses a DKIM key 
with SMTP Auth instead to be ready for IPv6.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Aug 2010 15:51:07 -0400

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Aug 2010 20:56:09 +0100

Folks,

Please. Let's get back to the work at hand and not
spend time on this,

Stephen.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 19 Aug 2010 13:32:53 -0700

> Please. Let's get back to the work at hand and not

Encouraging use of DKIM, and avoiding confusion
between ADSP flaws and DKIM flaws is a big part
of the work at hand, I think. If it's not, it should be.

Cheers,
  Steve

---

From: John Levine <[email-masked]>
Date: 19 Aug 2010 20:50:18 -0000

>Encouraging use of DKIM, and avoiding confusion between ADSP flaws
>and DKIM flaws is a big part of the work at hand, I think. If it's
>not, it should be.

Agreed.  It would be nice to collect enough data about ADSP so we can
figure out whether my take on it or Mike's is closer to reality.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Aug 2010 17:03:10 -0400

> of the work at hand, I think. If it's not, it should be.

Well, unfortunately, 5+ years of work seems to show that hasn't been
possible. I doubt it will ever be possible to ignore what are not
subtle flaws but obvious protocol consistency flaws between WG
documents and ignoring the comments clearly hasn't help as well.
Can't blame me. I can step away and the bugs are still there. :)

---

From: "John R. Levine" <[email-masked]>
Date: 20 Aug 2010 11:26:04 -0400

> Unless you have reason to believe that the signer is taking steps to ensure 
> that the sender information is accurate.

A reputation system could make an assertion like that, but it's definitely 
outside the scope of DKIM.

For about the billionth time, why aren't the people who are worried about 
the identity of individual senders using S/MIME?  I have trouble 
envisioning a problem so serious that we need to invent complex extra 
mechanisms and try to force people to use them, yet so trivial that we 
can't be bothered to use the existing tools built into every MUA.

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 20 Aug 2010 16:01:37 +0100

Unless you have reason to believe that the signer is taking steps to ensure 
that the sender information is accurate. I'd say that a DKIM signature from 
a reputable service provider would quite likely increase the *chance* that 
the sender information is accurate. Of course, you can't be certain (with 
any technology), because any account might be compromised by phishing.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 20 Aug 2010 16:16:42 +0100

--On 19 August 2010 11:18:06 -0700 Dave CROCKER <[email-masked]> wrote:

> assessment.  The nature of the design of the mechanism makes its ability
> to be used for this purpose uncontroversial and very low risk.  The risk,
> now, is all market preference, rather than functional. That is, there is
> no technical risk  to DKIM's ability to satisfy this requirement.  The
> extent to which the market  finds it useful for that purpose is still
> being established.
>

And, one thing's for sure: uptake is everything. Talking DKIM down 
increases the risk that we'll never get widespread domain based reputation 
services.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 20 Aug 2010 15:58:22 +0100

> Responsible for what?  Can I get sued when something goes wrong?

If you're doing stuff that's illegal, then your DKIM signature makes it 
easier to prove a law suit against you. Similarly, if you're not doing 
anything illegal, then your signature could provide evidence of tampering 
by the recipient or a third party.

> technological disclaimer out there.

Yes, I wouldn't call an ADSP user draconian. Defensive (in a neutral 
sense), perhaps.

> But what if it didn't match?  Do you continue sending potentially

Actually, there is filtering usefulness in DKIM, because it can be used in 
conjunction with a reputation database.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 20 Aug 2010 10:24:58 -0700

Daniel, et al,

Persistent misunderstanding of DKIM is a significant problem, and worthy of 
efforts to make corrections.

To that end:

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

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

4.  It enables verifiable accountability, such as is already used for feedback 
loop registration.

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

> bad signatues while allowing mailing list mail through.

This is not a DKIM problem.  Broken signatures are supposed to be treated as no 
signature.

> Given likelyhood of benefits are signficantly lower that costs I'm not seeing

The benefits are significantly higher when the costs and benefits are more 
accurately defined and assessed.

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

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

> 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

DKIM has essentially nothing to do with the task of identifying forged mail, 
nevermind the impossible task of having the end-user doing it.

> 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

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

> 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

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.

d/
-- 

   Dave Crocker

---

From: "Mark Delany" <[email-masked]>
Date: 20 Aug 2010 09:35:50 -0700

> any technology), because any account might be compromised by phishing.

Why isn't a signed 822.From sufficiently accurate sender information
from a provider who cares?

Mark.

---

From: Hector Santos <[email-masked]>
Date: Fri, 20 Aug 2010 13:52:33 -0400

No matter which way you wish to preach this David, and ignore all 
comments, the protocol inconsistency issues in the WG documents are 
clearly present and make it very difficult to employ DKIM with any of 
the WG proposed methods.

Any current DKIM-CORE deployment cited is not used by itself  but 
rather augmented with proprietary methods, special host to host 
arrangements and non-standard solutions.

Resolving the inconsistency with the working WG documents would be 
much welcome. Ignoring it, just continue a status quo of lack of wide 
understanding and usefulness for DKIM from SMALL to LARGE MTAs.

---

From: John Levine <[email-masked]>
Date: 20 Aug 2010 18:18:30 -0000

>from a provider who cares?

The "who cares" bit is a reputation system, you know.

I also suspect that my signing model is fairly typical of small
providers.  I sign everything, and make no effort to validate stuff on
the From: line.  In the unlikely event that one user engages in
hostile spoofing of another, there's enough stuff in the Received:
headers and logs to figure it out.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 20 Aug 2010 11:30:04 -0700

On 8/20/2010 11:18 AM, John Levine wrote:
> ...
>     I sign everything, and make no effort to validate stuff on
> the From: line.

They key point is that DKIM makes no statement about the basis by which a given 
signature is made or not made, AND different signers do indeed have very 
different criteria.

No doubt some do validate the From: field.  Others merely mean "the message went 
through my MTA".  Any assertion of From: field assessment is therefore far 
outside the scope of the DKIM base specification.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Fri, 20 Aug 2010 14:33:04 -0400

> headers and logs to figure it out.

I don't see how because that would represent the anonymous unknown 
world.  However, what is shown is your 5322.From domain if you simply 
exposed a DKIM=ALL (or DISCARDABLE if it applies) policy for your 
IECC.COM domain or any other you are hosting, then all ADSP RECEIVERS 
would be able to protect your DOMAIN reputation from abuse.  You won't 
be responsible for any harm done and further more, the resigner would 
not assume any erroneous responsibility.

All the eyes dotted, tees crossed - common sense protocol consistency 
within WG documents.  You can't development a consistent protocol with 
unknown methods and solutions only privy to MTAs outside this group.

---

From: Hector Santos <[email-masked]>
Date: Fri, 20 Aug 2010 14:41:42 -0400

Dave CROCKER wrote:
> 
> No doubt some do validate the From: field.  Others merely mean "the 
> message went through my MTA".  Any assertion of From: field assessment 
> is therefore far outside the scope of the DKIM base specification.

This is hard to grasp and conflicts with the DKIM base specification 
which makes the 5322.FROM a fundamentally required binding hashed 
entity in the DKIM signature manufacturing.

In additional, the 5322.From header is a historic persistent entity 
from handler to handler. i.e. it can not change for any single and/or 
collective set of signature.

Inherently, there are assessment assertions to be made within DKIM 
5322.From binding requirement - ergo the protocol inconsistency with 
between WG documents.

---

From: Hector Santos <[email-masked]>
Date: Fri, 20 Aug 2010 15:06:13 -0400

Ian Eiloart wrote:
> Actually, there is filtering usefulness in DKIM, because it can be used 
> in conjunction with a reputation database.

Do you mean in lieu of Reputation Information?  Because the question 
above is when it doesn't match.

I just have a problem received two messages:

   MSG #1:  From: [email-masked]
            DKIM-SIGNATURE: .....

   MSG #2:  From: [email-masked]
            (NO DKIM-SIGNATURE)

And MSG #1 is whitelisted with confidence and MSG#2 is passed anyway, 
even if its has been assigned initial dirty score with it, passed to 
users to make a decision themselves.  That is a very risky think to 
pass on to MUAs, especially OFFLINE MUAS where you have no real 
control of what they in mail presentation.

Whatever this "REPUTATION" IDEA is, it still needs some "bit" that it 
expects "something" about domain.com having a signature, right?

I don't see a difference with REPUTATION with regard to the same 
issues people complained about SPF or ADSP:

    known reputation   - make a hard decision - GOOD CITIZEN MODEL
    unknown reputation - soft failure? or Neutral? or Reject?

Do you see a difference? I don't other than one group wants to accept 
the unknown (or learn the badness of the message, if your lucky to 
accumulated repeated scoring) and the other group wants to do 
something about it.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Aug 2010 11:55:40 -0700

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Hector Santos
> Sent: Friday, August 20, 2010 11:42 AM
> Subject: Re: [ietf-dkim] marketing dkim
> 
> Dave CROCKER wrote:
> >

I don't know what you mean by "binding".  DKIM doesn't say From: has to contain any particular value, only that it has to be one of the signed fields.

---

From: "Mark Delany" <[email-masked]>
Date: 20 Aug 2010 13:08:41 -0700

> I don't know what you mean by "binding".  DKIM doesn't say From: has
> to contain any particular value, only that it has to be one of the
> signed fields.

I don't know about binding either, but my point, before this
sub-thread is completely lost, is that the suggestion that a "caring
provider" put in some user identifiable token amounts to the same thing
as asking a "caring provider" to ensure that 822.From can be used as a
user identifiable token.

In other words, there is no need to invent anything new here to
achieve the OP's result. After all, an uncaring provider means that
>From is as reliable as any other user identifiable token, which is to
say, not at all.

So, assuming you can determine a caring provider, then ask them to be
careful about 822.From rather than ask them to invent and insert some
other user identifiable token.

Note: I'm not necessarily advocating the OP's suggestion, just saying
no new token needs to be invented to support it - instead, just make
the recommendation to "caring providers". Job done. Move along.

Mark.

---

From: "Jones, Steven M" <[email-masked]>
Date: Fri, 20 Aug 2010 19:32:35 +0000

I thought it might be useful to chime in here. My goal is simply to show where a commercial sender/receiver might see some value, with Daniel's APNIC presentation in mind. I'm not asserting that any of this applies to a regional ISP per se, but insofar as it applies to their customers they may wish to understand it.

If you want to use any of what follows outside of this mailing list, contact me before doing so.

Bank of America has been using SPF and DKIM for more than a few years now. We have a rich mix of originators of message traffic using various domains and subdomains, located on both sides of traditional corporate boundaries, and targeting different internal and external recipients. We've gone to considerable effort to implement these techniques as widely as possible, and to educate and encourage other corporations to do so.

We have done this because we believe that doing so will enable us to better protect our customers from fraud and abuse, with respect to our brands and relationships. Speaking about this publically may help others reach similar conclusions, which may help protect our customers from being compromised through other brands and relationships. So for us, this is a very real and practical matter.

Early on, even without 100% coverage we were able to address certain issues around bad actors targeting our employees. We found that to be of great benefit, even though it wasn't why we started down this path.

We see real value in DKIM for what we believe it gives us - a way for a receiver to tell whether or not a given message using one of our domains was sent by ourselves or one of our delegates. There are definitely cases where the technique breaks down, and there is also an added cost to our operations, but these factors have not changed our cost/benefit decisions.

There hasn't been much press coverage lately about high-profile bilateral DKIM+SSA adoption, such as the Yahoo and eBay/PayPal arrangement. However in the past year or so several startups have appeared that seek to act as SSA clearinghouses or brokers. This approach certainly seems more practical than a proliferation of bilateral agreements, offering some kind of uniform mechanism while avoiding real/perceived limitations of ADSP - but you've got to have a handle on DKIM to participate.

Also over the past several years a lot of MTA appliance vendors have delivered DKIM functionality that can be used in making receiver filtering decisions. I would suggest that we don't know how many of their customers are using DKIM with a local policy for high-value or certain highly-phished traffic. Consider the use of mandatory TLS to protect messages in transit between specific endpoints - something we know the financial and legal communities have adopted with vigor and real savings, despite any weakness over other solutions. It seems likely to me that something similar is happening with DKIM, though getting the data to back it up would be difficult.

--Steve.

Steven M Jones
ET&D Desktop & Electronic Communications
Bank of America; Concord, California
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Fri, 20 Aug 2010 17:54:48 -0400

Mark Delany wrote:
> On Fri, Aug 20, 2010 at 11:55:40AM -0700, Murray S. Kucherawy allegedly 
> 
> I don't know about binding either, 

hmmmmmmmmmm, I am surprise that I have to be put into an awkward 
position to explain what "binding" means here as digital signature 
term in what I thought was a technical qroup.  Very odd.

It is a well understood computer term especially when talking about 
hashing values and electronic signatures.

Google it:

       binding hash signatures

Here is a hit that might help:

    http://en.wikipedia.org/wiki/Digital_signature

    Digital signatures cryptographically bind an electronic
    identity to an electronic document .......

The term bind or binding is a commonly used in hashing ideas when you 
want to associate parts, as in like Collections or Association Arrays.

For DKIM, when you hash the h= headers, you are technically binding 
values, "entities", parts, to the signature.  Changing any values 
breaks the bind.

Since 5322.FROM is a required binding for DKIM,  it means you can not 
change the 5322.FROM without breaking the signature. This naturally 
implies an digital signature binding assertion that can used for 
security purposes.

I am surprise it is even questioned at this point.  Very odd.

---

From: "Mark Delany" <[email-masked]>
Date: 20 Aug 2010 16:39:23 -0700

> term in what I thought was a technical qroup.  Very odd.

Hector. You are too funny.

You miss the subtlety and then you assume the OP is inexcusably
ignorant.

I just love the Schoolmarm lessons that inevitably follow. Priceless.

Mark.

---

From: Hector Santos <[email-masked]>
Date: Fri, 20 Aug 2010 21:05:54 -0400

Honestly, no assumption of ignorance. I did have a few variations 
"You're joking?... This is a joke right? ... Yeah right!" etc. But 
you're right, I missed any subtlety and should of left it alone. I 
apologize to anyone who felt offended for the Binding 101 lesson. :)

--
HLS

Mark Delany wrote:
>> position to explain what "binding" means here as a digital signature
>> term in what I thought was a technical group.  Very odd.
>

---

From: "John R. Levine" <[email-masked]>
Date: 20 Aug 2010 22:47:11 -0400

> other user identifiable token.

It's fairly difficult to validate From lines when you have users with 
catchall domains, since they can use any address in their domain.

On a system like Yahoo, it makes perfect sense to lock down what the
users can do, since your users are all strangers and when someone wants
to do something unusual, you have to assume it's malicious until proven
otherwise.

On small systems like mine or my ISP, the management has a reasonably good 
idea who the users are, they rarely misbehave, and they have all sorts of 
funky setups with domains, web servers, scripts, or whatever, and there 
aren't throwaway accounts. I have no idea what addresses my users are 
allowed to use, but I add enough stuff to audit the mail in case of 
questions rather than trying to pre-validate anything that might appear on 
the From line.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 20 Aug 2010 23:27:05 -0400

We've had a lot of arguments about the importance of verifying the 
identity of contributors to mailing lists.  If you think that's important, 
take a look at this message.

Even though Mailman has added a subject line tag and a message footer, the 
S/MIME signature still verifies, and your MUA should show a green star or 
whatever, at least once you've told it to import my S/MIME cert.  Mailman 
automagically wrapped the multipart/signed in multipart/mixed.  And the 
signing cert has both my full e-mail address and my True Name.

So I suggest we update the DKIM MLM draft to take out all the stuff about 
signatures surviving lists, and just say that if it's important for your 
signature to survive, S/MIME already does that, with a suitable pointer.

R's,
John

---

From: Daniel Black <[email-masked]>
Date: Sat, 21 Aug 2010 12:58:30 +1000

Thanks for all the comments. I probably don't have quite enough time to 
respond to them individually. I'm responding to say thanks for the bits of 
value that I can actually use to promote dkim and to comply with Stephen 
Farrell's request to move on.

Thanks for the warnings against ADSP=discardable. I'll take this into account.

I'll incorportate comments about forensic verification.

Thanks to those that responded on and offlist to say that DKIM isn't totally a 
reputation company's bait for getting hooked on their services, or useless, 
and does have a use outside of it. Your examples are valuable and thanks.

Appoligies for my small wimper of dispair about where dkim was going.

Lets move on. There's drafts to review.

Daniel

---

From: Hector Santos <[email-masked]>
Date: Sat, 21 Aug 2010 10:51:04 -0400

> signing cert has both my full e-mail address and my True Name.

Sorry John, I don't see any "green star" or any other form of 
certified mail indication in Thunderbird our Outlook. There is also no 
5322 based S/MIME parts in the source message.  Any evidence of that 
expectation by you has been stripped and cleaned at the scene of the 
crime.

> signature to survive, S/MIME already does that, with a suitable pointer.

+1 for removal of any suggestions that broken ADSP protected 
signatures can be restored without conflict.

-1 for adding any reference to S/MIME.  I don't think it is a good 
idea to further complicate this by adding another unnecessary protocol 
interface engineering requirement.

What is ironic is that this message of your 100% exemplifies all the 
concerns and also benefits POLICY proponents have been advocating.

You had an expectation for mail operations, a POLICY regarding S/MIME 
expectations, yet that expectation failed.

Allow people to expose that expectation using standard methods, and 
"receivers" will begin to honor it.