Subject: [ietf-dkim] Handling the errata after the consensus call

From: DKIM Chair <[email-masked]>
Date: Fri, 06 Mar 2009 09:11:04 -0500

Pasi, Stephen, and I had a conference call to sort out where we can go with the 
errata, the idea of a 4871-bis, and so on.  This summarizes what we think, where 
we'd like the working group to go, and what the working group needs to decide.

The first point is that while 2/3 of the working group prefer the stronger and 
more extensive clarifications in the "Dave draft" (realizing that he's the 
editor, and that others were involved in drafting this; it's a convenient way to 
refer to it) to the more minimal, more "errata-type" update of the "modified 
Eliot draft", Pasi thinks the discussion shows neither text is probably 
appropriate as an RFC Editor errata (that skips the usual IETF consensus 
process).  Dave's changes, in particular, introduce new terminology and make 
enough changes in how the affected areas of the spec are worded that Pasi 
believes -- and thinks the IESG as a whole will agree -- that it needs to go 
through the full process of getting community input and rough IETF consensus.

He is sure, though, that the IESG will be happy to handle this expeditiously, and 
so we recommend that Dave's draft be processed as an RFC that updates RFC 4871. 
This will mean that we have come to agreement on the text, but there are less 
constraints about the length, and the outcome can include text that some folks 
would interpret as changes to RFC 4871.  Since Dave's draft has a clear majority 
behind it, we'd like those who disagree with some parts of it to help with making 
it more acceptable to everyone -- or most of us, anyway -- so we can get it out 
as a 4871 update.

Next is the question of how to put it out and what to do with the other errata, 
which are non-controversial.  We could handle them as normal errata, put Dave's 
draft out as an update that resolves that item, and then start work on whatever 
4871-bis would be.  We're concerned, though, with the lack of visibility of 
errata, and we note that some of these errata are important for people to see 
when they're implementing 4871.  That might make it worth taking one of these two 
paths (and this is what we'd like the working group to decide):

1. Include the other errata into Dave's draft, leave the whole thing as "old text 
/ new text" format, and put it out as an RFC that updates 4871.  There would be 
no rev of 4871, and implementors would need to use both documents.  Work on 
4871-bis from there.

2. Include the other errata and Dave's draft into a 4871-bis, which would 
obsolete 4871 and make sure that implementors get the right version.  Nothing 
would go out as "old / new"; the merged document would be a rev of 4871.  Work on 
4871-ter from there.

Then there's the question of where ADSP stands, and whether it can proceed as is, 
or needs to be changed in light of the "errata".  Pasi may have some comments on 
this, and I know the working group will.  We've been holding ADSP up for a while, 
and we need to release it and move it forward.

We would like to get the decisions of how to proceed sorted out before the San 
Francisco meeting, and to use the meeting time in San Francisco to <strike>shout 
at each other</strike> come to the agreements and compromises that we need to get 
this done.  We'd like to be able to confirm these decisions on the mailing list 
and move ahead shortly after the San Francisco meeting.

Responses to this message should stay in this thread, until we decide to split 
sub-threads off.

Barry

--
Barry Leiba, DKIM working group chair  ([email-masked])
http://internetmessagingtechnology.org/

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

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 06 Mar 2009 07:19:13 -0800

> through the full process of getting community input and rough IETF consensus.

Please clarify:

1.  While our area director might have concerns about processing these changes 
as an errata, there is the separate question of rough consensus about these 
changes.   Are you saying that a vote of 2/3 is not sufficient to declare 
working group approval?  If so, what is?

     Even if the wg is forced to publish the change through an RFC rather than 
an Errata, it does not make sense to force the wg to cover this ground again, 
given its rough consensus on the topic.

2.  The RFC Editor publishes rules for Errata.  So does the IESG.  You indicate 
that Pasi is refusing to process draft-ietf-dkim-rfc4871-errata-02 for two 
reasons:  It introduces new terminology and it makes too many changes.  Neither 
of these is included (or excluded) from the RFC Editor or IESG Errata rules. 
Pasi should explain his basis for adding these constraints.

d/
-- 

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

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 06 Mar 2009 07:44:43 -0800

[email-masked] wrote:
> Dave Crocker wrote:
> 
>> 2.  The RFC Editor publishes rules for Errata.  So does the IESG.
>> You indicate that Pasi is refusing to process
>> draft-ietf-dkim-rfc4871-errata-02 for two reasons: It introduces new
>> terminology and it makes too many changes.  Neither of these is
>> included (or excluded) from the RFC Editor or IESG Errata rules.
> I do not believe the errata meets this criteria, agreed by the IESG
> for IETF Stream RFCs:
> 
> http://www.ietf.org/IESG/STATEMENTS/iesg-statement-07-30-2008.txt:

Pasi,

That document contains specifics.  I am asking you to cite the specifics that 
cover the reasons given for your refusal to process this as an Errata.

To make this simpler:

    Let's say you refused to process the Errata because the Errata contained the 
word "the".  And when asked to explain your reason, you said:

    "I do not believe the errata meets this criteria, agreed by the IESG
    for IETF Stream RFCs:

    http://www.ietf.org/IESG/STATEMENTS/iesg-statement-07-30-2008.txt"

    No one would find that an adequate explanation.

Yet this is exactly what you have just done, since I do not see any way to 
interpret the text of the IESG statement as covering the conditions Barry cited.

You obviously do see a way and I am asking you to explain it, by providing the 
details.

>> 7. Changes that modify the working of a protocol to something that
>> might be different from the intended consensus when the document
>> was approved should be either Hold for Document Update or
>> Rejected. Deciding between these two depends on judgment.
>> Changes that are clearly modifications to the intended consensus,
>> or involve large textual changes, should be Rejected. In unclear
>> situations, small changes can be Hold for Document Update.
> 
> We have already exchanged many off-list emails about this topic, and 
> I get the impression that you disagree both with the IESG statement 
> itself and my judgement call. 

I haven't commented on the adequacy of the statement.

In fact I keep trying to reconcile the reasons you cite with the content of that 
statement.  That's the failure that /I/ keep citing and that's why I'm asking 
you to be specific, rather than just invoking the IESG statement in its entirety.

d/
-- 

   Dave Crocker

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 6 Mar 2009 16:28:40 +0100

We have already exchanged many off-list emails about this topic, and 
I get the impression that you disagree both with the IESG statement 
itself and my judgement call. If that's an accurate impression,
let's just agree that we disagree -- this is not a topic for
debate on the DKIM WG list.

Best regards,
Pasi

---

From: Michael Thomas <[email-masked]>
Date: Fri, 06 Mar 2009 17:34:38 -0800

I frankly don't see the point of a -bis document, and so long as the errata
shows up reasonably close to the top in a google search, I think that the
dev front should be fine. Invoking another round of IETF process at this
point sends exactly the wrong message: that DKIM is not stable. DKIM
has been remarkable in its stability and interoperability, so sending that
message would be a real shame.

       Mike, dev-by-google-consensus is the new "rough consensus
         and running code"

---

From: Tony Hansen <[email-masked]>
Date: Fri, 06 Mar 2009 23:35:58 -0500

On the contrary, moving DKIM **forward in the standards process** sends
exactly the proper message: that DKIM *is* stable enough for us to
advance its standards level.

Remember, advancing along the standards track has serious constraints on
the types of changes permitted to the spec. It is *not* an indicator of
instability, but instead is an indicator of its stability.

If we were to come out with a 4871bis *without* also attempting to move
it forward on the standards track, then I agree that we'd be sending a
bad message to the industry. But I don't think doing a bis without
concurrent advancement is being seriously considered -- I'm certainly
advocating moving it to Draft Standard.

	Tony Hansen
	[email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Sat, 7 Mar 2009 00:55:19 -0500

> advocating moving it to Draft Standard.

In other words, Tony, you're advocating option 1: put the "errata" out
as an RFC that only makes updates, and reserve the 4871 replacement
for an attempt to go to Draft Standard.

Option 2 is the one you aren't considering seriously.

Barry

---

From: Michael Thomas <[email-masked]>
Date: Fri, 06 Mar 2009 22:41:14 -0800

> Option 2 is the one you aren't considering seriously.
I just reread your note and I'm completely not getting how it supposedly
leads to draft standard one way or the other. FWIW, multiple normative
documents usually suck from a dev standpoint.

Is draft  standard even on the table? I for one am pretty uncomfortable
with a bunch of new normative changes to the sematics of DKIM with
absolutely no interoperability being rolled into a draft standard rev. I
thought that draft standard was mainly about clarification and removing
unused stuff.

          Mike

---

From: Hector Santos <[email-masked]>
Date: Sat, 07 Mar 2009 01:38:55 -0500

> would go out as "old / new"; the merged document would be a rev of 4871.  Work on 

Personally, I am not all familiar with procedure, but from a marketing 
standpoint, I would like to suggest that if Dave's errata is going go 
forward, that an abstract be updated to include an executive summary 
of what is the key/fundamental changes and if possible, the effects 
and repercussions. i.e. don't force people to read deep into the 
errata to find out if any of this matters and/or applies to them.

> and we need to release it and move it forward.

+1.  This is our own holdup on moving forward with DKIM.

I just to make a final statement here to reiterate I think the #1 
benefit is exclusive signings (where I believe the highest payoff will 
be with private domains), and ADSP will offer some assistance in this 
area.  ADSP will allow us to provide the technical selling and 
incentive, a reason to explore DKIM to our customers.

Thanks

--
Hector Santos
http://www.santronics.com

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Sat, 7 Mar 2009 12:46:17 +0530

I am for #2 personally speaking.  The errata discussion has become way
too complex and it would be extremely confusing for operational users
of dkim to have to switch back and forth between rfc and errata.

This, as long as 4871bis is a "short" step before draft standard - and
the draft standard doesnt diverge significantly from 4871bis.

thanks
--srs

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Sat, 7 Mar 2009 12:49:25 +0530

> +1.  This is our own holdup on moving forward with DKIM.

Speaking of ADSP, I am -1 on its continuation.  I dont see any
significant receiver (ISP) adoption of ADSP, to be frank.

---

From: Hector Santos <[email-masked]>
Date: Sat, 07 Mar 2009 04:58:17 -0500

> significant receiver (ISP) adoption of ADSP, to be frank.

That might be because it wasn't stable. SSP was cut off and it was 
already part of API software. If you used the API, it include default 
support for Policy Lookups.  So the ADSP coup d'etat did not help. 
Lots of work was lost.  Pissed off people, to be frank. Some even feel 
ADSP was really a poison pill. To badly paraphrase Rush Limbaugh, some 
really wanted 'SSP/ADSP to fail' (not progress to draft standard), so 
for some there is still pessimistic feelings about it because of what 
happen.

Fortunately, there is still some redeeming value remaining with ADSP, 
at least this is the reason I am still hanging around, and we should 
be well aware the "significant receiver (ISP)" group clearly do not 
represent the entire electronic mail market place.  There are millions 
of private and HV (high value) domains,  certain magnitude more than 
all the ISPs combined. Most private enterprises will benefit with 
exclusive DKIM signing policy protection. Private Vendor/User 1 to 1 
communications with a high benefit and payoff is desirable. They is no 
expectation for public, promiscuous, open usage. No Mailing list.  If 
eBay advertises and screams to the world "Hey, we will always sign our 
emails - always!", are they doing this so that others ignore that 
expectation?

Most of our customers are private enterprises, many offer small ISP 
operations (they serve their own private clients).  In our customer 
surveys and discussions, a DKIM+POLICY component has long been 
established as the preferred feature to add.  It is also easier to 
promote, market and sell DKIM+POLICY, than without POLICY.  It will 
help justify the cost of implementation.

So to be frank, with respect and sincerity, I really hope what you say 
is not true and ADSP should be considered as a natural part of DKIM 
implementations, whether they need it or not.  In other words, even if 
you don't implement DKIM, ADSP separately can still be used.  See the 
expired I-D http://tools.ietf.org/html/draft-santos-dkim-rcvd-00 
proposing how a site can use partial support as a migration path.

-- 
Sincerely

Hector Santos

---

From: Tony Hansen <[email-masked]>
Date: Sat, 07 Mar 2009 16:04:08 -0500

> significant receiver (ISP) adoption of ADSP, to be frank.

Given the state of flux for ADSP, there was no way that our ISP services
would even consider deploying it until after it was published. Now that
it's closer, our ISP services certainly have plans for deployment.

	Tony Hansen
	[email-masked]

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Sun, 8 Mar 2009 06:21:53 +0530

> it's closer, our ISP services certainly have plans for deployment.

Most of ADSP has been, so far, an attempt to introduce (sometimes
ridiculously) fine grained reputation scoring for vendors, and clients
of vendors.

Now, given new wording about d= primacy and i= opaqueness e&oe out of
band discussion ..

--srs
-- 
Suresh Ramasubramanian ([email-masked])
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Sat, 07 Mar 2009 20:57:53 -0500

> it's closer, our ISP services certainly have plans for deployment.

Thats good news Tony.

Question. Can you speak of which ISP services?

   - the general usage of the ISP's public domain for users, or
   - vendor/user communications.

For example, my home DSL account is with AT&T. From cingular days, I 
still have a legacy email bellsouth.net user domain account. I am not 
sure if AT&T issues att.net accounts to home tiers.

I think it will help to distinguish that there two basic forms of 
possible ISP adoption:

1) DKIM w/o ADSP support general ISP user domain hosting,
    e.g.;  mail from the ISP "open ended" user domain bellsouth.net.
    by open ended I mean, I can use it from anywhere and so can
    others.

2) DKIM w/ ADSP support for private Vendor (ISP/ESP)/USER
    communications. e.g.; ATT "Customer Care" emailing from
    amcustomercare.att-mail.com

The latter (#2) is what I believe we need to leverage and make sure it 
is the high benefit possible for DKIM w/ ADSP.

With #1, that has been the issue for the past 3-4 years wrt how SSP 
will of work here. ADSP is a result of the lack of SSP consensus or 
rather too complex to consider all the 3rd party issues.

In my view, we need to make very clear for adopters to get the good 
grasp of the key difference in this regard - where/how POLICY will 
play a role for ISP different type of communications or services.

-- 
Sincerely

Hector Santos

---

From: Hector Santos <[email-masked]>
Date: Sat, 07 Mar 2009 21:17:24 -0500

> ridiculously) fine grained reputation scoring for vendors, and clients

Can you explain where in the specification this is stated?

I really hope we can finally finish a DKIM Policy protocol and this 
time by keeping the unstable, lack of a standard reputations ideas out 
of scope as we try to finish up ADSP and get it to draft standard.

I hope the WG chairs will help keep the WG focus of the prize - an 
IETF standard policy layer/protocol for DKIM and not allow out of 
scope reputation ideas to ruin it once again as it did for SSP the 
past years.

I am not suggesting reputation should not be part of the a deployment 
plan. No doubt it will useful to handle the indeterminate conditions. 
  But it has to be viewed as independent consideration if we are going 
to get ADSP finished.

We need a standard approach for DKIM and POLICY().  Reputation() will 
be different with many systems. It can be local and/or remote, but I 
wouldn't pin our hopes nor would it be desirable to have a *single* 
centralized certification, reputation, domain assurance vendor 
controlling the market.

I hope we can keep this motivation out of scope as we move ADSP forward.

-- 
Sincerely

Hector Santos

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Sun, 8 Mar 2009 07:49:27 +0530

> Can you explain where in the specification this is stated?

Not the spec.  The majority of the use cases I have seen proposed for
it, on the other hand ..

> I hope the WG chairs will help keep the WG focus of the prize - an IETF
> standard policy layer/protocol for DKIM and not allow out of scope
> reputation ideas to ruin it once again as it did for SSP the past years.

If you call them out of scope where that's going to be their single
largest intended application .. well, you are technically right I
guess.  Practically ... ?  That's another question.

--srs

---

From: Douglas Otis <[email-masked]>
Date: Sat, 7 Mar 2009 20:22:43 -0800

On Mar 7, 2009, at 6:19 PM, Suresh Ramasubramanian wrote:

>>> ridiculously) fine grained reputation scoring for vendors, and  
>>> clients of vendors.
>>
> Not the spec.  The majority of the use cases I have seen proposed  
> for it, on the other hand ..

ADSP's current definition of Author Signature is not compatible with  
what might become typical DKIM signing practices utilizing opaque i=  
values.  Requiring two signatures is a needless waste of resources.

DKIM i= values can help mitigate abuse when the number of problematic  
i= values is limited.  A limited number of problematic i= values  
should not be seen as ridiculous.  There is already a fair amount of  
DKIM replay abuse, where i= values could play a meaningful role.  An  
alternative strategy might attempt to limit DKIM domains to specific  
SMTP clients, but that would make the email less robust.

> guess.  Practically ... ?  That's another question.

The challenge is to discuss these issues, especially when everyone has  
a different opinion about what might be a practical mitigation strategy.

-Doug

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Sun, 8 Mar 2009 11:28:40 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Suresh Ramasubramanian
> Sent: Saturday, March 07, 2009 7:52 PM
> To: Tony Hansen
> Cc: IETF-DKIM
> Subject: Re: [ietf-dkim] Handling the errata after the consensus call
> 

Suresh, notwithstanding what some vendors might wish in terms of
reputation, the case for ADSP is and always has been to leverage DKIM to
be able to say "this domain signs all mail" in one way or another.

Whether reputation is used in conjunction with this is a different
discussion. From an abused (by phishing) domain perspective, DKIM
signing of all mail + ADSP (being able to make the assertion that all
mail is signed for a particular domain or subdomain)is useful for both
the sender and the receiver. I am not going to claim that it is a magic
bullet. It addresses particular issues in a particular way.

Mike

---

From: Al Iverson <[email-masked]>
Date: Sun, 8 Mar 2009 12:00:00 -0500

> bullet. It addresses particular issues in a particular way.

+1

It has nothing to do with reputation or reputation granularity.

Regards,
Al Iverson

-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com   --   Chicago, IL, USA
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 8 Mar 2009 16:25:02 -0000

> reputation, the case for ADSP is and always has been to leverage
> DKIM to be able to say "this domain signs all mail" in one way or
> another.

You're both right.  The open issue in ADSP at this point is whether to
overload i= to attempt to add per-address reputation, or strip out the
cruft so it really does say this domain signs all mail.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 08 Mar 2009 10:35:47 -0700

> cruft so it really does say this domain signs all mail.

wouldn't that mean defining ADSP in terms of d=, rather than i=?

it would also remove the confusion about granularity.

d/

-- 

   Dave Crocker

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 9 Mar 2009 06:28:54 +0530

> be able to say "this domain signs all mail" in one way or another.

That seems like an overly complex, rube goldbergish way to indicate
it.  More like developing spf, with your sole reason being to publish
"v=spf1 -all" indicating that a domain never sends email.

And it is still not something I would trust without confirmation and
verification out of band (this, having noticed more than one wrong spf
declaration that if we'd bothered to check on in our mailserver, would
have resulted in lost mail)

Further, at least from my perspective, it is not something I would
bother to check for all but a few significant domains.

--srs

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Mar 2009 01:00:54 -0400

> bother to check for all but a few significant domains.

Suresh,

Opinions vary.

This would be your [local] policy, your implementation, your 
operation. You nor I can't speak for others, but I hope the goal here 
is to provide the standard protocol tools for vendors/implementators 
to provide to their customers and operators to allow them to decide.

Here's the irony:

      You just defined your own "POLICY" table - a list of significant
      domains to check.

So you have your own localized table for "ADSP" lookup considerations.

I would classify this as a non-anonymous operation.

Thats hasn't been the real problem IMO. The problem is the anonymous, 
the unsolicited, the other good/bad sites of the "significant" world 
that may not be part of some special white/black table.  If anonymous 
operations was not allowed, every sender was required to authenticate, 
then we probably won't be here today.  But that isn't realistic to 
have a close system across the board. Open SMTP is still valid for 
communications.

I would agree with you that valid signatures still require help in the 
area of positive reputations.  But IMO, failure detection provided 
with DKIM+POLICY is where you don't really need reputation.

Just consider reputation is already widely in practice in many forms. 
  Many believe that good signatures will not trump a bad rap and vice 
a versa, bad signatures will not trump a good rap.  So whats the rule 
here? Does reputation trump DKIM/POLICY?  Is it don't by weights? Or 
some does certified trusted service govern who is good or bad?

How many times does a ADSP domain have to tell a receiver that failed 
signatures or no signatures should be discarded per their ADSP?  1, 2, 
5, 10 times?  Why would a receiver continue to endure the overhead 
when the DOMAIN with a ADSP record is tell the receiver

      "Dude, do yourself a favor. Its not our mail.
       I suggest you get rid of it. No need to build up
       a score or pass the junk to users, and please do
       not bounce it to us!"

Reputation is still open-ended. No real rules to it other than the 
traditional scale/weight concepts.  No standard so unless you a 
promoting a single entity, a centralize service everyone can use (and 
must/should use to gain any real benefit if that is what you believe), 
at best, all we can do is define what is the "feed" to these 
futuristic services.

-- 
Sincerely

Hector Santos

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 9 Mar 2009 13:58:19 +0530

> So you have your own localized table for "ADSP" lookup considerations.

Like I said .. that's a rube goldberg mechanism.

thanks
srs

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 9 Mar 2009 10:17:30 -0400

Comments in-line

> From: Suresh Ramasubramanian [mailto:[email-masked]]
> Sent: Sunday, March 08, 2009 8:59 PM
> To: MH Michael Hammer (5304)
> Cc: IETF-DKIM
> On Sun, Mar 8, 2009 at 8:58 PM, MH Michael Hammer (5304)
<[email-masked]>
> wrote:
DKIM to
> "v=spf1 -all" indicating that a domain never sends email.

Please offer a better way of indicating that mail is always signed. 

I think your analogy to SPF is not quite correct. The SPF record itself
includes the ability to make a strong assertion (a record that ends with
-all but is not solely -all) as well as a means of indicating that one
does not send mail from a particular domain (publish only -all). The
base DKIM spec does not provide a way to specify one signs all email.

> have resulted in lost mail)

That is your choice as a receiver. I'm not sympathetic to senders that
publish incorrect or broken SPF records just as I'm not sympathetic to
senders who publish incorrect DKIM records. This is no different than
someone publishing incorrect DNS records.

It may be that you as a receiver choose to require some other
confirmation and verification before you act on what a domain publishes.
That is your prerogative. On the other hand, one of the reasons I am a
strong proponent for both SPF and DKIM (+ADSP) is that it provides a way
to scale beyond one to one out of band correspondence between sender and
receiver.

> bother to check for all but a few significant domains.

Again, different receivers will make different choices about what they
do. Isn't freedom of choice a grand thing?

Mike

---

From: Michael Adkins <[email-masked]>
Date: Mon, 09 Mar 2009 10:33:32 -0400

> some does certified trusted service govern who is good or bad?
Whether or not you should apply someone's policy declarations is more of
a function of their class than their reputation. You can't assume that
'significant' is the same thing as 'reputable'.

If I think social networks have a reasonable use case for policy
declaration, then it doesn't really matter how heavily one is abused
versus another. I'm going to apply both their policies regardless.

We'll never get anywhere if we keep dragging 'good' and 'bad' into it.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 9 Mar 2009 11:06:59 -0400

Stephen,

I'm not saying drop ADSP as I am really looking forward to being one of
the early publishers of ADSP records as a means of assisting receivers
in addressing abuse.

On the other hand, if Suresh has a better way of achieving the goal of
declaring one signs all email with DKIM, it is certainly worth a
discussion. 

If such a discussion is truly beyond the charter of IETF-DKIM then I
would recommend that Suresh post his proposal to ASRG. 

Mike

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Monday, March 09, 2009 10:49 AM
> Cc: Suresh Ramasubramanian; IETF-DKIM
> MH Michael Hammer (5304) wrote:
> Actually, please don't. We were chartered to do ADSP and we've
> (almost) done that. Unless someone's looking to recharter I don't
> see how this list is relevant for other ways to do what ADSP does
> or for ways to do something else, or for yet more discussion as
> to what ADSP does is wonderful/terrible.
> 
> Can we get back to the options mentioned in Barry's mail?
> 
> Thanks,
> Stephen.

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 9 Mar 2009 21:05:57 +0530

> base DKIM spec does not provide a way to specify one signs all email.

I'm happy to leave it at this stage -

> 6.3. Interpret results / apply local policy
> (for example, when communicating with a peer who, by prior agreement, agrees to only send signed messages)

And as for this ..

> someone publishing incorrect DNS records.

I have little or no sympathy for them. But broken spf records were
common enough, and then broken spf checking at various receiver sites
was even more common that we decided to remove our spf records in
2005.

If your sole goal in ADSP is "declare that domain x signs all mail"
then there could be a far simpler and more cut down version of ADSP
that'd fit the bill.  To wit - the "locked ADSP record" part.  And if
that's all that is required .. why then, I dont see why that part of
it cant be shoehorned into the base 4871 spec somehow - perhaps in
-bis as a newly defined tag.

> to scale beyond one to one out of band correspondence between sender and

Once it scales, given the complexity - and the heavy push for
reputation, it will be extensively gamed.

--srs

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Mar 2009 14:48:43 +0000

Thanks,
Stephen.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 09 Mar 2009 09:02:29 -0700

Suresh Ramasubramanian wrote:
> that'd fit the bill.  To wit - the "locked ADSP record" part.  

     I don't understand what this means.

> And if

the original IIM had bits of what is now ADSP in it. It was divided
and conquered mainly for processes reason. But in fact, they really
are two different pieces of software with pretty different goals. I really
don't see how merging them together into one document would change
either reality.

       Mike

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 9 Mar 2009 22:07:05 +0530

>    I don't understand what this means.

I was looking at an older draft-otis, Sorry.

The adsp draft on dkim.org calls this "bulk mailing domains with
discardable mail"

That's a special case.  And I think that's the one case Mike Hammer is
concerned about, rather than the rest of it.  It would be a valid
concern / need for me too - but I dont see how or why the rest of ADSP
has to be supported solely for that one bit of quite useful
functionality.

-srs

---

From: Douglas Otis <[email-masked]>
Date: Mon, 9 Mar 2009 09:58:43 -0700

On Mar 9, 2009, at 8:35 AM, Suresh Ramasubramanian wrote:

> that'd fit the bill.

Agreed.  It should not force double signing, for example.

> To wit - the "locked ADSP record" part.  And if that's all that is  
> required .. why then, I dont see why that part of it cant be  
> shoehorned into the base 4871 spec somehow - perhaps in -bis as a  
> newly defined tag.

This terminology is from a different draft where "all" was changed to  
"CLOSED" and "discardable" to "LOCKED".   The DKIM public key is not  
directly referenced from the email-address domain, it needs a selector  
to be discovered.  This policy is to be applied when no signature is  
found.  There does not seem to be any practical advantage attempting  
to overload the DKIM public key record, nor would a signature tag be  
that much help.

-Doug

-

---

From: Steve Atkins <[email-masked]>
Date: Mon, 9 Mar 2009 09:23:04 -0700

On Mar 8, 2009, at 5:58 PM, Suresh Ramasubramanian wrote:

> On Sun, Mar 8, 2009 at 8:58 PM, MH Michael Hammer (5304) <[email-masked] 
> > wrote:

If you have a list of domains to check, you don't need any of the
ADSP infrastructure, just require valid DKIM signatures for any
mail coming from those domains on the list.

So any use case that uses a list (private or public) of domains
to apply the algorithm to is probably out of scope for ADSP.

Cheers,
  Steve

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 9 Mar 2009 13:16:55 -0400

> [email-masked]] On Behalf Of Steve Atkins
> Sent: Monday, March 09, 2009 12:23 PM
> To: ietf-dkim WG

And this is the reason I like to say that ADSP is the public mechanism
for achieving what is currently being performed through private
agreements.

Mike

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Mar 2009 13:29:28 -0400

> to overload the DKIM public key record, nor would a signature tag be  

Lets keep this simple.

 From the beginning, there were certain policies that were considered 
that I can best summaries with these dialog box:

   -- SSP --

   DOMAIN: __________

   (_) NEVER SIGNED
   (_) ALWAYS SIGNED
        (_) ME ONLY
        (_) 3RD PARTY LIST  [ EDIT LIST ...]
   (_) SOMETIMES SIGNED
        (_) ME ONLY
        (_) 3RD PARTY LIST  [ EDIT LIST ...]

   [ SAVE SSP RECORD ] [ REMOVE SSP RECORD ]

That was deemed too complex, at least the 3rd party portions of it.

So now we have (I think)

   -- ADSP --

   DOMAIN: __________

   (_) ALWAYS SIGNED
        [_] ME ONLY
   (_) SOMETIMES SIGNED
        [_] ME ONLY

   [ SAVE ADSP RECORD ] [ REMOVE ADSP RECORD ]

Any further reduction is not going to help target the market of 
domains that at seeking exclusive DKIM signature usage.

-- 
Sincerely

Hector Santos

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Mar 2009 13:50:05 -0400

> for achieving what is currently being performed through private

Exactly.

The key reason is not just to get a standard [public] protocol, but 
when the facet is turn on full blast (the adoption catches on like 
wild fire),  there are going to be a lot of instant legacy spoofing 
that can now be detected.

Once the HVDs or PVDs (high value or private value) begin to implement 
DKIM, and IMO, I believe most will first explore DKIM with a private 
exclusive usage mode of operation before applied it in other areas, 
many compliant receivers will for the first time ever have a new level 
of standard email information to work with to better deal with the 
legacy spoofing.

I never questioned the idea that valid signatures (from good or bad 
guys) still needed to be dealt with in other ways.   But that 
classification is what we have today when receivers have no extra 
information.

The concern I always had which was the purpose of the expired DSAP I-D 
I wrote, was to protect the DKIM domain from the legacy fraud that 
exist today.

This is where the HIGH PAYOFF will be.  This is where the DKIM DOMAIN 
first trying it out will immediately see the benefit when there is 
LESS fraud on other remote receivers and sites.  When users at these 
other sites are less prone to getting spoofed mail.

Thats the payoff.

-- 
Sincerely

Hector Santos

---

From: Barry Leiba <[email-masked]>
Date: Mon, 9 Mar 2009 15:20:24 -0400

The discussion seems to be straying beyond certain useful
boundaries... as Stephen says, let's keep it within those.  So, in
particular, with my "participant" hat on:

It seems to me that the relevant point isn't whether you do or don't
like ADSP and whether you will or won't deploy it... but, rather, that
we agree on the details of it.  If you're a signer and you don't like
ADSP, you won't publish ADSP information.  If you're a verifier and
you don't like ADSP, you won't retrieve ADSP information.

So what matters is that we agree on what the ADSP information says and
means, and that we agree on the interpretation by a verifier of its
absence.

Barry

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 9 Mar 2009 15:31:21 -0400

> [email-masked]] On Behalf Of Barry Leiba
> Sent: Monday, March 09, 2009 3:20 PM
> To: [email-masked]

Starting with your last point first.... there can only be one
interpretation by a verifier of its (published ADSP record)
absence...... the signing domain does not implement ADSP.

With regard to the other discussion, for the implementations I'm engaged
in, d= works fine for ADSP. I recognize that for other implementations
using i= provides additional value. I therefore would support keeping
the reference string (domain part or HRS of i=) as i=. The fact that the
errata discusses opaqueness for DKIM base does not preclude using RHS of
i= for ADSP implementation.

Mike

---

From: Steve Atkins <[email-masked]>
Date: Mon, 9 Mar 2009 12:41:18 -0700

> means, and that we agree on the interpretation by a verifier of its

If ADSP assertions put constraints on DKIM use, especially
if those constraints end up affecting those who don't choose to
use ADSP, then it's a bit more important than that. (I'm already
seeing people who can't use DKIM appropriately because they're
using DKIM signing engines that were were written with one
limited use case in mind).

I don't know if that is the case. Does anyone else?

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Mar 2009 15:54:41 -0400

> We'll never get anywhere if we keep dragging 'good' and 'bad' into it.

+1. 100% agree. I was making reference to how the term "significant" 
was used here as to suggest it is the only thing that matters in the 
decision process.

 From my perspective, we (always) needed something that will help 
better define or rather "justify" the growing mail DISCARD ideas that 
are needed to fight back scatters and malicious mail.

This, in light of the fact that as of 2008, RFC 5321 (formerly 2821) 
now has semantics that allows operations to justify not adhering to 
the MUST BOUNCE requirement.

Systems that operate at the accept first (POST SMTP) payload checking 
MUST support SMTP requirements for bouncing. From RFC 5321

6.1.  Reliable Delivery and Replies by Email

    When the receiver-SMTP accepts a piece of mail (by sending a "250
    OK" message in response to DATA), it is accepting responsibility
    for delivering or relaying the message.  It must take this
    responsibility seriously.  It MUST NOT lose the message for
    frivolous reasons, such as because the host later crashes or
    because of a predictable resource shortage.  Some reasons that are
    not considered frivolous are discussed in the next subsection and
    in Section 7.8.

    If there is a delivery failure after acceptance of a message, the
    receiver-SMTP MUST formulate and mail a notification message.

What is new to SMTP developers and operators via the new 5321 
guidelines is 7.8:

7.8.  Resistance to Attacks

    In recent years, there has been an increase of attacks on SMTP
    servers, either in conjunction with attempts to discover addresses
    for sending unsolicited messages or simply to make the servers
    inaccessible to others (i.e., as an application-level denial of
    service attack).  While the means of doing so are beyond the scope
    of this Standard, rational operational behavior requires that
    servers be permitted to detect such attacks and take action to
    defend themselves.

7.8 is new to 5321 as of 2008. This was never a "written" 
consideration for this in the past 25 years.  User expectation for 
"notification" was "natural law."

But people did it anyway - the growing abusive era required it.

The point:

For growing systems who will perform DATA checking dynamically at the 
SMTP level, an ADSP discard policy will behave as a SMTP compliant 55x 
reject response. No mail notification is required. No SMTP violation.

On the other hand, systems that accept first then analyze the payload 
are pressured with a bounce requirement. If ADSP is followed, it is 
not a REJECT, but a DISCARD idea.

Mail reliability decreases if we don't give systems new non-frivolous 
justifications to apply via the new 7.8 semantics.

-- 
Sincerely

Hector Santos

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 09 Mar 2009 20:03:44 +0100

> for achieving what is currently being performed through private

Right!  And private agreements can only scale so far.

The use case for ADSP "discardable" at a d= level is clear, and well 
understood.  Other possible ADSP uses are much more complex, which is (IIRC) 
why the WG consensus was to leave 'em out for now.  But, that out-of-scope 
complexity doesn't remove the need for the simple case.

-- 
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: Douglas Otis <[email-masked]>
Date: Mon, 9 Mar 2009 13:45:58 -0700

On Mar 9, 2009, at 12:03 PM, J.D. Falk wrote:

>>> So any use case that uses a list (private or public) of domains to  
>>> apply the algorithm to is probably out of scope for ADSP.
>>
>> And this is the reason I like to say that ADSP is the public  
>> mechanism for achieving what is currently being performed through  
>> private agreements.
>
> understood.  Other possible ADSP uses are much more complex, which  
> is (IIRC) why the WG consensus was to leave 'em out for now.  But,  
> that out-of-scope complexity doesn't remove the need for the simple  
> case.

ADSP "discardable" is not well defined when there is an expectation  
that compliance assessments ignore the i= value.  For this, the  
following is needed.

CHANGE:

An "Author Signature" is any Valid Signature where the identity of the  
user or agent on behalf of which the message is signed (listed in the  
"i=" tag or its default value from the "d=" tag) matches an Author  
Address in the message. When the identity of the user or agent  
includes a Local-part, the identities match if the Local-parts are the  
same string, and the domains are the same string.

TO:

An "Author Signature" is any Valid Signature per section 3.2, where an  
Author Address domain is within the signature's "d=" tag and value  
domain.

-Doug

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 9 Mar 2009 16:14:00 -0400

On Mon, Mar 09, 2009 at 12:41:18PM -0700, Steve Atkins wrote:
>use ADSP, then it's a bit more important than that.

So essentially any spec that causes another DKIM record to be create to
solve interoperably problems should be viewed as a violation of DKIM
Base?

I'm thinking John L's use of i= as a cookie and ADSP. I'll note that
John's use of i= would be considered a violation too.

-- 
Jeff Macdonald
[email-masked]

---

From: Jim Fenton <[email-masked]>
Date: Mon, 09 Mar 2009 13:12:46 -0700

> it would also remove the confusion about granularity.

That's only one way to remove some of the overloading of i=; it doesn't
follow that ADSP needs to change.  The implication here seems to be that
it's ADSP that is doing the overloading.  There has been a lot of (in
many cases speculative) discussion about how the i= value could be used,
but the ADSP specification is the only place where an application for i=
is actually described (except possibly in Doug Otis's drafts).

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Mon, 09 Mar 2009 13:20:30 -0700

> I don't know if that is the case. Does anyone else?

ADSP doesn't put any constraints on a signer that doesn't publish an
ADSP record, or that publishes adsp=unknown.

Given the range of non-ADSP applications for the i= value that have been
described, verifiers would be well advised not to use the i= value as a
key to a reputation database.  So while a signer's use of ADSP might
constrain a verifier that wants to key reputation on that value, it's
not a good idea anyway.

-Jim

---

From: Franck Martin <[email-masked]>
Date: Tue, 10 Mar 2009 08:40:13 +1200 (ANAT)

Then they should upgrade.

---

From: John Levine <[email-masked]>
Date: 9 Mar 2009 21:17:35 -0000

> ADSP record, or that publishes adsp=unknown.

I sign all my mail, but there's no way I can say that with ADSP.  In
its current form, ADSP is broken and useless.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Mon, 9 Mar 2009 14:24:35 -0700

On Mar 9, 2009, at 1:20 PM, Jim Fenton wrote:

> Given the range of non-ADSP applications for the i= value that have  
> been described, verifiers would be well advised not to use the i=  
> value as a key to a reputation database.

As long as the i= relates to the on-behalf-of value in some manner as  
required by RFC 4871, there should not be a problem using this to  
reference reputation.  Only when the i= value does not correlate well  
with abuse, will i= value use be a problem.  Such problems will be  
experienced by signers that fail to reasonably constrain the i= value  
when reputation services mark all i= values as being the same.

>  So while a signer's use of ADSP might constrain a verifier that  
> wants to key reputation on that value, it's not a good idea anyway.

The Author-Signature should not constrain the use of the i= value.  It  
is important for the i= value represent in some undefined manner, the  
on-behalf-of entity.  This entity is not always going to be  
represented in the From header field.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: Mon, 9 Mar 2009 21:31:57 +0000 (GMT)

>> I sign all my mail, but there's no way I can say that with ADSP.  In its 
>> current form, ADSP is broken and useless.
>
> I thought that's what "dkim=all" says:
>
>      all    All mail from the domain is signed with an Author
>         Signature.
>
> Do you not sign them with Author Signatures?

Take a look.  I sign them all, but I don't use ADSP's version of i=

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: Mon, 9 Mar 2009 21:42:51 +0000 (GMT)

> You have chosen to sign your mail in a manner that is inconsistent with
> the practices described by ADSP.

Right.  My signatures use i= to describe the local identity responsible 
for each message, you know, like DKIM says I should.

> In any case, that's a different question than Steve asked:  He wanted to
> know if ADSP contrained domains that don't use it, and the answer is no.

Given that ADSP is useless, I don't suppose it's worth a lot of argument.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Mon, 09 Mar 2009 13:45:45 -0700

Getting back to the question that the Chairs asked us to answer:

> would go out as "old / new"; the merged document would be a rev of 4871.  Work on 

I'd like to see us go straight to a 4871bis (option 2).  The extra
editorial effort involved in merging the versions seems well worth it,
to have a single normative document for DKIM signatures.

The question that I still have is whether this 4871bis document would be
limited to "erratum" sorts of changes.  There has been a significant
amount of deployment experience since 4871 was published, and IMO it
would be beneficial to address that as well.  No, I don't have anything
particular in mind; I'm just trying to understand the ground rules.  Or
would the deployment experience be incorporated into 4871ter that you
refer to?

I don't have any experience with the types of changes that would be
allowed in 4871 and still progress the next revision to Draft Standard. 
I realize that is important to many, but I'm more interested in getting
the spec right than whether it's PS or DS.

-Jim

---

From: "John R. Levine" <[email-masked]>
Date: Mon, 9 Mar 2009 21:46:26 +0000 (GMT)

> So, by ADSP's definitions, you don't sign with Author Signatures.  That 
> doesn't mean it's "broken and useless".

Even though I do in fact sign all my mail with valid DKIM signatures, I 
can't say that with ADSP.  Perhaps there are people who consider that 
makes ADSP highly functional, but it seems an odd interpretation.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Mon, 09 Mar 2009 14:58:23 -0700

> Take a look.  I sign them all, but I don't use ADSP's version of i=

You keep telling us to do this, but the list manager strips off your
signature.  But I think we all know that you're able to do this.

-Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Mar 2009 14:28:29 -0700 (PDT)

---

From: Jim Fenton <[email-masked]>
Date: Mon, 09 Mar 2009 14:32:04 -0700

You have chosen to sign your mail in a manner that is inconsistent with
the practices described by ADSP.  Are you saying that it's not possible
for you to modify your signing practices (perhaps by not using i=)?

-Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Mar 2009 14:36:57 -0700 (PDT)

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Mar 2009 18:15:52 -0400

> makes ADSP highly functional, but it seems an odd interpretation.

Deja-vu!

Geez John, you wrote this thing.  Either you believe in it or not.

The current abstract says:

  DomainKeys Identified Mail (DKIM) defines a domain-level
  authentication framework for email to permit verification of the
  source and contents of messages.  This document specifies an adjunct
  mechanism to aid in assessing messages that do not contain a DKIM
  signature for the domain used in the author's address.  It defines a
  record that can advertise whether a domain signs its outgoing mail,
  and how other hosts can access that record.

it further says one in section 3.3. of the possible results are:

   o  All messages from this domain are signed with an Author Signature
      and discardable, i.e., if a message arrives without a valid
      Author Signature, the domain encourages the recipient(s) to
      discard it.

You clearly wrote in section 4.2.1:

    discardable   All mail from the domain is signed with an Author
                  Signature.  Furthermore, if a message arrives
                  without a valid Author 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.

Again it is repeated that the mail is "DISCARDED" when this policy is 
not met.

Is this not want you wrote?  Did you believe in it?

Is there something missing in your statement?

-- 
Sincerely

Hector Santos

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Mar 2009 14:55:38 -0700 (PDT)

> makes ADSP highly functional, but it seems an odd interpretation.

I also think it seems odd to label something which many people clearly 
consider to be potentially valuable as "broken and useless" in an 
environment which is supposed to be constructive and cooperative.

One approach encourages participation and improvement, the other 
discourages it.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Mar 2009 18:52:56 -0400

> signature.  But I think we all know that you're able to do this.

I think that is John's point, an issue we always battled with but 
never wanted to fully address - the issue regarding 3rd party signings 
or down link signings.

His exclusive signing was lost when it made the transition to the mail 
integrity breaking mailing list server (MLS).  So you end up with:

   DKIM-Signature: d=mipassoc.org ....
   Authentication-Results: sbh17.songbird.com;
	 dkim=pass (1024-bit key)
          header.i=[email-masked]
   From: "John R. Levine" <[email-masked]>

a 3rd party-like signature situation.

In SSP and in DSAP, we wanted to allow domains to define if a 3rd 
party was allowed to sign.  In fact, in DSAP

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

in regards to MLS (Mailing List Server) considerations:

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.

In john's case, he doesn't have a ADSP record, I don't think. So its 
open season on his domain.  Success, Failure, No Signatures, it 
watered down.

But if John has a ADSP policy ALL or DISCARDABLE, the smarter DKIM 
integrated MLS should not break the integrity of the message and not 
sign on behalf of john.

This was the complexity that we didn't want to deal with. But it all 
goes back to a policy description what a domains allow in regard to 
its author domain.

In this case:

Should the AR (Authentication-Result) be use to determine what the 
original domain expected?  But even here, the identity is different, 
user.iecc.com.

If we are going to allow this where there is no policy for the domain, 
then maybe the MLS "MUST" include bind the new signature with the AR 
header.

   DKIM-Signature: d=mipassoc.org
                   h=....;Authentication-Results:
   Authentication-Results: sbh17.songbird.com;
	 dkim=pass (1024-bit key)
          header.i=[email-masked]
   From: "John R. Levine" <[email-masked]>

But we should not allow this to be overall the justification why ADSP 
does not work.

There will be domains that do not want their domains to be somehow 
replayed as a 3rd party signed mailing list distribution.

If a domain has a ALL or DISCARDABLE policy, a receiver should reject 
this type of emails.  If the domain expects to use his domain in an 
open manner like this, then it should not be using any policy or one 
that says it is neutral (a waste).

-- 
Sincerely

Hector Santos

---

From: SM <[email-masked]>
Date: Mon, 09 Mar 2009 15:47:18 -0700

>its current form, ADSP is broken and useless.

Given that one of the authors of draft-ietf-dkim-ssp-09 states that 
ADSP is broken and useless, is it worth publishing it on the 
Standards Track or even asking for publication?

Regards,
-sm

---

From: "Siegel, Ellen" <[email-masked]>
Date: Mon, 9 Mar 2009 19:00:24 -0400

> the spec right than whether it's PS or DS.

While I'm not at all opposed to doing a -bis document, I think that a number of people are vastly underestimating the time required to take one to completion. 

My preference would be to declare consensus for the Errata document, and then work the contents from that document and any other relevant errata into a more polished -bis document. (I haven't been around for a whole lot of ietf votes, but 2/3 sure sounds about as close as a working group is likely to get towards consensus on issues like these.)

That approach gets the gist of the Errata clarifications out in a much more timely manner (i.e., almost immediately), and does not preclude the generation of the -bis document as rapidly as the process allows. 

Ellen 

------------------
Ellen Siegel
Constant Contact

---

From: Douglas Otis <[email-masked]>
Date: Mon, 9 Mar 2009 16:48:43 -0700

On Mar 9, 2009, at 2:55 PM, Murray S. Kucherawy wrote:

>> Even though I do in fact sign all my mail with valid DKIM  
>> signatures, I can't say that with ADSP.  Perhaps there are people  
>> who consider that makes ADSP highly functional, but it seems an odd  
>> interpretation.
>
> I also think it seems odd to label something which many people  
> clearly consider to be potentially valuable as "broken and useless"  
> in an environment which is supposed to be constructive and  
> cooperative.

ADSP constrains the use of the i= value in a manner the precludes its  
intended role.  This should be described as "broken" or at least  
"incompatible" with RFC4871.  When adhering to RFC4871, and there are  
cases where the i= value will not be found within the From header  
field.  Extra steps are needed to overcome ADSP incompatibilities and  
will be an impediment toward adoption.

> One approach encourages participation and improvement, the other  

Agreed.  There should be greater sensitively for adoption  
impediments.  ADSP will not achieve sufficient adoption when only a  
small percentage of those deploying DKIM can safely make ADSP  
assertions beyond "unknown".  Using terms like "CLOSED" and "LOCKED"  
instead of "all" and "discardable" were intended to avoid prejudicial  
handling that might discourage adoption, for example.

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 09 Mar 2009 16:57:40 -0700

Barry,

The purpose of rules and precedents is to make a process more equitable and
predictable.  The management of draft-ietf-dkim-rfc4871-errata[1] is failing to
conform to the IETF's rules and precedents.

This failure is more than an academic issue.  The draft was developed to respond
to real-world concerns affecting the use of DKIM signing *now*.  Those
concerns are being ignored, through the spontaneous invocation of undocumented
constraints that ensure delays and give no practical sense of how closure will
be achieved.

DKIM Chair wrote:
> The first point is that while 2/3 of the working group prefer the stronger
> and more extensive clarifications in the "Dave draft"
...
> Since Dave's draft has a clear majority behind it, we'd like those who
> disagree with some parts of it to help with making it more acceptable to
> everyone -- or most of us, anyway -- so we can get it out as a 4871 update.

1.  So, you are formally declaring that 2/3 is not rough consensus, in spite of
its typically being sufficient?

2.  "to everyone" is never an IETF requirement.  And "or most of us" is entirely
ambiguous; I've no idea what it means or what will satisfy it.  Do you?

3.  While it's always nice to get more support for a draft, a review of the
working group archive shows that none of those voting against
draft-ietf-dkim-rfc4871-errata engaged in anything that looks like negotiation;
they deny the problems that the draft addresses. In marked contrast, the draft
was produced through an incremental group process of discussion, debate and
revision. So your decision effectively hands a veto to those who disagree with
the draft, in spite of a 2/3 consensus in its favor, unless you have some plan
for a process that will produce real discussion and real compromise.  Do you?

> Dave's changes, in particular, introduce new terminology and make enough
> changes in how the affected areas of the spec are worded that Pasi believes
> -- and thinks the IESG as a whole will agree -- that it needs to go

To get this on the record explicitly and clearly:

    The IESG has Errata rules that cover the qualities required or prohibited
for an Errata entry that applies to a standards track document.  By all
appearances, those rules are being invoked but not followed.  They say nothing
about the length of an entry and they say nothing about introduction of
terminology, yet those are the two factors being cited for not issuing the
Errata draft.  If the IESG is creating new Errata rules, it needs to document
them.  What is happening here, however appears to be an ad hoc, undocumented
modification of the rules.

    In spite of multiple requests, we have not yet been told what specific IESG
Errata rule justifies refusing to publish the draft as an Errata entry and how,
exactly, the rule applies to draft-ietf-dkim-rfc4871-errata.

> We're concerned, though, with the lack of visibility of errata, and we note
> that some of these errata are important for people to see when they're
> implementing 4871.  That might make it worth taking one of these two paths
> (and this is what we'd like the working group to decide):

An additional irony to the "visibility" argument -- beyond being invoked without
detailed justification and without prior discussion in the working group -- is
that the ultimate /in/-visibility is failure to make the changes available at all.

The reason for pressing to develop and approve draft-ietf-dkim-rfc4871-errata as
an Errata is timeliness.

We are being repeatedly assured that the RFC path can be quick, but that is in
terms of numbers of months and it ignores the real-world timeline for RFCs (and
for this working group.)  Immediate example:  The Overview passed working group
last call almost 4 months ago and has not yet been submitted to the IESG.  We
have only just received Area Director review comments, requiring problematic
changes that will take more time to resolve, especially since there is no
indication which changes are required and which are merely advisory.  And
this is a common type of delay for RFC processing.

Your note appears to propose pursuing further revisions, through a quick
RFC4871bis effort, but it can only "quick" by making assumptions that are
probably wrong:  We have not yet gotten working group discussion or agreement on
what the revision effort will cover and it could easily encompass more than
you've been assuming.

Both in terms of content and process, quick is likely not to be.

So here is a counter-proposal, with three steps we should pursue:

1. Declare draft-ietf-dkim-rfc4871-errata approved by the working group.  Submit
it as an RFC Errata, containing text that indicates working group approval.  The
question of IESG approval affects its status label in the Errata database, but
not whether it is available through the RFC Errata mechanism.  While it would be
nice to have IESG approval, it's not a requirement for Errata distribution.
Whatever the deficiencies of Errata visibility, it's better than failure to
distribute.  We also can promote it through other channels.

2. If the claim is that 2/3 is not rough consensus, the working group need to be
told why, told what /will/ qualify, and given a much more concrete basis for
understanding how progress is going to be made at reaching agreements.  Some
groups naturally resolve issues through constructive debate, but this isn't one
of them. Discussion, here, needs far more active management than the group has
been getting.

3. Then we should follow your Option 2.

d/

[1]  The best way to indicate that draft-ietf-dkim-rfc4871-errata is from a
      group effort is to refer to it by its draft name.
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Mon, 09 Mar 2009 17:13:18 -0700

Dave CROCKER wrote:>
> draft-ietf-dkim-rfc4871-errata engaged in anything that looks like negotiation;

Objection: ad hominem.

> they deny the problems that the draft addresses. 

Objection: strawman.

		Mike

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Mar 2009 00:00:21 +0000

> Standards Track or even asking for publication?
Firstly, we're not authors in the sense of being personally  
responsible for each word - the ability and willingness to write  
something with which you disagree is laudable in many cases and in  
this case. Secondly, I don't think anyone would accuse John of a  
chronic tendency to understatement. So, no I don't believe his  
statement has any such implication,
S.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 9 Mar 2009 17:57:50 -0700

On Mar 9, 2009, at 5:00 PM, Stephen Farrell wrote:
>>> I sign all my mail, but there's no way I can say that with ADSP.   
>>> In its current form, ADSP is broken and useless.
>>

Being in agreement with both John and SM, why is it reasonable to  
ignore this statement?

Starting off with bad definitions is likely to forestall ADSP  
benefits.  Additional security is less likely to be achieved when ADSP  
signature definitions are impractical, or reduce delivery integrity.

Barry's suggestion to move ahead with ADSP seems unwise in light of  
recent discussions of how one should interpret ADSP definitions, and  
the i= value in particular.  Requiring two signatures for compliance  
is just wrong.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Mar 2009 21:01:59 -0400

I fail to see how one can willing to write a document reluctantly, 
write things he doesn't believe it, doesn't champion it and expect 
this to be followed, standardized and adopted.  Regardless in how this 
is spinned, if John doesn't think ADSP is useful, there are not going 
to be many to endorse its progress.

Of course, if John believe its broken, is he interested, able and 
willing in fixing it?  It appears that is what you implying.

-- 
Sincerely

Hector Santos

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Mar 2009 00:05:33 +0000

Does the subject line and the endless rehashing of old arguments imply  
that there is, in fact, no recession and that we all have plenty of  
time to do all this for the n-th time?

*Please* re-read and opine on Barry's message, and not on this aged  
topic.
S.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 09 Mar 2009 18:07:13 -0700

> i= for ADSP implementation.

Along with others, I think discussion of whether ADSP will or won't be useful is 
wasteful at best but more likely counter-productive.  Oh.  And out of scope.

Now, for the question that /is/ within scope:

    Given the clarification that we've now done on d= vs. i=, ADSP should use d= 
and only d=.

1.  The d=/i= clarification made clear that relying on i= is problematic.

2.  d= is sufficient for ADSP's stated goal.

3.  The current ADSP re-defines i= semantics.  While this is theoretically 
legal, it is neither necessary nor useful.  So the important question is not 
about legality, but about need. ADSP's use of i= makes the meaning of DKIM 
constructs more complicated and contingent.  As a specific example, why should 
ADSP use require Levine to alter his signing practices, given that they are 
entirely legal with respect to DKIM signing?

Simplicity and sufficiency are usually deemed to be compelling arguments in 
technical design.  If they don't hold sway here, why?

      "We could do it, but it would be wrong."
                           - /Richard Nixon/

We could use i=, but it would be wrong.

d/

ps.  Yes, this means changing the definition of "author signature"

-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 09 Mar 2009 21:14:59 -0400

On Mon, 09 Mar 2009 16:57:40 -0700 Dave CROCKER <[email-masked]> wrote:
> ... a review of the
>draft-ietf-dkim-rfc4871-errata engaged in anything that looks like 
negotiation; ...

Since you're such an expert on IETF procedural requirements, where is it 
this requirement to negotiate documented?

Scott K

---

From: Jim Fenton <[email-masked]>
Date: Mon, 09 Mar 2009 20:07:33 -0700

> for a process that will produce real discussion and real compromise.  Do you?

This is somewhat at odds with the fact that I voted against
draft-ietf-dkim-rfc4871-errata (more accurately: in favor of a different
proposal) and am listed in the acknowledgements.  But I suppose that my
efforts at negotiation don't count because they weren't on the list.

I also view Eliot Lear's suggested erratum as an attempt at negotiation
but it takes >= two to negotiate.

-Jim

---

From: SM <[email-masked]>
Date: Mon, 09 Mar 2009 22:15:46 -0700

Hi Stephen,
>statement has any such implication,

The authors do not have to agree to every word in their draft if the 
document is the work of a WG.  It is laudable that authors include 
material they may not fully agree with.  I appreciate John Levine's candidness.

Quoting part of the message from the DKIM Chair:

  "Then there's the question of where ADSP stands, and whether it can 
proceed as is,
   or needs to be changed in light of the "errata".  Pasi may have 
some comments on
   this, and I know the working group will.  We've been holding ADSP 
up for a while,
   and we need to release it and move it forward."

The WG will probably be asking the IETF community to review and 
comment on the ADSP draft.   If one of the authors has serious 
concerns about that draft, it is better to have them voiced out now 
so that the WG can decide where ADSP stands.

Regards,
-sm

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Mar 2009 09:38:21 +0000

SM wrote:
> The WG will probably be asking the IETF community to review and comment
> on the ADSP draft.   If one of the authors has serious concerns about
> that draft, it is better to have them voiced out now so that the WG can
> decide where ADSP stands.

I consider that John's concerns have already been "voiced," even if
most recently in a quite sloppy manner. To be fair though, John has
been consistent throughout the entire process. And the WG has
consistently kept on with ADSP on the standards track.

Stephen.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 10 Mar 2009 10:11:34 -0400

In response to Dave's long note, I think there are (at least) two
major issues that we need to separate:

1. How to move forward and declare working group rough consensus on
the errata draft.

2. Why, specifically, Pasi thinks the "errata" draft requires fresh
IETF rough consensus.

I'm going to split these into two new threads; messages forthcoming.

Barry

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Mar 2009 10:39:17 -0400

> I'm going to split these into two new threads; messages forthcoming.

Not sure if you see this as worthy, but there was a few things he said 
that was troublesome, namely:

    ASDP using d= only.

This will not allow for no-signature "i always sign" DKIM=ALL or 
DKIM=DISCARDABLE policy.

In other words, ADSP only applicable when is a VALID signature.

A fundamental change neither of the above options address.

-- 
Sincerely

Hector Santos

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 10 Mar 2009 12:18:29 -0400

On Mon, Mar 09, 2009 at 07:00:24PM -0400, Siegel, Ellen wrote:

>While I'm not at all opposed to doing a -bis document, I think that a
>number of people are vastly underestimating the time required to take
>one to completion.
>
>My preference would be to declare consensus for the Errata document,
>and then work the contents from that document and any other relevant
>errata into a more polished -bis document. (I haven't been around for
>a whole lot of ietf votes, but 2/3 sure sounds about as close as a
>working group is likely to get towards consensus on issues like
>these.)
>
>That approach gets the gist of the Errata clarifications out in a much
>more timely manner (i.e., almost immediately), and does not preclude
>the generation of the -bis document as rapidly as the process allows.

+1

-- 
Jeff Macdonald
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Tue, 10 Mar 2009 17:21:00 -0700

> its current form, ADSP is broken and useless.

Since you are completely at liberty to create as many DKIM-SIGNATURE's
as you want, the only reason ADSP is "broken and useless" is because
you don't want to make the effort.

		Mike

---

From: Barry Leiba <[email-masked]>
Date: Tue, 10 Mar 2009 22:57:59 -0400

Dave says...
> entirely legal with respect to DKIM signing?

I'll note that Jim posted a draft:
   http://tools.ietf.org/html/draft-fenton-dkim-reputation-hint
to float the concept that this sort of thing can be done with another
tag that doesn't try to overload the meaning of an existing one.  I'll
note that the same sort of thing can be used if we want to narrow the
scope of ADSP tighter than just the domain.

I'll also note that such a thing could be done in the base ADSP... or
in an extension to ADSP that's written later.

I'm not sure what my opinion is on that last point, but on the first
point I think it's best to define an identifier that's specifically
for ADSP's use, if we want that function.  Some signers may give that
tag the same value they give i=, and there's no harm done.  Some
signers may use a different value, which would demonstrate the wisdom
of separating them.

Barry

---

From: John Levine <[email-masked]>
Date: 11 Mar 2009 10:40:18 -0000

>signers may use a different value, which would demonstrate the wisdom

Seems like a reasonable way to avoid the i= fight. If there's interest,
I can whip up a new ADSP draft with an r= tag.

R's,
John

---

From: [email-masked] (Wietse Venema)
Date: Wed, 11 Mar 2009 09:15:21 -0400 (EDT)

> I can whip up a new ADSP draft with an r= tag.

I am not sure how adding an r= tag would help deciding whether a
specific d= domain has made a first-party signature on behalf of
the rfc822.from.

Another way to avoid the i= fight is to design it out of ADSP
(leaving it in DKIM, if it can't be eliminated there).

ADSP is looked up for mail without a first-party DKIM signature.
In an ADSP without i=, the ingredients for the "first-party"
signature decision are:

1) DKIM signature check: Is the DKIM signature valid per DKIM rules
(this may or may not involve i=, but that is outside ADSP's scope).

2) First party check: Do rfc822.from and d= have the proper
relationship. This check is ADSP-specific.

If these checks fail, look up the ADSP policy for rfc822.from and
make a ruling.

	Wietse

---

From: Michael Adkins <[email-masked]>
Date: Wed, 11 Mar 2009 09:53:33 -0400

> I can whip up a new ADSP draft with an r= tag.
I would be interested. If ADSP isn't supposed to be part of the base
spec, there's no reason folks interested in using it can't add a
specific additional tag to implement it.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 11 Mar 2009 10:17:51 -0400

>I can whip up a new ADSP draft with an r= tag.

um, I read Jim's draft to use r= for "reputation" and not for ADSP. So
specify a new tag for ADSP.

-- 
Jeff Macdonald
[email-masked]

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 11 Mar 2009 12:01:25 -0400

> [email-masked]] On Behalf Of John Levine
> Sent: Wednesday, March 11, 2009 6:40 AM
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Moving on to ADSP - was RE: Handling the
> errataafter the consensus call
> 

I view introducing a new tag at this point as problematic. 

Using i= or even going to using d= does not require any changes to
current DKIM signing implementations. Introducing a new tag means that
implementers are at the mercy of the timeframes that vendors choose to
change how they sign DKIM.

As I have said before, I can personally accept using d= because of how
we chose to implement DKIM signing for our domains. I lean towards i=
for ADSP because I believe it gives others benefits.

Mike

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 11 Mar 2009 17:59:42 +0100

> I view introducing a new tag at this point as problematic.

Agreed.

> for ADSP because I believe it gives others benefits.

So then i= would be effectively meaningless to verifiers, EXCEPT when used 
in conjunction with ADSP, where it needs to match the author (From:) address?

Seems reasonable to me, assuming we're all agreed that i= is opaque to 
verifiers in all other cases.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 11 Mar 2009 10:15:05 -0700

Isn't it much simpler, and entirely sufficient, to have ADSP use SDID (d=)?

I am not understanding the downside to the choice.

The alternatives all seem significantly more complicated and probably problematic.

d/

-- 

   Dave Crocker

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 11 Mar 2009 13:28:23 -0400

The use of i= allows multiple subdomains to have the same d= DKIM
signature. As I said, I can live with d= personally but viewing it from
a standards approach I recognize the value of using i= for organizations
that use a number of subdomains. 

Sometimes simplifying in one place (eliminate use of i= in favor of d=)
creates (operational) complexity in another.

J.D. gets where I'm going with this. 

Mike

> [email-masked]] On Behalf Of Dave CROCKER
> Sent: Wednesday, March 11, 2009 1:15 PM
> To: J.D. Falk
> Cc: [email-masked]
> > So then i= would be effectively meaningless to verifiers, EXCEPT
when
> used

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Mar 2009 11:12:50 -0700

> The alternatives all seem significantly more complicated and  

100% agreed. : ^)

Depending upon the interpretation given for Section 3.2 of ADSP, any  
valid DKIM signature from the Author Domain may omit ADSP record  
transactions.

The only logic for requiring either a DKIM signature that lacks an i=  
value, or one that matches against the From header, would be there is  
something special about a DKIM signature that lacks the i= value.   
There does not appear to be any rational semantics to explain what is  
implied when the i= value is missing.  On that point, Dave is correct.

Since the ADSP draft is already internally in conflict on this point,  
a simple solution would be to drop the i= value requirement in ADSP.

If the DKIM i= value becomes defined as always being opaque, then ADSP  
will need to define some other tag to introduce a non-opaque namespace  
if DKIM is to be seen a method to affirm an email-address.   Defining  
i= values as always being opaque is not really needed.  After all, a  
valid signature does indicate the entity applying the signature is  
acting on behalf of the owners of the email-address namespace.

The present DKIM draft could be clarified as offering an i= value that:

a) represents a real email-address whenever it matches against a  
signed header field within the message, or

b) represents an opaque identifier whenever it does not match against  
a signed header within the message.

This clarification avoids a need to create a new tag, and still  
permits those implementing ADSP a means to affirm an email-address,  
but _only_ when the i= value matches exactly with signed header field.

Since there are those that do not want to extend the use of DKIM In  
this manner, ADSP would need to be seen as allowing a domain to only  
enforce a signature requirement.   Either affirming an email-address  
or just enforcing a signature requirement would be fine, but there  
should be agreement about what is intended goal of ADSP.

-Doug

---

From: "Siegel, Ellen" <[email-masked]>
Date: Wed, 11 Mar 2009 14:55:09 -0400

> On Behalf Of John Levine

Sounds like a good approach to me. 

Ellen

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 11 Mar 2009 14:59:58 -0400

> [email-masked]] On Behalf Of Douglas Otis
> Sent: Wednesday, March 11, 2009 2:13 PM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Moving on to ADSP - was RE: Handlingthe

You are incorrect Doug. Look at RFC4871:

If the DKIM-Signature header field does not contain the "i=" tag, the
   verifier MUST behave as though the value of that tag were "@d", where
   "d" is the value from the "d=" tag.

There is nothing special about a DKIM signature missing an i= filed. One
simply uses the d= field. Seems pretty straight forward to me.

> a simple solution would be to drop the i= value requirement in ADSP.

I see no conflict.

> acting on behalf of the owners of the email-address namespace.

<SNIP>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Mar 2009 19:07:00 +0000

> Sounds like a good approach to me. 

Just in case: Please don't prepare a new ADSP draft right now.

Stephen.

---

From: Hector Santos <[email-masked]>
Date: Wed, 11 Mar 2009 15:46:01 -0400

> Just in case: Please don't prepare a new ADSP draft right now.

+1.

But I will add that any "information" regarding how a message is 
expected to be signed or authored, it does make sense it should be in 
the ADSP record.  This begins to move back semantics like we had with 
SSP which is good.

I use three design criteria I try to use to keep sense of all this:

   1) no signature
   2) invalid 1st party signature
   3) the presence of 3rd party signature

The 1st and 2nd are easy, and so is the 3rd one if the ADSP is neutral 
on its signature.

-- 
Sincerely

Hector Santos

---

From: HLS <[email-masked]>
Date: Wed, 11 Mar 2009 15:54:43 -0400

The more we move "policy" information or in this case Jim's reputation-based
policy r= idea to the DKIM policy record, the better, where it ought to be
to better cover the legacy transactions (those without signatures).

-- 
hls

---

From: Jim Fenton <[email-masked]>
Date: Wed, 11 Mar 2009 15:55:05 -0700

Before I attempt to answer Dave's question, I have two questions for the
Chairs:

1. Is discussion of ADSP on the list in order again?

2. It sounds like what's being proposed here is a "do over" of the WG
and IETF Last Calls on the ADSP specification, by making a substantial
change.  Is that in order?

-Jim

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Mar 2009 19:26:52 -0400

>change.  Is that in order?
I have a somewhat related question.  It seems to me that this latest round of "let's redo ADSP 
again" was kicked off by a need to change ADSP due to the pending DKIM-base errata.

How is it possible that a design that has been through WGLC needs to be changed due to errata 
for an RFC it is built on and that errata is not making changes to the IETF of what the 
protocol is?  Compared to most of you I'm pretty new to IETF processes and 
so I' appreciate some help understanding this.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Mar 2009 16:40:01 -0700

On Mar 11, 2009, at 11:59 AM, MH Michael Hammer (5304) wrote:
>> On Mar 11, 2009 11:12 AM, Douglas Otis wrote:
>>
>> The only logic for requiring either a DKIM signature that lacks an  
>> i= value, or one that matches against the From header, would be  
>> there is something special about a DKIM signature that lacks the i=  
>> value. There does not appear to be any rational semantics to  
>> explain what is implied when the i= value is missing.  On that  
>> point, Dave is correct.
>
> If the DKIM-Signature header field does not contain the "i=" tag,  
> the verifier MUST behave as though the value of that tag were "@d",  
> where  "d" is the value from the "d=" tag.

A signature lacking an i= value defaults to the d= value, but this  
does not represent a From email-address!   As someone said, domains do  
not write emails, which leaves the "on-behalf-of" identity *undefined*.

> There is nothing special about a DKIM signature missing an i= filed.  
> One simply uses the d= field. Seems pretty straight forward to me.

Why must an i= value only represent a From email-addresses when  
present, when it is equally okay for the i= value to be omitted?  When  
a DKIM public key imposes a g= restriction, the i= value MUST contain  
the restricted local-part or the DKIM signature WILL NOT be valid.    
It will be evident to an MUA whenever a restricted local-part does not  
match against a From header.  It should also be safe for an MUA to  
annotate signed headers that match against the i= value, but not those  
that do not match, such as when the i= value is omitted or it omits  
everything but the d= value.  In such cases, just the domain might be  
annotated.

In either case, the i= value (on-behalf-of identity) might become  
declared as being opaque and thus defined as not representing a  
specific email-address.  When the i= value is declared opaque, no  
email-address should be annotated, even when it happens to match  
against the i= value.

>> Since the ADSP draft is already internally in conflict on this  
>> point, a simple solution would be to drop the i= value requirement  
>> in ADSP.
>
> I see no conflict.

Oops.  This has been corrected off-list since version 6.  Section 3.2  
now states Author Signature.  Well, Section 3.2 will need to change  
back to Author Domain if or when i= value dependence is removed.

By removing the i= dependency from ADSP, the assertions of "all" or  
"discardable" could then apply to any DKIM signature by the domain.

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Mar 2009 13:04:18 +0100

> that use a number of subdomains.

The difference between one record and two records per label is quite a 
bit smaller than the difference between no label and one.  This group 
burnt the i= bridge when we required each and every subdomain to have a 
valid ADSP record.

Eliot

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 12 Mar 2009 09:24:21 -0400

> From: Douglas Otis [mailto:[email-masked]]
> Sent: Wednesday, March 11, 2009 7:40 PM
> Cc: [email-masked]; [email-masked]

Whether i= or d=, when I go to look for the ADSP record I'm only looking
at the RHS of the address. Therefore, what does it matter if a signature
lacking an i= defaults to d=? Logically, unless I have a constraining g
value and even then (note well):

g=  Granularity of the key (plain-text; OPTIONAL, default is "*").
       This value MUST match the Local-part of the "i=" tag of the DKIM-
       Signature header field (or its default value of the empty string
       if "i=" is not specified), with a single, optional "*" character
       matching a sequence of zero or more arbitrary characters
       ("wildcarding").  An email with a signing address that does not
       match the value of this tag constitutes a failed verification.
       The intent of this tag is to constrain which signing address can
       legitimately use this selector, for example, when delegating a
       key to a third party that should only be used for special
       purposes.  Wildcarding allows matching for addresses such as
       "user+*" or "*-offer".  An empty "g=" value never matches any
       addresses.

Domains sign mail. Unless you can show that every user has access to
creating/modifying the keys in DNS. You have provided nothing that shows
there is an issue.

> the restricted local-part or the DKIM signature WILL NOT be valid.

So what's the problem? Do you expect domains publishing an ADSP policy
to intentionally not provide an i= value and include a g= value? I admit
that there will always be some people who will screw things up
regardless of how careful a framework is constructed and how many
warnings and cautions are provided...... so what? It's kind of like
publishing an SPF record that consists of only "-all" and then
complaining that people are not accepting your mail.

> everything but the d= value.  In such cases, just the domain might be

And where is the problem? Go do the lookup against the d= domain. That
is what the default is. Notwithstanding the g tag constraint, this works
fine thank you very much.

> email-address should be annotated, even when it happens to match

Conflating layers. Just because DKIM base considers it an opaque value
does not mean that ADSP must consider it an opaque value. By choosing to
publish an ADSP record one is at least indicating that a receiver (again
excepting the g tag case you specified with no i= present - a quite
artificial construct that should fail) should look at the RHS of the
string called an RFC2822From email address. 

> "discardable" could then apply to any DKIM signature by the domain.

As I have written multiple times (and I'm getting tired of repeating),
while simply using d= works fine for me, using i= can make deployment
easier for quite a few domains without any significant downside other
than causing some people to get ruffled feathers that DKIM base
considers the i= string opaque for it's purposes and ADSP imposes a
constraint (for those domains which choose to publish ADSP records) with
regard to checking against the RFC2822From email address (RHS).

---

From: Douglas Otis <[email-masked]>
Date: Thu, 12 Mar 2009 11:06:10 -0700

On Mar 12, 2009, at 6:24 AM, MH Michael Hammer (5304) wrote:
> From: Douglas Otis, Mar 11, 2009 7:40 PM
>>> the verifier MUST behave as though the value of that tag were  
>>> "@d", where  "d" is the value from the "d=" tag.
>>
>> does not represent a From email-address!   As someone said, domains  
>> do not write emails, which leaves the "on-behalf-of" identity  
>> *undefined*.
>
> Whether i= or d=, when I go to look for the ADSP record I'm only  
> looking at the RHS of the address. Therefore, what does it matter if  
> a signature lacking an i= defaults to d=? Logically, unless I have a  
> constraining g value and even then (note well): <key g definition  
> elided >

> creating/modifying the keys in DNS. You have provided nothing that  
> shows there is an issue.

Is this agreement with removing dependence upon the i= value?

>>> There is nothing special about a DKIM signature missing an i=  
>>> filed. One simply uses the d= field. Seems pretty straight forward  
>>> to me.
>>
>> present, when it is equally okay for the i= value to be omitted?   
>> When a DKIM public key imposes a g= restriction, the i= value MUST  
>> contain the restricted local-part or the DKIM signature WILL NOT be  
>> valid.
>
> So what's the problem? Do you expect domains publishing an ADSP  
> policy to intentionally not provide an i= value and include a g=  
> value?

The original motivation for ADSP imposing i= value dependence was in  
hope of causing non-From-g-restricted-signatures to be rejected.   
Ironically, few domains will double-sign exceptions to ADSP's  
requirement that i= values must matching against a From email- 
address.  In effect, this inhibits both the intended use of the i=  
value and ADSP.  If few domains use ADSP, few receiving MTA will  
reject messages on the basis of non-From-g-restricted-signature non- 
compliance with ADSP.

When MUAs annotate using Authentication-Results headers, non-From-g- 
restricted-signatures represent less risk since MUAs can still  
determine the intended identity, whether the identity is the list- 
manager as Sender or the From header.  Currently, ADSP dependence upon  
the i= value may require inclusion of a DKIM signature where the i=  
value is omitted, which can not be done by a non-g-restricted- 
signature.  If non-From-g-restricted-signatures represent a  
significant risk, they should be considered invalid by the base  
specifications!

> I admit that there will always be some people who will screw things  
> up regardless of how careful a framework is constructed and how many  

By removing i= dependence, an ADSP assertion of "all" could then mean  
_all_ messages are signed.  This reduces mistakes and keeps things  
simple, while also eliminating possible double signing requirements.

>> It will be evident to an MUA whenever a restricted local-part does  
>> not match against a From header.  It should also be safe for an MUA  
>> to annotate signed headers that match against the i= value, but not  
>> those that do not match, such as when the i= value is omitted or it  
>> omits everything but the d= value.  In such cases, just the domain  
>> might be annotated.
>
> And where is the problem? Go do the lookup against the d= domain.  
> That is what the default is. Notwithstanding the g tag constraint,  
> this works fine thank you very much.

In order to exclude non-From-g-restricted-signatures, all i= values  
that do not match against the From header must currently be double  
signed.  This additional requirement is a problem when few wish to  
double sign otherwise perfectly valid DKIM signatures.

> Conflating layers. Just because DKIM base considers it an opaque  
> value does not mean that ADSP must consider it an opaque value. By  
> choosing to publish an ADSP record one is at least indicating that a  
> receiver (again excepting the g tag case you specified with no i=  
> present - a quite artificial construct that should fail) should look  
> at the RHS of the string called an RFC2822From email address.

ADSP records are not checked when there is a valid Author Signature.   
An Author Signature IS a DKIM signature!  If i= values are always  
declared opaque, rather than conditioning opacity on not matching  
against a signed header email-address, then g-restricted-signatures  
will become a meaningless mechanism.  Security must be reviewed in  
light of this mechanism being made meaningless.

>>>> point, a simple solution would be to drop the i= value  
>>>> requirement in ADSP.
>>>
>>> I see no conflict.
>>
>> Oops.  This has been corrected off-list since version 6.  Section  
>> 3.2 now states Author Signature.  Well, Section 3.2 will need to  
>> change back to Author Domain if or when i= value dependence is  
>> removed.
>>
> As I have written multiple times (and I'm getting tired of  
> repeating), while simply using d= works fine for me, using i= can  
> make deployment easier for quite a few domains without any  
> significant downside other than causing some people to get ruffled  
> feathers that DKIM base considers the i= string opaque for it's  
> purposes and ADSP imposes a constraint (for those domains which  
> choose to publish ADSP records) with regard to checking against the  
> RFC2822From email address (RHS).

ADSP is not independent of DKIM.  Removing ADSP dependence on the i=  
value enables acceptance of non-From-g-restricted-signatures.  This  
will not affect any sub-domain convenience, nor will it lead to  
exploits that can not be mitigated through refusal of non-From-g- 
restricted-signatures or use of Authentication-Results headers.

-Doug