Subject: Re: [ietf-dkim] DKIM charter update proposal

From: "J.D. Falk" <[email-masked]>
Date: Thu, 01 Oct 2009 13:41:21 -0600

Franck Martin wrote:

> Seems to me something is missing: gather data to establish if DKIM specifications have in any way alleviated any misuse of the email system, in particular but not limited to spam, phishing attacks and fraud.

What would that prove, or disprove?

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Franck Martin <[email-masked]>
Date: Fri, 2 Oct 2009 07:56:08 +1200 (FJT)

Is the goal of a spec, the writing of the spec itself, or to tackle a higher goal?

Are we forgetting the original objectives of DKIM, which was to reduce spam? 

I hear a lot about what DKIM is not, fair enough. I hear a lot that DKIM is a tool and not a magic solution, fair enough too. But if we cannot show DKIM helps alleviating spam, then we better use everyone computing cycles for something useful instead.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Oct 2009 13:27:02 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Franck Martin
> Sent: Thursday, October 01, 2009 12:56 PM
> To: J.D. Falk
> Cc: IETF DKIM WG

How can one forget that which was never true to begin with?

The working group and its antecedents, as far as I'm aware, have always been pretty adamant about the fact that reducing spam has never been one of its goals.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 1 Oct 2009 13:23:00 -0700

> Are we forgetting the original objectives of DKIM, which was to  

That wasn't a goal for DKIM. Rather the goal of DKIM was to provide  
additional data to recipients, which could be used in a number of ways.

("While the techniques specified by the DKIM working group will not   
prevent fraud or spam, they will provide a tool for defense against  
them by assisting receiving domains in detecting some spoofing of  
known domains." is the charter wording).

> I hear a lot about what DKIM is not, fair enough. I hear a lot that  
> DKIM is a tool and not a magic solution, fair enough too. But if we  
> cannot show DKIM helps alleviating spam, then we better use everyone  
> computing cycles for something useful instead.

DKIM itself cannot alleviate spam, as it's just a tool for  
authentication. That means that if the only thing you want to measure  
is "How much did DKIM deployment directly alleviate spam" then you're  
going to get an answer that's close to zero.

A more interesting question is how domain based authentication helps  
domain reputation based systems reduce false positives in spam  
filters, or how domain based feedback loops help ISPs and mailers  
avoid sending unwanted email. DKIM itself doesn't do either of those,  
it's just a platform they're based on.

I don't think we're at a point, yet, where the answer to that will be  
particularly enlightening. It may be time to start tracking the data  
if you're not already, though.

Cheers,
   Steve

---

From: Franck Martin <[email-masked]>
Date: Fri, 2 Oct 2009 09:25:42 +1200 (FJT)

----- "Steve Atkins" <[email-masked]> wrote:

> > Is the goal of a spec, the writing of the spec itself, or to tackle 
> 
> > a higher goal?
> >

yes this is what I said, how DKIM helps alleviate spam, I did not say it alleviates spam. If you want to be more pedantic in the question, it is fine with me.

I understand this WG is careful about not promising a magic potion but I'd like to have somthing like the way Steve formulates the question in the workgroup charter, so we don't forget why we do all these things.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Fri, 02 Oct 2009 14:39:42 +0200

Hi Murray,

> The working group and its antecedents, as far as I'm aware, have always been pretty adamant about the fact that reducing spam has never been one of its goals.

I think it was the goal of many who participated to reduce spam.  That
having been said, DKIM by itself cannot reduce spam, and that was always
readily apparent.  DKIM can be used as one of a number of components to
a comprehensive approach to identifying legitimate email.  If all of
that happens, then the economic incentives for spamming would seem to
dwindle.

That's a lot of moving parts, of course.

All of this having been said, I think Scott Kitterman is right.  I still
think the standard needs more soak time.  But that's me.

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Thu, 01 Oct 2009 23:56:55 -0700

> that happens, then the economic incentives for spamming would seem to

For me, it was about limiting the degrees of freedom that bad guys had to
operate in. There will always be bad guys trying to do bad things; the mark
of civilization in general is how much impunity they have. I think that
DKIM moves us in the "civilized" direction.

> think the standard needs more soak time.  But that's me.

I tend to agree, but then again there's only so much navel gazing that a 
standards
body can do. It's now been about 5 years since Y! and we simultaneously
came up with the same general idea. There's been running code for nearly 
as long.
The real question that IETF needs to answer is not whether it's useful 
per se, but
whether there are inherent issues with the protocol which limit its 
utility. I really
haven't heard anything about that though modulo standard carping about
woulda-shouldas from the usual suspects. Maybe there's a vast latent 
pool of
disaffection, but after all this time is there any reason to believe 
that they'll
suddenly appear, issues in hand?

Mike

---

From: hector <[email-masked]>
Date: Fri, 02 Oct 2009 17:33:42 -0400

> think the standard needs more soak time.  But that's me.

My assessment:

My hope was that DKIM would be used to help fight the #1 problem in 
email - legacy (No DKIM mail) spoofs and to raise the bar to address 
DKIM spoofs.

However:

Far too much time was spent on trying to make DKIM fit in an 
environment (Mailing List Servers) where it would inherently have mail 
integrity problems.

The deemphasis of policy did not help where this should of been the 
primary focus and worked out before attempting to "retrofit" it into 
complex mailing list server environment.

When the authors of a WG document and protocol are not firm believers 
of their work, it doesn't help promote the end result.

When you have out of scope concepts being the top priority 
(reputation), when it fact, it should of been in scope due to the 
large # of people who wanted it, it didn't allow for a group synergism 
to be created and "reputation" standard to be developed.  The irony 
here is that every after all that has happen, the re-chapter still 
attempts to keep it out of scope. Very odd.

Instead, a very complex subjective integration requirement 
materialized where there is no working methods or standards to work 
with. When you have software developers who can't agree on what DKIM 
API should or should not be or even its definition, thats a problem. 
In addition, as a result of the mailing list focus without policy, 
DKIM has become more of a Sender Protocol rather than an Original 
Domain Author Protocol - a hop to hop authentication protocol.

Sans Policy, Sans Reputation, DKIM-BASE, as it stands, is an 
unprotected mail signing protocol with a large water down effect - 
high potential for failed signatures, lack of protocol consistency, 
receivers can't trust it especially for anonymous transactions and its 
usefulness is very isolated, thus a low payoff and low adoption rate.

In my opinion, if DKIM can not be easily adopted by 80% of the small 
to mid size market, thats a problem.

---

---

From: <[email-masked]>
Date: Fri, 2 Oct 2009 22:56:44 -0400

while I have enjoyed  participasting in this WG I would like to  
discuss the ability of an ISP to sign on behalf  of an entity that we  
provide all services for. This has generated disinclination  in the  
past but as a provider who has an expressed interest in providing 3rd  
party signatures we need a set of rules/ideas that states I signed  
this message on the behalf of foo.examplemy.client.com. Otherwise DKIM  
is interesting as an artifact but I ill will be signing soon my  
residential emails but have no interest in signing my commercial folks  
unless there is a benefit
thanks,
Bill

---

From: Franck Martin <[email-masked]>
Date: Sat, 3 Oct 2009 23:01:05 +1200 (FJT)

I do not see where is the issue? I 3rd party sign emails and I have not faced any problems with that (Am I missing something?) The providers that check DKIM all include a dkim=pass in the mail headers.

---

From: hector <[email-masked]>
Date: Sat, 03 Oct 2009 08:15:30 -0400

Franck Martin wrote:

> I do not see where is the issue? I 3rd party sign emails and I have not 

 > faced any problems with that (Am I missing something?) The providers
 > that check DKIM all include a dkim=pass in the mail headers.

Franck,

Thats because receivers have yet to support and honor RFC 5617 (ADSP). 
Once they do,  your 3rd party signing of domains with ADSP 
DKIM=DISCARD|ALL are subject to mail rejection/discard at receivers.

RFC 5617 says:

      all       All mail from the domain is signed with an Author
                Domain Signature.

      discardable
                All mail from the domain is signed with an
                Author Domain Signature.  Furthermore, if a
                message arrives without a valid Author Domain
                Signature due to modification in transit,
                submission via a path without access to a
                signing key, or any other reason, the domain
                encourages the recipient(s) to discard it.

What Bill is referring to is the "3rd party Policies" that was part of 
the original SSP specification but pulled for ADSP.

SSP include a "concept" that allowed 3rd party signatures, however, 
the complexity was how do we control (authorize) the 3rd party signer.

In other words, how to we tell the world that 1st party domain 
"santronics.com" allows 3rd party signer domain "genuis.com" to sign 
mail on the behalf of santronics.com.

The proposals were to provide a LIST "somwhere" like in the POLICY 
record.  The draft DSAP proposal offered this feature.  The issue with 
that is how big can that list be.

--
HLS

---

From: hector <[email-masked]>
Date: Sat, 03 Oct 2009 08:33:20 -0400

Franck,

Let me clarify that if your system was checking the ADSP record and 
"skipping" or avoid 3rd party signing of domains with 
DKIM=DISCARD|ALL, then IMO, your system would be protocol consistent 
and behaving correctly.

Blind resigning could cause problems, such as:

1) Receivers rejecting DKIM=DISCARD|ALL author domains with 3rd party
    signatures.

2) Create negative reputation on the 3rd party signer for perpetuating
    continued sending of 1st party ADSP failures.

3) Potentially create a membership removal for continued failure
    at the recipient mail host by not accepting list signed
    distributions.

To mitigate #3, receiver software SHOULD NOT issue a SMTP LEVEL 
negative reply code (45z, 55z) and under ADSP failures, SHOULD
accept the message and silently DISCARD the message as allowed
by RFC 5321 and RFC 5617.  This will resolve issue #3 and also
minimize back scattering.

#2 is still a risk for 3rd party signers if they ignore RFC 5617.

--

hector wrote:

> SSP include a "concept" that allowed 3rd party signatures, however, the 
> complexity was how do we control (authorize) the 3rd party signer.
>

---

From: Steve Atkins <[email-masked]>
Date: Sat, 3 Oct 2009 09:16:48 -0700

On Oct 2, 2009, at 7:56 PM, <[email-masked]> <[email-masked]>  
wrote:

> provide all services for.

You can do that today, in several ways.

> This has generated disinclination  in the

If you have control over the DNS for foo.examplemy.client.com then
you can sign mail with that token. If you don't have control over
it, but the owner of that wants you to sign on their behalf then
they can give you a private key for signing, or delegate a subtree
inside that space ( cox._domainkey.foo.examplemyclient.com)
to you, so you can handle the key management.

And you can sign the message twice, once as cox.com, once
as the customer domain, pretty cheaply.

Can you expand on what you'd like to be able to do that's different
from all those?

Cheers,
   Steve

---

From: Steve Atkins <[email-masked]>
Date: Sat, 3 Oct 2009 14:19:12 -0700

On Oct 3, 2009, at 2:02 PM, <[email-masked]> <[email-masked]>  
wrote:

> I would like cox.com<http://cox.com/> to sign on behalf of a  
> customer a.com<http://a.com/> to z.com<http://z.com/> so
> a checker would lookup a.com<http://a.com/> and see that the cox.com<http://cox.com/ 
> > is the
> authorized signer on behalf of z.com<http://z.com/>

If a receiver receives an email with a selector of foo.cox and
a signing domain of z.com then the existence of a DNS record
like...

  cox._domainkey.z.com NS dkim.cox.com

... tells the recipient that cox.com is one of the authorized signers
for z.com, and that this particular message was signed by cox.com
on behalf of z.com.

If you wanted to make it more explicit that the signing was being
done by Cox there are several ways you could do it - my first
thought would be to add Signed-on-behalf-of: header that was
covered by the DKIM signature.

Cheers,
  Steve

> On Oct 3, 2009, at 12:16 PM, Steve Atkins wrote:
>
>
> On Oct 2, 2009, at 7:56 PM, <[email-masked]<mailto:[email-masked] 
> >> <[email-masked]<mailto:[email-masked]>>
> wrote:
>
> this message on the behalf of foo.examplemy.client.com<http://foo.examplemy.client.com 
> >. Otherwise DKIM
> If you have control over the DNS for foo.examplemy.client.com<http://foo.examplemy.client.com 
> > then
> And you can sign the message twice, once as cox.com<http://cox.com>,  
> once

---

From: hector <[email-masked]>
Date: Sat, 03 Oct 2009 20:45:59 -0400

> On Oct 3, 2009, at 2:02 PM, Bill Oxley wrote:

> 
>> I would like cox.com to sign on behalf of a  
>> customer a.com to z.com so a checker would lookup 

 >> a.com and see that the cox.com is the authorized
 >> signer on behalf of z.com

> covered by the DKIM signature.

How is a.com involved in this solution?

--

---

From: <[email-masked]>
Date: Sat, 3 Oct 2009 17:02:05 -0400

I would like cox.com<http://cox.com/> to sign on behalf of a customer a.com<http://a.com/> to z.com<http://z.com/> so
a checker would lookup a.com<http://a.com/> and see that the cox.com<http://cox.com/> is the
authorized signer on behalf of z.com<http://z.com/>
On Oct 3, 2009, at 12:16 PM, Steve Atkins wrote:

On Oct 2, 2009, at 7:56 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
wrote:

this message on the behalf of foo.examplemy.client.com<http://foo.examplemy.client.com>. Otherwise DKIM

If you have control over the DNS for foo.examplemy.client.com<http://foo.examplemy.client.com> then

And you can sign the message twice, once as cox.com<http://cox.com>, once
as the customer domain, pretty cheaply.

Cheers,
  Steve

---

From: John Levine <[email-masked]>
Date: 4 Oct 2009 03:11:31 -0000

>I would like cox.com<http://cox.com/> to sign on behalf of a customer
>a.com<http://a.com/> to z.com<http://z.com/> so

Keeping in mind that each DKIM signature ties a message to a domain,
so that recipients can apply a the domain's reputation to all of the
signed messages, it's still not clear to me which of these two things
you mean:

A) Mail from a.com is signed by a.com and mail from z.com is signed by
z.com, so each domain has its own reputation, and Cox's involvement is
just administrative.  If a.com moves to another provider, it takes its
signing reputation with it.

B) Cox extends its reputation umbrella over all its customers that all
the mail from a.com and z.com shares the presumably superior
reputation that Cox has developed for cox.com.  If a.com moves
somewhere else, it has to start over developing a reputation or hope
its new provider will offer a similar umbrella.

Which of these do you have in mind?  (They're not exclusive, but I get
the impression you mean one or the other.)  Since DKIM has a
straightforward way to do either or both, what prevents you from using
the methods that DKIM provides now?

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 5 Oct 2009 10:31:54 +0100

Scott Kitterman wrote:
> If advancing DKIM/ADSP along the standards heirarchy is all that's on the 
> table, I think it should wait.  
> 
> Effective rollout of DKIM in large hetrgenous organizations is complex and 
> takes time.  I think it's better to pause for a while and give broad 
> operational experience more of a chance to exercise what has just been 
> standardized.

When we last discussed this, and certainly at the Stockholm meeting,
there did seem to be consensus for moving 4871 along to DS. If other
folks want to wait they should speak up, but for now, I think we do
have WG consensus to do that.

Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 5 Oct 2009 10:36:38 +0100

Franck,

> Seems to me something is missing: gather data to establish if DKIM specifications have in any way alleviated any misuse of the email system, in particular but not limited to spam, phishing attacks…

If you want to propose some specific work items for the WG
then please do so as proposed charter text.

However, I've not really seen much interest or energy for
such work so if you're suggesting something, would it be
safe to assume you're willing to work on it yourself? In
that case, submitting a draft-martin-dkim-foo I-D would
be a good place to start so's we'd have an idea of what
kind of gathering you envisage.

Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 5 Oct 2009 10:38:29 +0100

Thanks Dave,

Let's give it a day or two more to see if anyone else has
suggested changes then Barry & I will think about folding
in your suggestions.

Cheers,
S.

Dave CROCKER wrote:
> 
> Barry Leiba wrote:
>> Description of Working Group:
>>
>>   The Internet mail protocols and infrastructure allow mail sent
>>   from one domain to purport to be from another. While there are
>>   sometimes legitimate reasons for doing this, it has become a
>>   source of general confusion, as well as a mechanism for fraud and
>>   for distribution of spam (when done illegitimately, it's called
>>   "spoofing"). The DKIM working group has produced standards-track
>>   specifications that allow a domain to take responsibility, using
>>   digital signatures, for having taken part in the transmission of
>>   an email message and to publish "policy" information about how it
>>   applies those signatures. Taken together, these will assist
>>   receiving domains in detecting (or ruling out) certain forms of
>>   spoofing as it pertains to the signing domain.
> 
> I suggest replacing the last sentence with something more generic, to avoid the 
> debate about how much any of this pertains to spoofing, per se.  Perhaps instead 
> have a value proposition statement derived from the one in the Overview abstract:
> 
>     These mechanisms permit email receivers to make additional assessments about 
> messages.
> 
> 
>>   While the techniques specified by the DKIM working group will not
>>   prevent fraud or spam, they will provide a tool for defense
>>   against them by assisting receiving domains in detecting some
>>   spoofing of known domains. The standards-track specifications do
>>   not mandate any particular action by the receiving domain when a
>>   signature fails to validate. That said, with the understanding
>>   that guidance is necessary for implementers, the DKIM documents
>>   discuss a reasonable set of possible actions and strategies, and
>>   analyze their likely effects on attacks and on normal email
>>   delivery.
> 
> Delete the first sentence, per my concern above.  At the least, the sentence 
> appears to be largely redundant with the preceding paragraph's last sentence.
> 
> Isn't the second sentence incorrect?  Doesn't DKIM mandate treated a failed 
> validation the same as no signature present?
> 
>>   The previously chartered deliverables for the DKIM working group
>>   have been completed:
>>
>>   * An informational RFC presenting a detailed threat analysis of,
>>     and security requirements for, DKIM. (RFC 4686)
>>
>>   * A standards-track specification for DKIM signature and
>>     verification. (RFC 4871, updated by RFC 5672)
>>
>>   * A standards-track specification for DKIM policy handling.
>>     (RFC 5617)
>>
>>   * An informational RFC providing an overview of DKIM and how it
>>     can fit into overall messaging systems, how it relates to other
>>     IETF message signature technologies, implementation and
>>     migration considerations, and outlining potential DKIM
>>     applications and future extensions. (RFC 5585 and
>>     draft-ietf-dkim-deployment, in its final stages)
>>
>>   (One previously chartered deliverable, a standards-track
>>   specification for DKIM DNS Resource Record(s), was dropped by
>>   agreement between the working group and the Area Directors.)
> 
> Do re-charters usually contain all this history?
> 
> 
>>   The working group is now ready to switch its focus to refining and
>>   advancing the DKIM protocols.  The current deliverables for the
>>   DKIM working group are these:
>>
>>   * Advance the base DKIM protocol (RFC 4871) to Draft Standard.
>>
>>   * Collect data on the deployment and interoperability of the
>>     Author Domain Signing Practices protocol (RFC 5617), and
>>     determine if/when it's ready to advance on the standards track.
>>     Update it at Proposed Standard or advance it to Draft Standard,
>>     as appropriate.
>>
>>   As before, several related topics remain out of scope for the DKIM
>>   working group. These topics include:
>>
>>   * Reputation and accreditation systems. While we expect these to
>>     add value to what is defined by the DKIM working group, their
>>     development will be separate, and is out of scope for the DKIM
>>     working group.
>>
>>   * Message content encryption.
>>
>>   * Additional key management protocols or infrastructure.
>>
>>   * Signatures that are intended to make long-term assertions beyond
>>     the expected transit time of a message from originator to
>>     recipient, which is normally only a matter of a few days at
>>     most.
>>
>>   * Signatures that attempt to make strong assertions about the
>>     identity of the message author, and details of user-level
>>     signing of messages (as distinguished from domain-level keys
>>     that are restricted to specific users).
>>
>>   * Duplication of prior work in signed email, including S/MIME and
>>     OpenPGP.
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 5 Oct 2009 10:43:58 +0100

Folks,

To make life a little easier for us all, (well, mainly Barry
and I:-), could you please keep this thread to discussion of
the proposed charter update.

And where you've thoughts on that, specific alternate
text would be appreciated.

Thanks,
Stephen.

PS: I see John L. has done the right thing and changed
the subject line, maybe reply to that if that's what you
want to chat about.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 5 Oct 2009 09:55:46 -0400

I'm going to reply to this point in both threads, so people who just
read the charter thread see it.  Please continue any discussion of it
over in the "gathering data" thread.

On Wed, Sep 30, 2009 at 2:01 PM, Franck Martin <[email-masked]> wrote:
> Seems to me something is missing: gather data to establish if DKIM
> specifications have in any way alleviated any misuse of the email system,
> in particular but not limited to spam, phishing attacks and fraud.

On Mon, Oct 5, 2009 at 8:27 AM, Franck Martin <[email-masked]> wrote:
> I just had the feeling, seeing all the presentations, blogs ,etc... about DKIM
> that we have forgotten why it was created on the first instance, and I just
> wanted to put it back there where it belongs.
>
> Like now each RFC must have a security consideration chapter, should
> email(and other messaging) related RFCs have a spam consideration chapter?
>
> So as for the workgroup charter, it seemed all for refining the DKIM specs,
> forgetting the original goal, but then I also realize the goal of reducing spam
> was skilfully removed from the original charter (yeah, I should read the past
> charters first ;) )

It's not a question of skill, though thanks for the vote of confidence
there. :-)

It really was a question of focus: DKIM has never been meant to
address spam directly, but to be a tool to enable other mechanisms to
address spam.  That's reflected in the charter, both the old one and
the proposed new one.

I like the idea of having spam considerations in email-related
documents, actually.  I think the right place for that is in the
Security Considerations, and I think the Apps ADs should be the ones
responsible for making sure that spam-related considerations are in
there when appropriate.  Good idea.

To the point of gathering data, two things:

1. I agree that it's very important to do the data collection and
analysis.  It's also something that people are doing: I know that
Cisco is keeping track of various DKIM stats, and has shared partially
anonymized versions with us before.  Dave is collecting data, through
his surveys, on the deployment and use of DKIM.  Both Dave, as MAAWG
technical advisor, and I, as IETF liaison to MAAWG, will be getting
data, over time, from MAAWG members who use DKIM.

2. The IETF standards track has specific emphasis at the different
maturity levels (see RFC 2026).

For Proposed Standard, we need rough consensus that a protocol will be
useful, will interoperate, and is well designed.

For Draft Standard, we need to demonstrate that it does interoperate,
and that we have "sufficient operational experience".  Note that RFC
2026 says, "A Draft Standard may still require additional or more
widespread field experience, since it is possible for implementations
based on Draft Standard specifications to demonstrate unforeseen
behavior when subjected to large-scale use in production
environments."  That doesn't mean that we know, yet, that it's as
useful as we'd hoped or would like.

For (full) Internet Standard, we need "significant implementation and
successful operational experience", "a high degree of technical
maturity," and "a generally held belief that the specified protocol or
service provides significant benefit to the Internet community."  This
is the level at which we need to show how useful it is -- that it's
actually accomplishing what we'd like it to, and that it's a
"significant benefit".

DKIM might or might not get to full Internet Standard, but that's not
what we're aiming at now.  We do want to collect the data Franck is
talking about, and we are doing so.  And if there's consensus to put
that in the charter, I'm happy to do so (so far, only Franck has asked
for it).  But it's not a prerequisite for moving to Draft Standard.
On the other hand, it's entirely possible that moving to Draft
Standard is a prerequisite for getting the wide-spread deployment
needed to see the real usefulness.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 5 Oct 2009 10:07:50 -0400

>    These mechanisms permit email receivers to make additional assessments about

It's been an ongoing complaint of mine (and of others) that
re-charters are hard to review, because a new charter is usually
thrown at us with no indication of what's changed.  With that in mind,
I wanted to make this one easier for folks to review.  So I structured
it this way:

1. Explanation of the working group.  For this, I changed the two
paragraphs that are there as little as possible, only changing the
tenses from future to past.  I intend to mark them as "unchanged from
the original", so it's easier on the reviewers.  Also, this text was
already approved, when we were first chartered.

2. Explanation of the current state.  That's the list of work items
already done (the "history", as Dave puts it).

3. Plan for the future.

(And then 4. What's still out of scope.)

Because I want the working-group description to be unchanged to the
extent possible, I'd rather leave the text as is.  On the other hand,
I certainly agree with Dave's suggestions, so if consensus is to make
the change, I'll do so.  I'd like to hear other comments about it.

> validation the same as no signature present?

That's not what that sentence means.  It means that the specifications
don't tell you to do anything particular to the message in that case.
The intent was to point out that we don't say, "If the signature fails
to validate, be suspicious of the message," or "delete the message,"
or anything like that.

> Do re-charters usually contain all this history?

I thought it was useful to include it.  If there's consensus not to,
or if Pasi thinks it's clutter, I'll remove it.

Barry (as participant, editing new charter)

---

From: "MH Michael Hammer \(5304\)" <[email-masked]>
Date: Mon, 5 Oct 2009 09:37:56 -0400

In light of the comments by Bill Oxley and my belief that the ability of
a domain to designate signing by a specified 3rd party is useful, I'd
like to see this included in the update. I believe this would be useful
for ISPs as well as ESPs. I don't have any specific wording or proposals
on this.

Michael Hammer - [email-masked]
Web Operations Security
AG Interactive/americangreetings.com

> [email-masked]] On Behalf Of Stephen Farrell
> Sent: Monday, October 05, 2009 5:44 AM
> To: IETF DKIM WG

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 05 Oct 2009 07:44:45 -0700

MH Michael Hammer (5304) wrote:
> like to see this included in the update. 

Such an addition is the equivalent of adding an access control list (ACL) to 
DKIM. This was debated extensively before and the working group noted that an 
adequate control mechanism already exists in DKIM:  selectors.

At its core, this change seeks to have recipients enforce authorization to use 
DKIM by an agent that is within the a "sender's" sphere of control.  Even though 
the agent is an independent actor, they have an arrangement with the sender and 
are therefore within their sphere of control.  ACLs are a significant bit of 
mechanism.

Rather than invent an entirely new mechanism that adds to the complexity of the 
recipient's DKIM handling, the same level of useful information is imparted by 
having the sender and signer coordinate so that the signer uses a selector for a 
domain (or sub-domain) of the sender.

This moves the work to (only) the folks who have the clear need and motivation, 
and it requires no additional changes to DKIM.

However what this repetition of a resolved item does suggest is that we ought to 
generate a document that gives specific details for specific scenarios, beyond 
what is already in the Deployment document:

    <http://www.ietf.org/id/draft-ietf-dkim-deployment-08.txt>

Apparently, the detail in its sections 6.3 and 6.4 isn't sufficient.

d/

-- 

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

---

From: "MH Michael Hammer \(5304\)" <[email-masked]>
Date: Mon, 5 Oct 2009 10:55:57 -0400

I am not necessarily advocating that this be added to DKIM base. My ox
isn't being gored on this issue but I recognize that it may not be as
resolved as Dave states. It may not always be as simple as Dave
indicates for senders and signers to "coordinate" in the manner he
suggests. 

To the extent that it is currently more difficult than less for ISPs and
ESPs dealing with a lot of domains that belong to their customers, I
still believe it is worth considering this revisiting this issue.

This is not quite the same as an ACL in the commonly used sense. I view
it more as a simple statement..... this domain signs for my mail as if I
signed it myself.

Mike

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Monday, October 05, 2009 10:45 AM
> To: MH Michael Hammer (5304)
> Cc: IETF DKIM WG
> Subject: Third-party "authorization"
> 
> 
> Such an addition is the equivalent of adding an access control list
(ACL)
> to
> DKIM. This was debated extensively before and the working group noted
that
> an
> At its core, this change seeks to have recipients enforce
authorization to
> use
> DKIM by an agent that is within the a "sender's" sphere of control.
Even
> though
> are therefore within their sphere of control.  ACLs are a significant
bit
> of
> mechanism.
> 
> Rather than invent an entirely new mechanism that adds to the
complexity
> of the
> having the sender and signer coordinate so that the signer uses a
selector
> for a
> However what this repetition of a resolved item does suggest is that
we
> ought to
> generate a document that gives specific details for specific
scenarios,
> beyond

---

From: John Levine <[email-masked]>
Date: 5 Oct 2009 14:57:11 -0000

>for ISPs as well as ESPs. I don't have any specific wording or proposals

If you want to do that, please start with a clear explanation of the
reasons that the current methods to delegate signing to a third
party are unusable.

My impression is that when we get down to the nuts and bolts, this has
invariably turned out to be an argument that it is too hard to get
people to set up the DNS records currently needed to do delegated
signing, but it would be easy to get them to set up some other kind of
DNS records.  The chance of getting anything through the IESG with
that argument is zip, so I wouldn't bother.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 05 Oct 2009 08:06:16 -0700

MH Michael Hammer (5304) wrote:
> I am not necessarily advocating that this be added to DKIM base.

Understood.  It is, nonetheless, additional mechanism, where the desired 
functional control can be achieved by using what is already available.

Additional mechanism is expensive.  And it incurs the challenge of getting 
everyone to adopt it.  Using what is already available only requires adoption by 
those with the highest motivation.

> My ox

The fact that some sender/signer situations might have some difficulty 
coordinating doesn't justify adding an entire layer of mechanism that needs to 
be adopted by everyone.

> still believe it is worth considering this revisiting this issue.

Here's my suggestion:

      You should document the specific details for adoption and use by all of 
the affected actors, for each approach.  One set of details for using a 
selector-based mechanism and one set of details for using an ACL.  Include a 
statement about who does and does not have to adopt it.  Then compare the degree 
of effort and the motivation of the actors.

> it more as a simple statement..... this domain signs for my mail as if I

That puts it into a category like Unix "group" authorization (self/group/other) 
and that is driven by an underlying list of members.  It's an ACL.

d/
-- 

   Dave Crocker

---

From: "MH Michael Hammer \(5304\)" <[email-masked]>
Date: Mon, 5 Oct 2009 11:19:22 -0400

Perhaps the appropriate answer might be an update or addendum to best
practices document or an informational document. 

Mike

> Sent: Monday, October 05, 2009 11:06 AM
> Subject: Re: Third-party "authorization"
> 
> 
> 
>       You should document the specific details for adoption and use by
all
> selector-based mechanism and one set of details for using an ACL.
Include
> a
> statement about who does and does not have to adopt it.  Then compare
the
> degree

---

From: John Levine <[email-masked]>
Date: 5 Oct 2009 15:54:10 -0000

>practices document or an informational document. 

Sure.  What I've been hearing tells me that people need better DNS
provisioning tools, not another wart in DKIM.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Oct 2009 09:21:51 -0700

> [email-masked]] On Behalf Of Barry Leiba
> Sent: Monday, October 05, 2009 6:56 AM
> To: Franck Martin
> Cc: IETF DKIM WG

It seems to me based on my own experience that the turning point for adoption is not the progression from proposed standard to draft standard, but the issuance of an RFC (which has already happened).  Public perception appears to be that when an RFC comes out, the protocol is no longer in flux and is thus "safe" or "worth it" to implement.

So I don't believe that moving DKIM to draft standard will mean there's a big surge in adoption, thus allowing statistics to be gathered.  I think the next big surge of adoption will occur when something extremely useful, like domain reputation, is built on top of DKIM.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Oct 2009 09:20:56 -0700

> [email-masked]] On Behalf Of MH Michael Hammer (5304)
> Sent: Monday, October 05, 2009 8:19 AM
> To: [email-masked]
> Cc: IETF DKIM WG
> Subject: Re: [ietf-dkim] Third-party "authorization"
> 
> 

So this is an opportunity for me to get something clarified:

Is the deployment draft supposed to be a BCP, or are we talking about something new here?

---

From: Douglas Otis <[email-masked]>
Date: Mon, 05 Oct 2009 09:45:50 -0700

> provisioning tools, not another wart in DKIM.

John,

Creating a method to "authorize" mailing lists might represent such a 
use without causing a wart to appear.  Suggesting mailing lists arrange 
selectors that perhaps use CNAME references arranged by authorizing 
domains to point to their current public key, to then allow these 
third-party domains to become indistinguishable from the domains 
offering authorization represents an unsatisfactory and insecure 
approach, and this should be seen as a wart.

Selector or key exchanges would also represent the coordinated 
interaction between from two or more administrators, that will need to 
be maintained as selectors or keys are updated.

There was a suggestion on par with ADSP that used a single query to 
answer whether some party had been "authorized" to sign on behalf of the 
domain.  This approach scales to _any_ level without requiring 
additional queries.  This approach only requires a single administrator 
to make the authorizations, without coordination with the signing domain 
being authorized.

I would be happy to update the draft that gave an example how this might 
be done.  The suggestion that careful and routine coordination between 
two or more domains, to accomplish what would appear to represent a 
first party signature, overlooks the value of having a clear 
"authorization" of a third-party signature.  DKIM policies, in a similar 
manner as that of ADSP, could be conveyed and likely offering actionable 
information for a greater percentage of the grey area cases where this 
policy information is most needed.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Mon, 05 Oct 2009 11:23:03 -0700

> have WG consensus to do that.

I don't remember when we last discussed this, but of course consensus
"in the room" at Stockholm needs to be confirmed via the mailing list.

In any case, I generally agree with Scott -- pushing this along the
standards track seems to me to be premature given the number of use
cases that need to be considered in the case of DKIM.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Mon, 05 Oct 2009 11:36:33 -0700

> reasons that the current methods to delegate signing to a third

Yes, and please also explore the scaling characteristics of such a
scheme.  It's one thing to say that isp.com signs for a.com or z.com,
but this would also need to support the third party signers of a large
enterprise domain, like maybe cisco.com.  I don't know how many we have,
but there are lots:  benefits providers, events organizers, online
survey providers, and senders of various marketing campaigns.  Not to
mention, possibly, mailing list domains.  Whatever third-party signer
list is supported needs to support an effectively unbounded list of
third-party signers for some domains.

In addition, I foresee a problem with publishing such a list, in that it
would very conveniently show who we use for various services, which is
in the aggregate proprietary information.  At the very least it might be
viewed as an endorsement on the part of the domain being signed, which
the legal people won't like.

-Jim

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 05 Oct 2009 15:37:58 -0600

> if you're not already, though.

Similarly, I don't think we're at a point where any discussion of 
standardizing domain reputation systems -- any more than we're at a point of 
standardizing IP reputation systems.  There's a lot more experimentation 
that needs to happen (and is happening) before anything could be considered 
standard enough for an IETF document.  I'd expect to see (and may offer) 
competing "considerations for..." drafts before there's anything close to a BCP.

So, where does that leave the DKIM WG?  I think it leaves us exactly where 
we were before: reputation assessment is, and should be, out of scope.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 06 Oct 2009 17:18:24 +0100

> for ISPs as well as ESPs. I don't have any specific wording or proposals

At item I would like to see is some clear guidance to mailing list  
expanders (otherwise they are all going to do it differently). It may turn  
out that there is no "one size fits all" solution, but I doubt that 57  
different solutions would be needed either.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: hector <[email-masked]>
Date: Tue, 06 Oct 2009 13:45:50 -0400

> different solutions would be needed either.

First, For any 3rd party signer, there is one commonality - it MUST 
honor RFC 5617 (ADSP) otherwise it is adding risk to the 1st party 
domain and to its own operations.

Until this is recognized, I don't see any hope whatsoever on getting 
any additional 3rd party signing controls.

I'm a list server developer and I can see how I can sleep like a baby 
thinking we can blindly sign any domain passing thru the system 
without creating issues for ourselves or the domain itself.

I can see the explicit agreement established with DNS provisioning 
working between two parties working. These are concrete contracts. 
There is built-in indemnification, authorization.

But the blind 3rd party signing of the 1st party is the problem.

Second, even if the MLS begins to honor RFC 5617 which to me would be 
a major step forward for greater DKIM adoption,  we are still missing 
a policy that tells a MLS they are "Allow To Resign".

We have the following:

    UNKNOWN, I DON'T CARE WHO SIGNS
    ALL, I ALWAYS SIGN, JUST DON'T GO NUTS REJECTING MAIL
    DISCARD, I ALWAYS SIGN, REJECT INVALID MAIL!!

We have two considerations:

    ALWAYS,  MAIL IS ALWAYS SIGNED BY ME OR SOMEONE ELSE
    ALWAYS,  MAIL IS ALWAYS SIGNED BY ME OR SPECIFIC DOMAIN

The latter is the concern by some that we would never be able to scale 
an unbounded authorization list of specific 3rd party domains.

I ask these design questions:

1) Why does it have to be unbounded?  Why can't there be a limit?  I 
personally do not see the majority of these cases to have a need for 
unbounded list.  If so, its just a case of more DNS provisioning. I 
don't join all the mailing list without some knowledge of who they 
are. I would love the opportunity to declare that mipassoc.org or 
gmail.com is signing on behave of my domain.  I am not going to want 
or need to have room for 50, 20, 30 or ever 10 mailing list 3rd party 
signing domains.

2) Do we need a LIST at all?  Why not just the statement itself 
"ALWAYS SIGNED by anyone" sufficient and then allow the expected 
"Domain Reputation Layers" to augment a more complete solution?

Unfortunately, the status quo right now RFC 5617 is useless and that 
promotion has made it not supported by some list servers, including 
this mail list server.

If we can't a list server like Mipassoc.org to support RFC 5617, I 
don't see any hope in 3rd party signer Policy discussions.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 7 Oct 2009 16:20:48 -0400

> Is the deployment draft supposed to be a BCP, or are we talking about something new here?

draft-ietf-dkim-deployment, whenever the authors get back to me with a
last round of nit-fixes, is being submitted to the IESG as an
Informational RFC (not BCP).

Barry

---

From: Barry Leiba <[email-masked]>
Date: Sun, 18 Oct 2009 11:54:47 -0400

Coming back to this: I've still seen very little direct input on the
charter proposal.  JD likes it.  Dave made some specific comments,
which I responded to; there've been no other comments on what Dave's
said.  There've been no other specific proposals for changes to the
text.

Franck suggested gathering data on whether DKIM has been useful.  I
responded to that, saying that I don't think it's a necessary issue
for chartering at this stage.  Agreement or disagreement with that
would be useful.

Bill suggested looking at extensions for additional signature
delegation, Michael Hammer agreed, and a thread branched off from
there.  Is that still an active consideration for the charter, or not?
 Charles wants to see something more about guidance for mailing lists.
 Is that an active consideration?

Some have opined that it's even too early to consider taking the base
DKIM protocol to Draft Standard; let's make sure we have consensus on
that point, one way or the other.

I'd like to settle very soon on what, if anything, to do about
re-chartering.  Please address my specific points, above, so we can
get there.  And please keep the discussion focused on the charter,
without going into lengthy discussion of details of the work.

Barry, as chair

On Wed, Sep 30, 2009 at 12:00 PM, Barry Leiba
<[email-masked]> wrote:
> Pasted below is my proposal for an updated DKIM WG charter.  Stephen
> has reviewed it and agrees, and now it's the working group's turn.
>
> I've kept two of the paragraphs from the original introduction,
> changing only the tenses, from things like "will produce" to "has
> produced".  I've turned the original deliverables list into a summary
> of what's been delivered.  I've put in new deliverables that basically
> amount to "advance the two protocols through the standards process, as
> appropriate."  And I've left the "this stuff is out of scope" section,
> because it's my sense that we still want to stay away from those
> items, at least for now.
>
> Please comment on it.  If you like it, please say so.  If you want
> changes, please specify, and suggest specific text.  If you don't
> care, and just want to get out of here, that's useful input as well.
> Let's define a two-week comment period, which we'll extend if
> needed... so, comment as soon as possible, and no later than Friday,
> 16 October.
>
> Barry, as chair
>
> ----------------------------------
> Domain Keys Identified Mail (dkim)
> ----------------------------------
>
>  Chairs:
>     Stephen Farrell <[email-masked]>
>     Barry Leiba <[email-masked]>
>
>  Security Area Directors:
>     Tim Polk <[email-masked]>
>     Pasi Eronen <[email-masked]>
>
>  Security Area Advisor:
>     Pasi Eronen <[email-masked]>
>
>  Mailing Lists:
>     General Discussion: [email-masked]
>     To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim
>     Archive:      http://mipassoc.org/pipermail/ietf-dkim/
>
> ----------------------------------
>

---

From: hector <[email-masked]>
Date: Sun, 18 Oct 2009 12:17:34 -0400

> there.  Is that still an active consideration for the charter, or
 > not? Charles wants to see something more about guidance for
 > mailing lists. Is that an active consideration?

Barry,

(shaking head)

Is there a reason why my suggestions are off the table?

Namely, codify the existing specification and specifically adding 
simple text that imply:

    Forwarders SHOULD|MUST NOT break ADSP domain messages.

or

    Forwarders  SHOULD|MUST take into account ADSP Domains
    before stripping and resigning or signing ADSP domain messages.

Why is this not a legitimate consideration for rechartering - Codify 
the existing RFC specifications? Can you explain why it would not be 
thus not even include it in your suggestions?

I believe the ADSP/FORWARDER guidelines are needed to help SMTP and 
List Server developers and implementators guide their software designs 
or operational setups.

I even suggested a far fetch possibility to "deprecate" RFC 5617, if 
thats all even IETF procedurally possible, to help remove this 
on-going dispute.  I can understand this would be extreme, but there 
was a agreement but another person with this.

---

From: SM <[email-masked]>
Date: Sun, 18 Oct 2009 10:06:21 -0700

>Coming back to this: I've still seen very little direct input on the

[snip]

> >  The previously chartered deliverables for the DKIM working group

There has been a lot of discussion of these deliverables after the 
RFCs were published.  Reinterpretation of the specifications can only 
lead to confusion and has a negative influence on implementation and 
deployment.

> >  * Advance the base DKIM protocol (RFC 4871) to Draft Standard.

The base DKIM protocol is updated by RFC 5672.  In my opinion RFC 
4871 cannot be advanced to Draft Standard status without RFC 5672.

> >    Update it at Proposed Standard or advance it to Draft Standard,

I cannot support advancing RFC 5617 to Draft Standard.  The message 
posted by one of the WG Chairs at 
http://mipassoc.org/pipermail/ietf-dkim/2009q4/012747.html summarizes 
why I don't think that it is useful to have the discussion.

Regards,
-sm

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 18 Oct 2009 19:48:28 +0100

> 4871 cannot be advanced to Draft Standard status without RFC 5672.

Yes. The intent as I understand it is not to declare 4871 as DS but
to write a 4871bis draft that folds in the changes from 5672.

S.

---

From: hector <[email-masked]>
Date: Sun, 18 Oct 2009 14:49:47 -0400

> why I don't think that it is useful to have the discussion.

if the resolution is not possible using any update process, such as 
the Deployment Guide, then +1, I can not support advancing RFC 5617 to 
Draft Standard.

---

From: John Levine <[email-masked]>
Date: 18 Oct 2009 20:31:25 -0000

I concur with the plan to advance DKIM to draft standard.  It's not
clear to me as a matter of IETF politics whether we can advance
4871+5672 as a unit to draft standard, or if it's mandatory to make
another pass and turn them into one document.  I'd rather avoid that
pass if at all possible since the worms in this particular can are
unusually wriggly.

Re the ADSP data collection, I'd like to add a third option to move it
to Historic if ADSP turns out to be as useful as I think, but I
realize this is unlikely to be a popular suggestion.

Re the other stuff, it's way too early to make changes.  At some point
it might be useful to update the usage guide on hot button issues like
signing for your customers and DKIM vs. mailing lists, but we need
actual experience first.  At this point it's just guessing to argue
whether there are in fact any problems that the current DKIM cannot
solve that a modified version could.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 18 Oct 2009 16:52:59 -0400

>that point, one way or the other.
I'm going to re-iterate my point for this perspective.  We do not yet have 
a broad experience base with deployment of DKIM by large, heterogeneous 
organizations.  This is a hard problem for them because they first have to 
get their outbound mail architecture under control.  

My view is that these types of deployments are the ones that will teach us 
the most about the protocol and we are at least a year and maybe two or 
three from getting significant experience/feedback to support progressing 
DKIM along the standards track.

The methaphorical ink is barely dry from our last update (which was eith 
much ado about nothing or a correction of a serious problem, I'm not quite 
sure which).

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Sun, 18 Oct 2009 15:08:10 -0700

> get their outbound mail architecture under control.

It's actually a very easy problem, or at least an incremental one,
as there's no need whatsoever to get all their mail architecture
under control at once.

Attaching a DKIM token to an outbound mail benefits that mail,
even if other mail from the same sender doesn't have a token. The
potential benefit to each individual mail increases as more mail
has the same token, but it starts as soon as some mail has it.

So DKIM can be deployed incrementally, one server, one
location or one application at a time, and will add benefit
to senders of wanted email immediately.

> DKIM along the standards track.

Perhaps.

I don't think that that particular decision is going to affect
real world deployment at all, though, so it's not something
I see as desperately important either way.

I do think that any plan that's based on actually changing
the protocol in two or three years time in any way that's
not localized to a black box MTA implementation, is likely
to be unfruitful.

A widely deployed base of a "good enough" implementation
is going to be hard to change, for the social reasons I
suspect most people here are familiar with.

Cheers,
   Steve

---

From: Barry Leiba <[email-masked]>
Date: Sun, 18 Oct 2009 18:12:12 -0400

> (shaking head)

No need to do that, nor say that.

> thus not even include it in your suggestions?

Oversight.  It's certainly a valid way to proceed, and it should be
included in the discussion.

You'll need to clarify where you think this text should go.  Note that
RFC 5617 does not "update" RFC 4871, using "update" in the RFC sense.
That means that no one implementing DKIM base is told to go read ADSP
and get more implementation information there.  They can do ADSP or
not, as they please.

That also means that if we add your text to ADSP, it won't help
implementations that do DKIM base only.

If we add your text to DKIM base, it must go through another cycle at
Proposed Standard, and can't be moved to Draft Standard yet.

Now, that's a perfectly good thing for the working group to decide to
do, so it's absolutely in scope for discussion.  I'm pointing this out
so it's clear what the process will be.

> was a agreement but another person with this.

This is basically John Levine's suggestion, in his branch-off thread

> realize this is unlikely to be a popular suggestion.

"Historic" is the proper way to take a protocol out of current use.
There's also a stronger mechanism, if we should decide that it was
SUCH a bad idea that we really wanted to tell people, "NOOOOO!  DON'T
USE IT!": we could make an "ADSP Considered Harmful" RFC that
officially updates 5617.

I personally think it's way too early to consider any of this now,
which is why the ADSP step in the proposed charter starts with data
collection and analysis.

But I will change my working version of the proposal to make it clear
that we have flexibility in what to do after the analysis is done:

 * Collect data on the deployment and interoperability of the
   Author Domain Signing Practices protocol (RFC 5617), and
   determine if/when it's ready to advance on the standards track.
   Take action as appropriate -- update it at Proposed Standard,
   advance it to Draft Standard, move it to Historic, or some other
   action that the working group decides.

How's that?

Barry

---

From: Barry Leiba <[email-masked]>
Date: Sun, 18 Oct 2009 18:16:21 -0400

> 4871 cannot be advanced to Draft Standard status without RFC 5672.

As Stephen says, the intent has always been to roll 5671 into 4871.
That was one reason we wanted to get 5672 done as quickly as possible,
so that the six-month timer wouldn't get in our way.  By the time
we're ready to have 4871bis out as DS, if that's what we decide to do,
the text in 5672 will be mature enough to include in it.  I will
re-word that bullet to say "4871 + 5672".

> I cannot support advancing RFC 5617 to Draft Standard.

That's fine.  That work item doesn't say we'll do that.  It says that
after more time, and data collection and analysis, we will decide
what's appropriate (and see the message I just posted in response to
Hector).

Are you saying that you can't support a charter that even has the
working group *consider* DS for ADSP?

Barry

---

From: Barry Leiba <[email-masked]>
Date: Sun, 18 Oct 2009 18:20:47 -0400

> DKIM along the standards track.

ACK.

I should point out -- just as a process point -- that moving from PS
to DS is not a statement that we have a great deal of operational
experience and that this is a solid, mature protocol.  That happens
when we go from DS to full Standard.  The move to DS says that the
protocol is stable and has been shown to interoperate.  It's possible
to move what we have to DS, then decide it needs updating -- in which
case the update goes back to PS again.

That's not to express an opinion on Scott's point at all... just to
make the process issues clear.

Barry

---

From: hector <[email-masked]>
Date: Sun, 18 Oct 2009 20:02:23 -0400

> implementations that do DKIM base only.

+1, Please make a note of this point you made here with the notes I 
have made and the one I will surmise below.

> which is why the ADSP step in the proposed charter starts with data

+1.

I respect the idea that ADSP and another "add-on" or "extended" DKIM 
technology is 100% optional.

However, the "data collection and analysis" have shown me that this 
only applies or the written guidelines only applies to receivers.

The implementation problems begin with intermediaries, more 
specifically, remailers, forwarders, middle ware such as a mailing 
list server.

I can make our SMTP receiver ignore or not support ADSP, but I can't 
ignore it for our remailers (Mail List Server).

Do you see the difference here?

All I have ask that we address this issue regarding remailers.

>    action that the working group decides.

I have no issue with this wording as long we encompass all the 
possible solutions with a strong look as to why there is a barrier to 
wide adoption.

We want field testing and data collection, but its like a chicken and 
egg situation.  It is prohibitive for anyone to even bother with ADSP 
because of the remailer issue.  I think many people want to support it 
,but they can't. No one can. Therefore I see little chance of anyone 
collecting data because the "experiment" or R&D process is crippled 
from the outset.

Finally, the text I proposed was based on my offlist question and your 
offlist suggestions to me.  That is why this specific issue note with 
suggested correction was posted:

     http://mipassoc.org/pipermail/ietf-dkim/2009q4/012648.html

proposed additional text for Deployment Guide 6.5.

   "Before any forwarder attempts to modifies messages and add
   a new signature to the message, it SHOULD look at the
   ADSP record for the 5322.From domain.   If the domain has
   an ADSP record with "dkim=all" or "dkim=discardable", the
   forwards SHOULD NOT forward the message.

      Note: Forwarders who do not support ADSP should be aware
      bounce mail may be result.  For mailing list systems,
      false subscriber removal notifications can occur when
      subscribers MDA receivers are supporting ADSP.

   See section 6.1 for ADSP support recommendations."

With this, it it my opinion, that implementators will have more 
information to work with when they begin their software redesigns or 
operators change their scripts, etc.   Allow them to decide add this 
or not.   Then we begin to see how effective or ineffective ADSP will be.

One last note:  This was not new. The old expired 2006 DSAP provided 
some guidance here as well:

    http://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-12

    3.3. Mailing List Servers

    Mailing List Servers (MLS) applications who are compliant with DKIM
    and DSAP operations, SHOULD adhere to the following guidelines:

    Subscription Controls

    MLS subscription processes should perform a DSAP check to
    determine if a subscribing email domain DSAP policy is restrictive
    in regards to mail integrity changes or 3rd party signatures.  The
    MLS SHOULD only allow original domain policies who allow 3rd party
    signatures.

    Message Content Integrity Change

    List Servers which will alter the message content SHOULD only do
    so for original domains with optional DKIM signing practices and
    it should remove the original signature if present.  If the List
    Server is not going to alter the message, it SHOULD NOT remove the
    signature, if present.

There has been a number of people then and even today who agree that 
the above are helpful notes and/or begins to mitigate this long time 
issue for remailers as well as for domains who wish is to be protected 
by SSP (ADSP).

Thats all and I will try to make this my final input on this.

Thanks

---

From: Daniel Black <[email-masked]>
Date: Mon, 19 Oct 2009 12:00:17 +1100

> for chartering at this stage.  Agreement or disagreement with that

I think supporting data collection by those deploying it would be facilitated 
by getting http://tools.ietf.org/html/draft-kucherawy-dkim-reporting-05 to a 
RFC would be good. Eventually we should come back to data collection later 
though.

> there.  Is that still an active consideration for the charter, or not?
Doug and myself have been refining a draft that should be out soon for comment 
so I think this is good for the charter.

>  Is that an active consideration?
Definitely.  By giving then guidance up frount there will be fewer, or 
consistent signature failures for the verifiers to handle.

> that point, one way or the other.
+1 here

---

From: "MH Michael Hammer \(5304\)" <[email-masked]>
Date: Mon, 19 Oct 2009 10:16:04 -0400

Comments are inline.

> Sent: Sunday, October 18, 2009 11:55 AM
> To: IETF DKIM WG

I think it would be useful to gather information but is not necessary
for rechartering. Information from large scale receivers would be the
most useful at this point as far as I'm concerned.

>  Is that an active consideration?

I can live with it either way (consider or don't consider). 

I believe that this is potentially useful but the "greek chorus" seemed
intent on drowning it out. The case that I was looking at was (A)
domains which send all their mail through a 3rd party but don't delegate
the domain/subdomain through DNS (for whatever reason). My understanding
is that this is fairly common situation, particularly for smaller
organizations. Jim demanded that if case (A) is to be considered then
case (B) must also be addressed and resolved at the same time. That is,
a large sophisticated domain such as Cisco should be able to, through
the same mechanism as (A) be able to delegate to multiple domains. There
is no logical reason for such a requirement other than to kill
discussion of (A).

John indicated that in order to have the discussion, the working
solution - along with proof that it works - must be placed on the table.
By that metric DKIM and pretty much any other standard would never have
come into existence.

So while I believe it would be useful, my ox isn't gored on this one and
few other people have stepped forward. Life is too short.

> that point, one way or the other.

4871+5672 or 4871bis, whichever is more appropriate from the IETF
process perspective. 

I say this even though I would be obliged to argue the opposite if I
used the standard that John wishes applied to ADSP. That is, there is
currently no substantive and overwhelming evidence that DKIM is
effective or useful.

> without going into lengthy discussion of details of the work.

I do wish to touch on the RFC 5617 (ADSP) discussion but only within the
context of the charter and the working group. My position is that the
working group should leave well enough alone for now and allow more time
for implementation. That is, do not make any changes in the status of
RFC5617 or how the working group deals with it for the time being.

Supporting discussion:

The fact that few have deployed ADSP so far should not necessarily be
taken as an indication of a lack of support. It appears that those who
shout the loudest against ADSP are those who have done little if
anything with regard to implementing or moving to implement.

We (AGI) fully intend to implement ADSP discardable (by way of first
implementing ALL) for the 5 major domains for which we have asserted
(here and in other venues) that all mail is DKIM signed and that mail
lacking signatures or having broken signatures could be discarded.
People should also remember that we made those assertions in late
2007/early 2008.

I'd like to point out that as a sender we were an early implementer of
DKIM/4871 signing and encountered some of the arrows that a pathfinder
sometimes finds in their back. A good example of this was the ".
stuffing" issue with regard to the body length hash.

With regard to ADSP there are very similar and real risks to
implementing, particularly with a discardable assertion. For example, I
am aware of one large mail system vendor which incorrectly adds a mime
type header AFTER DKIM signing. I can understand their intent as RFC
1521 (and subsequent RFCs) say:

"Default RFC 822 messages without a MIME Content-Type header are taken
   by this protocol to be plain text in the US-ASCII character set,
   which can be explicitly specified as:

     Content-type: text/plain; charset=us-ascii

   This default is assumed if no Content-Type header field is
specified."

Assuming the default and adding the default type header - especially
after signing a message - are two different things.

This issue was pointed out to the vendor quite some time ago but has not
been addressed. Anyone using the product as an outbound border mail
system (injecting mail from other systems) runs a risk of a broken
signature.

AGI was able to be more aggressive with DKIM implementation and
discardable assertions in the absence of a solidified ADSP (or SSP)
standard precisely because we could make the discardable assertions to a
smaller group with the ability to get feedback from that smaller group
of receivers.

As far as I know there are only 3 substantive independent (3rd party)
feedback loop efforts for authenticated mail information, two of which
appear to have stalled and the third which provides limited information.
I am also aware of several IDs for authentication FBLs.

It is this type of information that will enable more senders to
confidently implement ADSP. 

I have in the past been able to get some data slices from various
receivers with regard to authenticated mail. Not being able to get this
kind of feedback is an impediment to implementation all the way around
with regard to understanding "false positives".

At the risk of inciting some by mentioning SPF, I have been seeing very
interesting (positive) results as a sender in terms of the combined
impact of SPF+DKIM with regard to phishing attacks against our brands.
Unfortunately - in a weird sense - we have been successful enough in
reducing these attacks that the corpus of phishing attack submissions
(against our brands) for evaluation is getting too small to be a
meaningful sample going forward. 

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 19 Oct 2009 09:58:55 -0700

> [email-masked]] On Behalf Of John Levine
> Sent: Sunday, October 18, 2009 1:31 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] How about that DKIM charter update proposal
> 

How about "Experimental"?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 19 Oct 2009 10:07:58 -0700

> [email-masked]] On Behalf Of Daniel Black
> Sent: Sunday, October 18, 2009 6:00 PM

I'd be fine with doing that through this WG, although we have chosen on several occasions not to take up that draft as a WG item.  Instead, it's now in the proposed charter for the ARF WG.

I just don't want it to get stuck between the two.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 19 Oct 2009 13:36:59 -0400

> How about "Experimental"?

I haven't seen something go from Proposed Standard to Experimental
without being changed significantly along the way, and that would seem
quite weird to me.  Though I suppose it's possible.  Anyway, my
suggested text change (in the other thread) should cover that
possibility as well.

Barry, as chair

---

From: Steve Atkins <[email-masked]>
Date: Mon, 19 Oct 2009 10:42:25 -0700

On Oct 19, 2009, at 10:07 AM, Murray S. Kucherawy wrote:
> I'd be fine with doing that through this WG, although we have chosen  
> on several occasions not to take up that draft as a WG item.   
> Instead, it's now in the proposed charter for the ARF WG.

It's a DKIM thing. If it's going to be done, this group is the group  
to do it.

Backdooring it through another group is, at best, not going to be as  
effective I don't think.

Cheers,
   Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 19 Oct 2009 10:45:12 -0700

> [email-masked]] On Behalf Of Steve Atkins
> Sent: Monday, October 19, 2009 10:42 AM
> To: IETF DKIM WG

I think it has non-trivial relevance to both groups, and I don't consider doing it through ARF a sneaky move of any sort.

Since the WG has turned it down a few times now, are you suggesting it should be an individual submission?

---

From: Barry Leiba <[email-masked]>
Date: Mon, 19 Oct 2009 13:49:35 -0400

Re: http://tools.ietf.org/html/draft-kucherawy-dkim-reporting

> Backdooring it through another group is, at best, not going to be as

It's not a question of a "back door".  This WG decided some time ago
that it was a good idea, but out of scope.  As far as I can tell, that
hasn't changed, so it's still out of scope.

In any case, once it's a Proposed Standard, no one will care what
working group sent it through.

Barry, as chair

---

From: Steve Atkins <[email-masked]>
Date: Mon, 19 Oct 2009 10:51:48 -0700

> working group sent it through.

Yup.

But it's going to get better input from this group of people rather than
the ARF group, so whether it's sent through the ARF group, this
group or as an individual submission it'll benefit from input from
the people in this group.

Cheers,
   Steve

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 19 Oct 2009 10:59:42 -0700

> Backdooring it through another group is, at best, not going to be as  

Adding to the responses already posted:  It legitimately touches two possible 
working groups, so there's nothing wrong with its being pursued in the "other" one.

I could pretty easily argue that the dominant issue in this bit of work is the 
reporting mechanism, not the peculiarities of the DKIM info being reported and 
that, therefore, it's actually better in the ARF wg.    Yes, the activity needs 
DKIM expertise, but I'm pretty sure they'll have that covered, Murray and most 
of its other participants experience profound amnesia.

d/
-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 19 Oct 2009 14:59:26 -0400

>How about "Experimental"?
Why is it more experimental now than when it was published?

>From the beginning, I have not had the impression that the policy piece of 
the charter has not been taken very seriously.  Publishing All/Discardable 
does take some significant effort to make sure all of an entities MTAs are 
reliably signing.  I think it's way premature to have an opinion about if 
it will get used or not.

Scott K

---

From: SM <[email-masked]>
Date: Mon, 19 Oct 2009 17:28:08 -0700

Hi Barry,
>re-word that bullet to say "4871 + 5672".

Thanks, that clarifies the goal for DKIM-base.

>working group *consider* DS for ADSP?

I am not objecting to the Working Group considering DS for ADSP or to 
any of the text in the charter update.

Regards,
-sm

---

From: Jim Fenton <[email-masked]>
Date: Fri, 23 Oct 2009 16:17:31 -0700

> that point, one way or the other.

I'm generally in this latter camp.  The six-month timer might be useful
for some protocols, but the huge installed base and mission-critical
nature of email causes everything to move more slowly from a deployment
standpoint.

It's fairly easy to demonstrate interoperability of protocols, but
usefulness is much more difficult.  DKIM is an infrastructure protocol,
designed to provide a basis for other mechanisms, such as domain-based
reputation, to operate.  Those other mechanisms are as yet nascent; how
does one judge usefulness at this point?

If this working group does continue, I'd suggest that updates to the
service overview (RFC 5585) and deployment/operations document also be
on the table.  Those are the most appropriate places for the results of
operational experience to be described.

To summarize, I support waiting at least a year, perhaps more, before
progressing the WG specifications.  Whether that means that the WG shuts
down and restarts or just goes dormant is a question for the IETF
process wizards.

-Jim

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 23 Oct 2009 16:54:52 -0700

> does one judge usefulness at this point?

Jim,

This appears to be imposing criteria that go considerably beyond the IETF's 
requirements for Draft.

 From the standpoing of IESG process, how is this legitimate?

d/
-- 

   Dave Crocker

---

From: Franck Martin <[email-masked]>
Date: Sat, 24 Oct 2009 12:06:04 +1200 (FJT)

> for chartering at this stage.  Agreement or disagreement with that

Not sure about gathering data, but I don't want the group to loose track of the end goal of all these tools, which is to help fight spam/abuse. I know this is not the direct goal of DKIM, we had this discussion ;)

> not?

I think guidance for mailing lists is needed. Postmasters will just implement blindly tools like spamassassin and others.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 23 Oct 2009 17:08:45 -0700

Jim Fenton wrote:
> Good question.  I wasn't proposing that we judge usefulness at all; I
> was responding to suggestions from others that measuring usefulness be
> included in the charter.

Well, I can certainly understand producing documents that discuss efficacy (and 
maybe even how to achieve it) but I don't understand refraining from moving 
specs to Draft.

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Fri, 23 Oct 2009 17:00:52 -0700

Dave CROCKER wrote:
> This appears to be imposing criteria that go considerably beyond the
> IETF's requirements for Draft.
>

-Jim

---

From: Michael Thomas <[email-masked]>
Date: Fri, 23 Oct 2009 17:21:32 -0700

> maybe even how to achieve it) but I don't understand refraining from moving

First, do no harm.

Mike

---

From: hector <[email-masked]>
Date: Fri, 23 Oct 2009 21:51:42 -0400

+1.

--
HKS

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 23 Oct 2009 22:01:29 -0400

>This appears to be imposing criteria that go considerably beyond the 
IETF's 
> From the standpoing of IESG process, how is this legitimate?

So is it your position that a protocol must be advanced if it meets a 
minimal set of criteria even in the face of engineering judgement that the 
protocol is not yet sufficiently deployed to have a reliable understanding 
of the adequacy of the current design?

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Sat, 24 Oct 2009 18:13:41 -0400

> of the adequacy of the current design?

As I see it, the reasons to go to DS would be

Y1. to progress a fairly stable standard along a defined track, and
Y2. to review it and perhaps clean it up a little along the way, and
Y3. to get broader deployment as a result of higher maturity.

As to Y3, there's evidence, as Murray has pointed out and as many of
the rest of us are aware, that most deployment comes from publication
as PS, and from other sorts of publicity... and DS probably doesn't
create the swell of deployment that we might like.  Still, as long as
the IETF considers the three-stage standards track to have value, I
think there's some value in working within it.

The reasons not to go to DS would be

N1. to avoid wasting our time on nominal advancement that has little
or no real value, or
N2. to avoid wasting any more time working on something that's not
very useful, or
N3. in recognition that it's not stable, and that, while it certainly
meets stated criteria for DS now, we think we're likely to change it
significantly after more experience with it.

My opinion is that N1 is arguable, but that N2 and N3 are not the
case, and that we shouldn't resist advancing DKIM base to DS for
reasons N2 and N3.  My opinion is also that, while N1 might be true,
the fact the IETF considers it worthwhile overrides that.

And note that I'm only advocating advancement for DKIM base at this
point; I think we DO need more experience with ADSP before we have any
clue whether it's stable (or useful).

Barry, as participant

---

From: Barry Leiba <[email-masked]>
Date: Sat, 24 Oct 2009 18:19:17 -0400

> does one judge usefulness at this point?

Indeed; I agree.  But, as I've said before, I think this is relevant
for advancement from DS to (full) Standard, and not so much from PS to
DS (unless we're really quite sure that it's NOT useful, and so should
not waste any more time with it).

> operational experience to be described.

Agreed.  Unless there's objection to this, I'll add a work item about
ongoing review and appropriate updating of those informational
documents.

> down and restarts or just goes dormant is a question for the IETF

I think "dormant" will work, if this is the route we decide to take.
But I think we won't be completely dormant, anyway, if we're gathering
data and reviewing the informational documents, and perhaps updating
them.

Barry, as chair

---

From: hector <[email-masked]>
Date: Sat, 24 Oct 2009 19:11:26 -0400

> data and reviewing the informational documents, and perhaps updating

I think it would be nice if we had (if already done, reestablish) a 
foundation for what exactly we are looking for during this "dormant" 
period.

   - Personal Community/Network (AKA Local Sites) Statistics?
   - Growth of Incoming Signed Messages
       - Percentage of Spam
       - Percentage of 1st, 3rd party
       - Percentage of failed hashing from EyeBalled Good guys.
   - Growth of ADSP domains
   - Growth of Open Standard Reputations Systems
   - Growth of Open API Commercial Reputations Systems
   - Exclusivity Analysis (What If)
       - What if your other current filters (i.e. SPF)
         was not around?
       - What if Remailers honored ADSP?
   - FOG (Flash Of Genius) protocol fitting solutions

etc, some form of foundation for producing a formal report after 1+ 
years or at some group agreed date.

One other data point, in a form of a open question:

   - If ADSP is not recommended for 3rd party signers, are
     3rd party signers also exempt from performing
     reputations checks?

This would probably fall under the percentage of spam data point

Maybe we don't know what these questions are?

---

From: Barry Leiba <[email-masked]>
Date: Sat, 24 Oct 2009 19:42:59 -0400

> foundation for what exactly we are looking for during this "dormant"

Agreed.

> years or at some group agreed date.

That sounds like a good set to start discussion with.  And, yes, I
like the idea of having a report on the work-item list.

Barry, as participant

---

From: Franck Martin <[email-masked]>
Date: Sat, 24 Oct 2009 16:17:35 -0700

> clue whether it's stable (or useful).

+1

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 24 Oct 2009 23:19:31 -0400

>clue whether it's stable (or useful).

I think it's a reasonable set of criteria.

Where I disagree is that we have a sufficient basis to declare it stable.

It has not been very long at all since we rushed a new RFC out to clarify 
things.  What's the basis for confidence that that was it?

It is my expectation that if there are any significant warts left in the 
basic protocol it will become apparent in large scale deployments where 
DKIM signature data is being used as an input to other processes (like ADSP 
or private reputation services).  I don't see a lot of evidence that such 
deployments are at all common yet.  If other participants have significant 
experience with these, I'd appreciate hearing about it.

Scott K

---

From: SM <[email-masked]>
Date: Sat, 24 Oct 2009 23:40:16 -0700

>Where I disagree is that we have a sufficient basis to declare it stable.

The interoperability issues have been addressed in the implementation 
I use.  There are still some quirks which are MTA related.

>things.  What's the basis for confidence that that was it?

If you do DS and you want changes later, I'll say that a recycle is 
needed.  I am not arguing for or against DS.

>or private reputation services).  I don't see a lot of evidence that such

It's wide deployment and not large scale deployment that identify 
warts.  I do not have to write about assessment as that is out of 
scope. :-)  The choice is about where to direct the effort to move 
DKIM forward.

DS is a good time to document warts.  DS would mean that this WG is stable. :-)

>progressing the WG specifications.  Whether that means that the WG shuts

If it takes that long for the WG to be stable, so be it.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 25 Oct 2009 04:14:14 -0700

Barry Leiba wrote:
> DS 

Right.  The rules for Draft require that we demonstrate interoperability by at 
least two, independent implementations.  That's all.

We need to be careful that we not invent our own standards process, no matter 
how much better we might think it.

As you note, efficacy (or more likely 'popularity') is the real key to Full 
Standard, but it's not relevant to Draft Standard.

+1

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Sun, 25 Oct 2009 12:37:57 -0700

> I use.  There are still some quirks which are MTA related.

I think that Scott is talking about a much higher level of "interoperability".
Clearly the rfc we have now is highly interoperable at the nuts and bolts
software level. What I think that Scott is getting at is whether we have
an "stable" spec that meets the use cases that we actually intended
DKIM to work for (eg, for all the enterprise, and other uses).

I think that Scott's use of "stable" might be a bit idiosyncratic,
but his concern is valid. I guess I mostly agree: I'm not really
sure what the rush is to get to DS. It's almost like people are
sorry to see this insufferable list go dormant along with the
working group :)

Mike

---

From: hector <[email-masked]>
Date: Mon, 26 Oct 2009 07:29:39 -0400

> software level. 

[My opinions here is towards this statement and not the person who 
made it.]

If it is meant that if ADSP was followed, then I would agree, we are 
closer to closing the software based loopholes.  OTOH, if ADSP is 
ignored as it never existed, then DKIM-BASE is pretty straight forward.

But not when we integrating the RFcs, I have a hard time agreeing with 
this. IMO, we have pretty clear conflictive technical implementation 
guidelines, otherwise we would not be in this confused state that 
seems to leave one with a "don't know what to do, wait and see" status 
asking us to wait yet another 1+ years beyond the 3-4 already done.

For an integrated mail system, the SMTP developer and LIST SERVER 
developer are in conflict in regards to the forwarding issue.    Even 
under the same brand of software, there is an design issue with the 
SMTP software supporting ADSP being ignored by the List Server 
software.  Its not 'integrated software' logical.

On the domain side, domains have no clear solutions for what policy to 
use. We don't have enough representation of all markets here. Discard 
is pretty clear for one group regardless of how small another group 
would thing that is.  "all" is not very clear for any group, yet one 
list group is desperately trying to make it viable.  And even those 
domains who wish to use "discard" are quickly finding out they will 
not be protected against legacy spoofs and anonymous signers by the 
purported "Good Guy" resigner market we have no general and wide 
adoption method to find that out.

Even when we remove POLICY and replace it with reputation, we still 
have the open question if a forwarder/remailer SHOULD|MUST follow 
domain reputation public query information.   The same SMTP/LIST 
SERVER conflict still exist here even with REPUTATION models.

So there is no straight forward protocol and solid foundation other 
than DKIM-BASE. All we have is a pretty clear mechanism for signing 
machines but its value is questionable with no protected layer.  IMV, 
we are in a confused or better stated, COMA state, looking or waiting 
for some mystical reawaken hope to occur or kick in.

--
Hector Santos

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 26 Oct 2009 10:52:08 -0700

> Sent: Wednesday, September 30, 2009 9:01 AM
> To: IETF DKIM WG
> Subject: [ietf-dkim] DKIM charter update proposal
> 

I like it; comments below.

>     draft-ietf-dkim-deployment, in its final stages)

Although I'm not going to oppose it without, I believe there's room for improvement here.  I don't have specific text yet, but I'd be happy to collaborate to come up with some.  Specifically, it's clear to me, from WG conversations and hallway track at MAAWG and elsewhere, that more guidance is needed in terms of how DKIM results get interpreted in certain contexts such as mailing lists and other third-party signing.  Even if the output of that process is "DKIM doesn't tell you anything here", this needs to be more explicit.

If we don't want to change this document so late in its evolution, that's fine; I'd be happy if it came out as a BCP document later, either from the IETF or through a body like MAAWG.

I'd invite the people that have been involved in those conversations to state specifically what areas draft-ietf-dkim-deployment could cover to close these gaps.

>   * Advance the base DKIM protocol (RFC 4871) to Draft Standard.

I support this as a goal.  I believe DKIM itself is ready to advance as-is, plus or minus the pending errata.  I also completely agree that ADSP is far from ready for such advancement.

---

From: John Levine <[email-masked]>
Date: 26 Oct 2009 18:35:35 -0000

It occurs to me that there are a bunch of technical clarifications to
the spec that (I think) Tony wrote up after the connectathon a year or
so ago.  If we want to move to DS, would it be worth a pass over 4871
to incorporate them?  I don't think there have been any more recently,
so this would probably count as making it more mature.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 26 Oct 2009 13:40:18 -0700

Murray S. Kucherawy wrote:
>     Specifically, it's clear to me, from WG
> conversations and hallway track at MAAWG and elsewhere, that more guidance is
> needed in terms of how DKIM results get interpreted in certain contexts such
> as mailing lists and other third-party signing.  Even if the output of that
> process is "DKIM doesn't tell you anything here", this needs to be more
> explicit.
> 
> If we don't want to change this document so late in its evolution, that's
> fine; I'd be happy if it came out as a BCP document later, either from the
> IETF or through a body like MAAWG.

Separate BCP on details on usage:  +1

d/
-- 

   Dave Crocker

---

From: hector <[email-masked]>
Date: Mon, 26 Oct 2009 20:15:35 -0400

> I'd invite the people that have been involved in those conversations to state specifically what areas draft-ietf-dkim-deployment could cover to close these gaps.

I seek one thing:

Codify the semantics regarding ADSP implementation vs Forwarder DKIM 
implementation.

If thats a problem, then ADSP needs to be pulled.  We don't need 
evidence to show there is a problem but only engineering inference 
that there will be a problem if there is any growth in either part 
with a clear collision.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 Oct 2009 07:02:10 +0100

> Separate BCP on details on usage:  +1

+1, but a forward reference of some sort, like "a separate work is 
planned on this topic" wouldn't be out of order.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 27 Oct 2009 13:51:23 -0400

>> Murray S. Kucherawy wrote:
  [ . . . ]
>> Separate BCP on details on usage:  +1
  [ . . . ]
> planned on this topic" wouldn't be out of order.

+1 to both the BCP and the forward reference.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Oct 2009 14:25:36 -0700

Agreed.

-Doug