Subject: [ietf-dkim] draft Errata on RFC 4871

From: Dave CROCKER <[email-masked]>
Date: Sun, 25 Jan 2009 23:24:26 -0800

Folks,

Howdy.

I've just submitted an Internet Draft with text for the working group to 
consider. A group of us have been working on it.

It clarifies and resolves the roles and relationship of the d= and i= tag.

An html version of the I-D is at:

    <http://dkim.org/specs/draft-ietf-dkim-rfc4871-errata-00.html>

d/
-- 

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

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 26 Jan 2009 13:07:17 +0530

I support this, as well as the wording that emphasizes d='s role.

I particularly like the analogy here .. where it puts forward a
concept I have of d= being the sum(i= 1-n) from an authority and
reputation perspective.

--------

This document was initially formulated by an ad hoc design team,
comprising: Jon Callas, J D Falk, Jim Fenton, Tony Hansen, Murray
Kucherawy, John Levine, Michael Hammer, Jeff Macdonald, Ellen Siegel,
Wietse Venema. It represents a rough consensus of that effort,
although the final wording of the submitted draft is the sole
responsibility (d=) of the listed author.

--------

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Jan 2009 10:41:30 +0000

Thanks Dave (and the other's acked) for taking this on
and making a firm proposal.

I guess we've a couple of questions related to this:

Firstly, do we have rough consensus on the substance of
the erratum?

Separately, is the best route from here to do a 4871bis
(assuming the 5378 mess gets sorted), that incorporates
all agreed errata to date? If not, then what?

I'd welcome opinions on the above in the next week or
so,

Thanks,
Stephen.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Jan 2009 12:48:17 +0100

Hi Dave,

I have a request and an objection.

First, the request.  You may want to include a clarification (I didn't 
see it) on the text blob size in DNS and how to deal with keys that are 
larger (most implementations simply concatenate; but it should have been 
clearly specified).  Murray and I discussed this some time ago.

The objection is this: you are introducing new concepts and terminology 
in errata.  That's not the point of errata.  The point of errata is to 
correct minor errors in the specification or to clarify points whose 
intent was clear to the WG and implementers but perhaps not in the spec, 
such that an interoperability problem could arise.  I would suggest that 
your additions actually deserve a new RFC, and I would have no 
objections with you proceeding in that general direction.

Eliot

---

From: Tony Hansen <[email-masked]>
Date: Mon, 26 Jan 2009 07:22:17 -0500

I strongly support working on a 4871bis >>and<< moving DKIMbase forward
to Draft Standard as part of that.

	Tony

---

From: John Levine <[email-masked]>
Date: 26 Jan 2009 13:48:02 -0000

>to Draft Standard as part of that.

Same here.  I don't feel strongly about errata vs. 4871bis, so I have
a practical preference for whatever will get it through the IESG and
published as expeditiously as possible.

With respect to Eliot's point about long strings, section 3.6.2.2
already says you concatenate the strings together.  If something's
insufficiently clear we could of course take the opportunity to
clarify it.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Jan 2009 15:55:32 +0100

On 1/26/09 3:38 PM, Siegel, Ellen wrote:
>
> The new text does introduce new terminology, but I disagree that it is adding new concepts.

>   The issue that the new text is attempting to address is that the existing language describing the concepts is confusing, and in some cases inconsistent and/or absent, and will likely lead to interoperability issues if it has not already.
>    

Please say more because this is not at all clear to me.  Why are more 
TLAs (or in this case FLAs) there?  Also, you've defined another term: 
Identity Assessor.  Why?

Finally, I'll add one more comment, and then I'll withdraw.  There are a 
lot of errata filed for 4741. This is a good indication that it's 
probably time for another version, and I would view this as good news 
because it demonstrates a lot of work has occurred.  Congratulations to 
all!  Whether that version is PS or draft is a debate unto itself, but 
not my debate ;-)

Eliot

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 26 Jan 2009 07:07:29 -0800

> all agreed errata to date? If not, then what?

Stephen,

The intent for this effort was to issue it as an Errata entry, per 
<http://www.rfc-editor.org/errata.php>.

The changes are narrow and few.  We really don't need to generate a brand new 
RFC just for this.  Or at least, not yet, IMO.

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 26 Jan 2009 07:33:45 -0800

> TLAs (or in this case FLAs) there?  Also, you've defined another term: 

There is real and substantial confusion in the community about these two tag 
values.  Confusion that affects interoperability.  (I tend to use the cliche' 
about watches:  if you have one, you know what time it is; if you have two, you 
are never quite sure.)

I regularly hear someone explain their particular, reasonable and sophisticated 
intent behind using one or another of the two values, as if there is some magic 
by which the organization running the other side of the DKIM exchange is going 
to a) be motivated, and b) be knowledgeable enough, to incorporate that intent 
into their use of DKIM.  In fact, the other participant has no way of knowing 
about that intent, and scaling limits make it impossible to incorporate all the 
different intents.

What is missing is the thing that has always been at the core of successful 
Internet protocol interoperability:  a small, common, core of semantics. The 
DKIM community disagrees about which of the two values is that common, core, 
semantic output.

Creating distinctive names for the two makes a reference that uses one of them 
unambiguous; clarifying the role and relationship of each makes the meaning of 
each unambiguous.  That's goodness.  It's also essential for interoperability.

> because it demonstrates a lot of work has occurred,

Good point.

So I'll suggest that we considered this proposed Errata as an Errata entry, 
first and by itself, and *then* pursue generating a revised dkimbase RFC.

That way we focus on the proposed Errata narrowly, and reach consensus on it, 
before expanding the scope to an entirely new RFC.

Tony's suggestion that we pursue Draft status at the same time makes sense to 
me.  I had forgotten there were all those other errata.

d/

ps. I can't find any documentation that says anything about Errata scope other 
than it covers 'errors'.  Beyond that legalistic point, the proposed change is, 
in fact, quite narrow and it merely fixes the technical ambiguity about the 
output that the document says is its primary goal.

-- 

   Dave Crocker

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 26 Jan 2009 21:30:42 +0530

> about watches:  if you have one, you know what time it is; if you have two, you

I would support Eliot's point about introducing new terminology into
an errata document rather than a -bis RFC as a followup to this one.
Especially as a lot of work has already been done on this, it might be
appropriate to produce both this errata document as well as a -bis
based on broader feedback from the IETF community.

Speaking entirely for myself,  I always thought d= and i= are quite
clear concepts by themselves, on what they denote and what they
authenticate.  There is, of course, substantial difference in opinion
exist on their actual real life use cases, and on what reputation
model can reasonably be layered on top of this authentication (or
combinations of d= and i= some of which may be possible in more based
on these.

I personally dont see how differences in opinion on the use cases and
reputation model are going to be resolved by this new terminology, but
if some consensus has already been achieved on the FLAs, I give my
qualified support to this changed nomenclature - based on any previous
consensus that it makes the distinction between d= and i= clearer.

Conversely (and I thank Eliot for raising this issue), if there is
enough consensus that the FLAs can be dispensed with,  I dont mind
either.

In either case, the next step I would suggest is an operational "use
case" document, which takes off where

> 9. Section 6.3. Interpret Results/Apply Local Policy

leaves off by simply stating that this is beyond the scope of this RFC.

The use case document can certainly describe scenarios (from both
sides of the d=i=vide) where d= and i= are used to

[a] authenticate an email (where there is little or no controversy]

[b] layer a reputation model on top of this authentication [which is
the bone of contention between the d= and i= camps, though possibly
out of scope for this RFC or any use case document strictly based on
DKIM as a framework  for  authentication].

Finally, whether or not the new FLAs are adopted or the old
nomenclature is retained, in my view, the errata document serves its
purpose by emphasizing the primacy of d= over i= (or in this case,
their new FLA equivalents).  Dave's analogy in the errata, about him
being d= as the primary author of this RFC while the other
contributors are i= is particularly apt in this case.

Oh by the way, Dave, if you introduce new terminology for d= and i= ..
might be reasonable to follow it in the entire document? :)

> A. Acknowledgements
[...]
> although the final wording of the submitted draft is the sole responsibility (d=) of the listed author.

regards
--srs

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 26 Jan 2009 21:34:49 +0530

bah. rephrased .. i need to go produce an errata document for this
email - i drafted it in two or three stages and this slipped through
my proof reading.

" There are of course substantial difference in opinion on their
actual real life use cases"

"What reputation model can reasonably be layered on top of this
authentication, either singly or in various combinations of d= and i=,
some of which may only be completely realized in more fine grained
filtering systems, and to a possibly lesser extent or not at all in
larger and more high volume receiver mail systems, which may choose to
concentrate either solely on d= or i=."

suresh

---

From: Dennis Dayman <[email-masked]>
Date: Mon, 26 Jan 2009 09:37:55 -0600

I'm ok with this... Addresses the majority of confusion that's even  
popped up in the last week or so.

-Dennis

---

From: Tony Hansen <[email-masked]>
Date: Mon, 26 Jan 2009 10:18:56 -0500

There are no new concepts introduced in this errata, just giving some
names (and four letter acronyms) to existing concepts so they can be
referenced easily later on. This set of errata could be written without
introducing those names or four letter acronyms. But adding the names
and FLAs seemed to make the text shorter and more to the point.

	Tony Hansen
	[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Jan 2009 18:32:28 +0100

Dave,

I'm okay with your proposed approach.  I agree that errata is a bit 
vague, but since they don't always get read, and sometimes aren't even 
known about, the next rev seems apt.

Eliot

Eliot

On 1/26/09 4:33 PM, Dave CROCKER wrote:
>> TLAs (or in this case FLAs) there?  Also, you've defined another 
>> term: Identity Assessor.  Why?
>
> There is real and substantial confusion in the community about these 
> two tag values.  Confusion that affects interoperability.  (I tend to 
> use the cliche' about watches:  if you have one, you know what time it 
> is; if you have two, you are never quite sure.)
>
> I regularly hear someone explain their particular, reasonable and 
> sophisticated intent behind using one or another of the two values, as 
> if there is some magic by which the organization running the other 
> side of the DKIM exchange is going to a) be motivated, and b) be 
> knowledgeable enough, to incorporate that intent into their use of 
> DKIM.  In fact, the other participant has no way of knowing about that 
> intent, and scaling limits make it impossible to incorporate all the 
> different intents.
>
> What is missing is the thing that has always been at the core of 
> successful Internet protocol interoperability:  a small, common, core 
> of semantics. The DKIM community disagrees about which of the two 
> values is that common, core, semantic output.
>
> Creating distinctive names for the two makes a reference that uses one 
> of them unambiguous; clarifying the role and relationship of each 
> makes the meaning of each unambiguous.  That's goodness.  It's also 
> essential for interoperability.
>
>
>> Finally, I'll add one more comment, and then I'll withdraw.  There 
>> are a lot of errata filed for 4741. This is a good indication that 
>> it's probably time for another version, and I would view this as good 
>> news because it demonstrates a lot of work has occurred,
>
> Good point.
>
> So I'll suggest that we considered this proposed Errata as an Errata 
> entry, first and by itself, and *then* pursue generating a revised 
> dkimbase RFC.
>
> That way we focus on the proposed Errata narrowly, and reach consensus 
> on it, before expanding the scope to an entirely new RFC.
>
> Tony's suggestion that we pursue Draft status at the same time makes 
> sense to me.  I had forgotten there were all those other errata.
>
> d/
>
> ps. I can't find any documentation that says anything about Errata 
> scope other than it covers 'errors'.  Beyond that legalistic point, 
> the proposed change is, in fact, quite narrow and it merely fixes the 
> technical ambiguity about the output that the document says is its 
> primary goal.
>

---

From: Michael Adkins <[email-masked]>
Date: Mon, 26 Jan 2009 11:43:10 -0500

A question regarding the notes in 10 and 11:

Would it make more sense to suggest that the mail system make the UAID 
clear to the reader if its the identity whose reputation was used to 
deliver the message, and make the SDID clear to the reader otherwise?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: SM <[email-masked]>
Date: Mon, 26 Jan 2009 09:06:08 -0800

>Firstly, do we have rough consensus on the substance of

As Dave pointed out in his draft, there is some confusion about 
identities in RFC 4871.  If this is a clarification of the consensus 
at the date of publication of the RFC, then it can take the Errata path.

RFC 4871 defines one signing identity.  If the changes proposed in 
this draft are approved, DKIM will provide two identities.  By doing 
so, the draft is introducing concepts which some may see as 
formalizing what is in RFC 4871 while others may consider them as 
new.  Although the proposed input (d= and i=) for the Assessor module 
may not affect existing implementations, the draft changes the 
definition of these tags.

In my opinion, the draft is more than an erratum.

>all agreed errata to date? If not, then what?

That may be the best route.

Regards,
-sm

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 26 Jan 2009 23:12:03 +0530

> deliver the message, and make the SDID clear to the reader otherwise?

The RFC seems to steer clear from it beyond emphasizing the
differences between sdid / uaid.

Maybe just leave this for the use case document I suggested? If it is
inappropriate for an RFC, it could be produced as a maawg document.

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

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 26 Jan 2009 09:47:31 -0800

> deliver the message, and make the SDID clear to the reader otherwise?

Simple question:  why?

Complex question:  What is the empirical basis for believing that any user 
interface design recommendations that we make will have any utility to the 
end-user?  Experience with usability design demonstrates a key constant:  it is 
almost impossible to ensure user interface utility in the absence of empirical data.

-- 

   Dave Crocker

---

From: Michael Adkins <[email-masked]>
Date: Mon, 26 Jan 2009 13:40:13 -0500

I think there will be cases where a signer chooses to make their UAID 
semantics known to assessors specifically for assessment purposes. How 
the signer might communicate that to the assessors is out of scope for 
the moment I think. I would assume that, for starters, the signers would 
approach individual assessors/mailbox providers. If it proved useful and 
was worth doing on a larger scale, then we could figure out a way to 
make the signer's preference automatically known to assessors.

Siegel, Ellen wrote:
> [> ]
> Given that the semantics of the UAID are inherently opaque, how would you suggest that the mail system make the assessment? I like the concept, but don't see how it can be implemented given the defined syntax/semantics.
>
> Ellen
>

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 26 Jan 2009 13:48:42 -0500

>almost impossible to ensure user interface utility in the absence of empirical data.

That all depends on who the reader is and what is meant by clear. :)

For me just putting that information in a header in which I could tell
Mutt to display works for me. :)

But for everyone else, viewing the source (or internet headers) is
always an option. I don't know if that qualifies as "clear to the
reader", but it is close enough for me.

-- 
Jeff Macdonald
[email-masked]

---

From: Michael Adkins <[email-masked]>
Date: Mon, 26 Jan 2009 13:55:27 -0500

Dave CROCKER wrote:
>> Would it make more sense to suggest that the mail system make the 
>> UAID clear to the reader if its the identity whose reputation was 
>> used to deliver the message, and make the SDID clear to the reader 
>> otherwise?
>
>
> Simple question:  why?
>
> Complex question:  What is the empirical basis for believing that any 
> user interface design recommendations that we make will have any 
> utility to the end-user?  Experience with usability design 
> demonstrates a key constant:  it is almost impossible to ensure user 
> interface utility in the absence of empirical data.

Simple answer: If the purpose of the original text was to point out to 
users who the message is really from in cases of suspected forgery, and 
through whatever means the receiving system has decided that the real 
responsible identity is the UAID and not the SDID , it seems to me to 
fit better with the original intention of showing the user who the 
message is really 'from' to point out the UAID.

Complex answer:  I agree with the observation and don't know that there 
is any.  Is there a purpose for changing these sections beyond 
consistency with the rest of the document?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 26 Jan 2009 20:50:14 -0000

>message is really 'from' to point out the UAID.

Except that the UAID might or might not be an e-mail address.  The one
on this messgage isn't.

R's,
John

---

From: Michael Adkins <[email-masked]>
Date: Mon, 26 Jan 2009 15:58:56 -0500

That's correct.  This is dependant on the receiving system having some 
knowledge that the UAID is meaningful to parties outside the signing 
domain, and is therefore not the default.

---

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

> knowledge that the UAID is meaningful to parties outside the signing domain, 
> and is therefore not the default.

OK.  Now we're back to my t=address proposal, I guess.

R's,
John

---

From: Tony Hansen <[email-masked]>
Date: Mon, 26 Jan 2009 15:56:36 -0500

A side conversation with several people generated these two areas of
interest to a verifier about the i= identifiers being generated by a signer:

1) Are the values stable? That is, will the same value be used by the
signer each time a message is signed on behalf of a particular
user/agent? Examples of stable values are
[email-masked] (such as AUIDs that use the same
namespace as their users' email addresses),
[email-masked] (such as AUIDs based on the users'
internal user IDs), and [email-masked] (such as
AUIDs based on a hash of the user name). Examples of unstable values
would be ones that incorporate additional information within the i=
value that is time varying, but is still able to be mapped to a single
user's/agent's identity.

2) For stable values, is the namespace the same as the users' email
addresses? That is, is the stable value the same as the user's email
address?

One suggestion made was to use key record t= value to communicate this
information.

	Tony Hansen
	[email-masked]

Michael Adkins wrote:
>> Given that the semantics of the UAID are inherently opaque, how 
>> would you suggest that the mail system make the assessment? I like
>> the concept, but don't see how it can be implemented given the
>> defined syntax/semantics.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 26 Jan 2009 14:09:29 -0800

but, ummm...,  this really would be a functional enhancement, and so it ought to 
be discussed as part of the broader RFC revision effort, and certainly under a 
different thread, such as the Subject I'm using here...

d/

-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: Mon, 26 Jan 2009 22:25:47 +0000 (GMT)

> So, for clarity, can you (or someone) call out what you think is
> the impact, if any, for ADSP, caused by this proposed change to
> 4871.

Nothing.  ADSP's attempt to force i= to be an identifier that is an e-mail 
address was wrong before, and the errata doesn't change that.

I've put a note pointing that out in the proposed next draft, with a 
kludgy workaround being a second signature with no i= field.

If it were up to me, I'd remove all the references to i= from ADSP, but 
there seem to be people who believe that it will be useful.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J D Falk" <[email-masked]>
Date: Mon, 26 Jan 2009 16:24:45 -0500

> published as expeditiously as possible.

+1

Also, +1 to Suresh's suggestion of a use cases document.

---

From: Michael Adkins <[email-masked]>
Date: Mon, 26 Jan 2009 17:44:00 -0500

The stability part I agree with. For the second area of interest, are 
you saying the verifier would only find it interesting if i= was the 
same as the user's (for some definition of 'user') email address?

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 26 Jan 2009 14:45:04 -0800

> address was wrong before, and the errata doesn't change that.

Independent of whether ADSP will or will not be useful, John, there is nothing 
technical broken about what it is trying to do or how it goes about doing it.

It probably *is* a new model, in terms of what it does and how it does its job, 
but again, that's different from whether there ADSP has any theoretical problems.

For a base spec to say "the value is opaque" and another spec to come along and 
say "I'm announcing the particular, and possibly interesting, scheme that I 
follow for creating that value, and I promise to conform to that scheme for all 
such values that I create" is just fine.

Note for example, that BATV does a version of exactly this for Local-part. The 
only 'theoretical' difference is that BATV doesn't publish a record about what 
mailfrom creators are conforming.

So if you have a technical argument for this line of criticism that you keep 
repeating, I don't recall hearing it.  (And you know I'm not a fan of ADSP, but 
there are lots of mechanisms that I don't like which are, nonetheless, 
technically competent and maybe even useful...)

> there seem to be people who believe that it will be useful.

An entirely different issue is whether ADSP should refer to i= or to d=, and 
whether approval of the proposed Errata should change that choice.

But, then, that was the point of the question that was being asked...

FWIW, my opinion is that it should switch to d=, as the safer, simpler, more 
stable, and sufficient value.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 26 Jan 2009 14:49:10 -0800

Suresh Ramasubramanian wrote:
>    (from both sides of the d=i=vide) 

oh my.  i had missed that bit of cleverness.

thank you.  best quip of the day.

d/

-- 

   Dave Crocker

---

From: Tony Hansen <[email-masked]>
Date: Mon, 26 Jan 2009 17:50:42 -0500

The only one of interest I've seen suggested so far was if the i= value
was identical to the users' email addresses. But I could potentially see
other possible values for the 2nd area of interest. Another way to frame
the 2nd area of interest is: what type of namespace does the signer use,
if they care to identify it?

	Tony Hansen
	[email-masked]

Michael Adkins wrote:
>> but, ummm...,  this really would be a functional enhancement, and so
>> it ought to be discussed as part of the broader RFC revision effort,
>> and certainly under a different thread, such as the Subject I'm using
>> here...
>>
>> d/
>>
>> Tony Hansen wrote:
>>  
>>>> I think there will be cases where a signer chooses to make their
>>>> UAID semantics known to assessors specifically for assessment
>>>> purposes. How the signer might communicate that to the assessors is
>>>> out of scope for the moment I think. I would assume that, for
>>>> starters, the signers would approach individual assessors/mailbox
>>>> providers. If it proved useful and was worth doing on a larger
>>>> scale, then we could figure out a way to make the signer's
>>>> preference automatically known to assessors.
>>>>
>>>>
>>>> Siegel, Ellen wrote:
>>>>      
>>>>>          
>>>>>> UAID

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Jan 2009 21:51:04 +0000

Thanks,
Stephen.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 26 Jan 2009 18:44:04 -0500

>different thread, such as the Subject I'm using here...
Could we please let the ink dry on the one we have first?

Scott K

---

From: John Levine <[email-masked]>
Date: 27 Jan 2009 00:49:28 -0000

>same as the user's (for some definition of 'user') email address?

There's a school of thought that verifiers could do something extra if
they knew that the i= was supposed to be an actual e-mail address.
(Send the complaints there, I guess.)

As it stands, you can't tell whether i= is supposed to be an address,
a stable identifier, a serial number, or whatever.  So I suggested we
could define some new flag values to put into the t= in the keys so
that signers could declare their intentions, with the two suggested
flags being "it's stable" and "it's an address".

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 26 Jan 2009 17:06:17 -0800

> at the date of publication of the RFC, then it can take the Errata path.

I believe that clear definitions, relationship and usage of the two values was 
never fully developed as a working group consensus.  Hence the need to do it now.

Many participants had their individual understandings, but we didn't specify a 
common one.

> RFC 4871 defines one signing identity.  If the changes proposed in 

The document uses that specific term ambiguously.  Although, yes, there is a bit 
of text that is quite explicit about the definition, usage elsewhere in the 
document is conflicting.

> this draft are approved, DKIM will provide two identities.  By doing 

Common interpretation of the document is that it *already* provides two 
identities.  The Errata merely makes clear their nature and priority.

> definition of these tags.

Errata aren't allowed to fix something by changing it?

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 26 Jan 2009 17:13:12 -0800

Jim Fenton wrote:
> The phrase "the value is opaque" could be interpreted to mean that it
> MUST NOT have any easily-discerned relationship to other things.  So any
> message with an Author Signature (as defined in ADSP) would be in
> violation of the base spec.  If it said "the value MAY be opaque" that's
> probably reasonable.

Jim,

There is nothing in the semantics of "opaque" that says the structure can't be 
there.  It means there is no means of declaring and communicating it that is 
part of the standard and hence the presence of any possible structure and 
semantics is outside of the spec.

I don't know what "easily-discerned" means, as a technical term talking about an 
interoperable protocol.

What "opaque" means and what the draft Errata text says explicitly is:

    "Their sub-structures and particular semantics are not publicly
    defined and, therefore, cannot be assumed by an Identity Assessor."

Hmmm.  Perhaps that sentence should be added to the definitions of the two 
terms, rather than appear in the 'relationship' section?

Use of language like "MAY be opaque" would completely defeat the point behind 
explaining that, in terms of technical standards specification in the base 
document -- the string has no guaranteed structure or meaning.  That's the 
essence of opacity.  That some encoders might create structure and meaning and 
that some assessors might discern it is nicely heuristic.  And heuristic ain't 
standard.

Anyhow, I think that clarifying text has a meaning that is clear -- if not, then 
we need to fix it -- and certainly quite different from the interpretation you 
are suggesting.

Also, can you provide some technical distinction between "easily discerned" and 
"not easily discerned" with respect to technical implementation?

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Mon, 26 Jan 2009 16:59:27 -0800

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Mon, 26 Jan 2009 17:27:04 -0800

> there seem to be people who believe that it will be useful.
Nevertheless, what's in the specification represents working group rough
consensus, in connection with issues 1399 and 1519.  There have been
opportunities in WG Last Call and IETF Last Call to reconsider that
decision.

In response to Stephen's question, there are several things that I see
as problems relative to ADSP:

The position of ADSP in the verification process hasn't been defined,
which is reasonable since ADSP is an add-on.  Therefore, it must be part
of the Assessor rather than part of the verification process itself. 
This document makes the passing of the i= value (referred to as UAID)
optional, which means that some verifiers will not provide a value
required by the ADSP specification.

Section 5, paragraph 4, "responsible Identifiers that are individual,
opaque values" can be interpreted as requiring that an opaque value be
chosen by the signer, which would prohibit Author Signatures as defined
in ADSP.

Section 5, last paragraph, argues that interpreting any structured
semantics for either of the identifiers is "heuristic".  To the extent
that a signing domain publishes an ADSP "All" or "Discardable" record,
they are making an assertion of the semantics of the i= identifier so it
is not a heuristic.

I have many other comments about this draft, which I will save for
another message.

-Jim

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 27 Jan 2009 07:45:57 +0530

I dont particularly care if ADSP sinks .. i= being forced / mandated,
with various contortionist use-case scenarios isnt really going to
make it all that much of a hit among receivers.

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 27 Jan 2009 07:51:45 +0530

Mike Adkins had an interesting suggestion where he'd use d=aol.com to
sign outbound messages, and i=[email-masked], [email-masked] and
[email-masked] to denote various reputation scores that aol's filters
assigned an outbound message.

This would allow aol to separate mail into different streams at their
end, and it'd allow receiving ISPs aware of this i= classification to
specialcase their filters to watch for i=bad or i=suspect email from
aol.

That's just one use case .. it is not just senders wanting a separate
reputation for all their clients so that some bad clients dont harm
the rest of their client base.

Even in the AOL scenario.. ADSP would be a nonstarter, thank god.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 26 Jan 2009 18:44:14 -0800

> opportunities in WG Last Call and IETF Last Call to reconsider that

So, Jim, I commend your effort at retrieval specific references.

Certainly ADSP needs to say what string it is using.

Unfortunately your presenting citations raises the question of whether they 
resolve the current question.  My own conclusion is that they do not, for 
several reasons:

    1. 1399 received no substantive discussion and was then declared redundant 
with 1519.  So citing it winds up confusing the current discussion.

    2. 1519 had nothing to do with the choice between d= vs. i=.  It asked a 
very different question about i=.

    3. One could argue that all discussion "assumed" i=, but that's a very 
different claim that one that says we considered d= vs. i= and chose i=.

    4. If there is consensus on the proposed Errata, it well might change the 
basis for applying d= vs. i= to ADSP.  In fact this question, and the need to 
resolve it, was the reason for pressing so hard to get the Errata text onto the 
wg table.  (Yeah.  A lot earlier would have been a lot better, but the degree 
and impact of the confusion didn't become so compellingly clear until recently.)

So I strongly suggest that folk should not rely on the relatively legalistic 
claim that the choice of i= is a fait accompli.  It will invite more contentious 
and unproductive debate, of the type we might recall from earlier wg history.

> of the Assessor rather than part of the verification process itself. 

That matches my architectural, ummmm, assessment too.

> required by the ADSP specification.

Since the base specification makes the existence of the tag optional, making its 
delivery optional does not represent a change to its basic nature.  It might be 
there; it might not.

> they are making an assertion of the semantics of the i= identifier so it

As an incremental specification, ADSP essentially changes the definition of the 
delivered string from "opaque" to "author email address".  I do not see that 
sort of incremental specification as problematic in any way; in fact I see it as 
a reasonable approach to adding capability.

The creator of the string is publishing additional information and the consumer 
of the string can choose to use that additional information.  In terms of 
protocol design, that is a nicely collaborative enhancement, with no penalty to 
anyone choosing not to participate.  The base specification still works.

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 26 Jan 2009 18:46:49 -0800

> specialcase their filters to watch for i=bad or i=suspect email from

and why is that better, or worse, than d=good.aol.com, d=bad.aol.com, 
d=suspect.aol.com?

note your reliance on "ISPs aware of this i= classification".  It means that the 
mechanism won't scale, since we cannot assume that an arbitrary receiver will be 
aware of an arbitrary signer's scheme.

d/
-- 

   Dave Crocker

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 27 Jan 2009 08:40:06 +0530

On Tue, Jan 27, 2009 at 8:16 AM, Dave CROCKER <[email-masked]> wrote:
> note your reliance on "ISPs aware of this i= classification".  It means that
> the mechanism won't scale, since we cannot assume that an arbitrary receiver
> will be aware of an arbitrary signer's scheme.

The nice thing about i= is that it doesnt have to mean a thing except
to the sender emitting it.

The sender should not count on recipients knowing about i= or caring
about it enough to matter.

So - if a sender wants to sign i= besides d=.. they can count on a
feedback loop based on d= coming back to them and then separating this
loop email easily into multiple client domains based on the i= they
have inserted.  That's entirely internal to them and none of the ISP's
concern, if they choose to ignore that i=.

And if the ISP wants to sign i= to separate their mail streams up to
the receiver to decide whether they want to filter based on it or not.

i= can be freeform and any arbitrary value for all that I care (e&oe
some due diligence to stop mta exploit attempts being stuffed in i=)

--srs

---

From: Tony Hansen <[email-masked]>
Date: Mon, 26 Jan 2009 21:58:39 -0500

I don't think this idea meets the criteria that the i= value represents the

	Identity of the user or agent (e.g., a mailing list manager) on
	behalf of which this message is signed ...

My reading of this is that you can have a 1-to-1 mapping between the i=
value and the user/agent's identity, and you can have an N-to-1 mapping,
but you can't have a 1-to-N mapping. "good", "bad" and "suspect" do not
represent the identity.

	Tony Hansen
	[email-masked]

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 27 Jan 2009 09:40:57 +0530

>        behalf of which this message is signed ...

When you have a large, faceless mass of users (say at a huge consumer
ISP), all subject to the same outbound filtering norms, the identity
or the individual reputation of the actual user who emitted the
message is, frankly, irrelevant.  And the individual value of an i= in
such a situation wouldnt be worth anything at all assuming d= =
sum(i=) in a reputation score..

Or for us - we have 76 million ++ users, 400k domains. We could if we
so choose sign i=customerdomain1.com, customerdomain2.net etc .. but
we dont want individual reputation scores for different domains on our
network when they are all subject to the same acceptable use policy,
and same outbound (and inbound) filtering criteria.

And this suggestion from Mike Adkins would be a much more apt way to
use i= in such a context.

> but you can't have a 1-to-N mapping. "good", "bad" and "suspect" do not

They represent something more useful in such a context - an aggregated
identity that helps distinguish reputation in a more fine grained way
than simply d=largeisp.com .. while not going to the ridiculous
lengths that several million different values of i= would take this
line of reasoning.

srs

---

From: Tony Hansen <[email-masked]>
Date: Mon, 26 Jan 2009 23:27:40 -0500

But it breaks one of the constraints placed on the i= value, which is
not a good thing. Why do that when you can get the same functionality by
using the valid values of i=@good.largeisp.com, i=@bad.largeisp.com and
i=@suspect.largeisp.com?

	Tony Hansen
	[email-masked]

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 27 Jan 2009 10:04:26 +0530

> using the valid values of i=@good.largeisp.com, i=@bad.largeisp.com and

That too is possible.  The point about i= being a collective sum of
multiple user reputations, in a large isp scenario, doesnt depend on
this.  But that constraint is not too relevant, given the assumption
that i= can be anything at all and is mostly relevant to the entity
that signs and transmits the email.

-srs

---

From: Tony Hansen <[email-masked]>
Date: Tue, 27 Jan 2009 01:07:26 -0500

But i= can't be anything at all; it *does* have certain constraints.
Thinking otherwise is a bad assumption.

	Tony Hansen
	[email-masked]

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 27 Jan 2009 11:44:52 +0530

> Thinking otherwise is a bad assumption.

I' m simply considering one of the most common use cases of i=

And while it should certainly follow the accepted rfc format - the
function of i= as discussed in this thread makes it moot except for
the email signing + transmitting entity, unless the recipient wants to
consider it.

Operationally - at least in a large mail system - I believe that is
the case. I would invite comments on how common this POV is ..

srs

---

From: SM <[email-masked]>
Date: Mon, 26 Jan 2009 22:17:25 -0800

At 17:06 26-01-2009, Dave CROCKER wrote:
>I believe that clear definitions, relationship and usage of the two 
>values was never fully developed as a working group 
>consensus.  Hence the need to do it now.

In my opinion that cannot be done through an erratum.

>Common interpretation of the document is that it *already* provides 
>two identities.  The Errata merely makes clear their nature and priority.

The draft Errata does not update Section 1.1 of RFC 4871 which 
discusses about Signing Identity.

Section 3.5 of RFC 4871 defines "d=" as the domain of the signing 
entity.  And the relevant paragraph goes on saying that the domain 
that will be queried for the public key.  It does not mention whether 
it's only for the retrieval mechanism or if it can also be read as an identity.

If we were having a wider discussion, I would ask about the purpose 
of key granularity (g= in Section 3.6.1) when "d=" is considered as 
the "stronger" identity.

>Errata aren't allowed to fix something by changing it?

Based on the first paragraph that I quoted and the current 
discussion, the answer in this case is no.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 27 Jan 2009 07:05:44 -0800

SM wrote:
> The draft Errata does not update Section 1.1 of RFC 4871 which discusses 
> about Signing Identity.

That section also does not tie the term to a particular tag.  So what is the 
problem with not changing the section?

> entity.  And the relevant paragraph goes on saying that the domain that 
> will be queried for the public key.  It does not mention whether it's 
> only for the retrieval mechanism or if it can also be read as an identity.

The proposed errata changes the text.  So I'm not understanding what point you 
are making here.

> Based on the first paragraph that I quoted and the current discussion, 
> the answer in this case is no.

I don't understand.

d/
-- 

   Dave Crocker

---

From: "Adkins, Michael" <[email-masked]>
Date: Tue, 27 Jan 2009 10:17:47 -0500

Ok.  The key question there seems to me to be 'does the UAID namespace
represent actual identities'?  For most of the use cases I can think of
for assessing the UAID, it doesn't really matter whether it matches the
from address or not. 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tony Hansen
Sent: Monday, January 26, 2009 2:51 PM
To: DKIM IETF WG
Subject: Re: [ietf-dkim] RFC4871bis

	Tony Hansen
	[email-masked]

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 27 Jan 2009 20:54:58 +0530

> for assessing the UAID, it doesn't really matter whether it matches the

In fact it is in many cases irrelevant except to the sender himself

srs

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 27 Jan 2009 07:33:06 -0800

> In fact it is in many cases irrelevant except to the sender himself

(note the Subject reverted back to the original thread.)

It looks as if the two of you are agreeing that the i= value is indeed opaque to 
a receiver.

d/
-- 

   Dave Crocker

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 27 Jan 2009 21:04:10 +0530

On Tue, Jan 27, 2009 at 9:03 PM, Dave CROCKER <[email-masked]> wrote:
> It looks as if the two of you are agreeing that the i= value is indeed
> opaque to a receiver.

Cant speak for madkins but that's my impression.  I would also add
"often irrelevant"  besides "opaque"

---

From: "Adkins, Michael" <[email-masked]>
Date: Tue, 27 Jan 2009 10:46:55 -0500

Yes, we are in agreement about opacity.  I would even agree about the
'often irrelevant' part.  It's the few large cases where it's a good
solution that I would like to make sure we can still use it.

And I didn't really mean for my comment on the errata to turn into a
discussion of this topic, so if this isn't a good time for it we can
come back to it later.

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 27 Jan 2009 11:00:16 -0500

>"often irrelevant"  besides "opaque"

you lost me Suresh. It seemed like you were saying that i= would be
useful for different streams or groups of identities but then you say
"often irrelevant".

I believe what i= means is irrelevant from the perspective of a
receiver, but it does denote that something is different than a
straight d= value. Is that your thinking too?

-- 
Jeff Macdonald
[email-masked]

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 27 Jan 2009 21:31:51 +0530

The few large cases are

1. Exceptions to the general rule

2. Useful only when backed with some out of band discussion about
these .. I trust you to know that when you sign email as good (or bad)
it probably is that . but how much would I trust other providers?  Or
suppose a sender signs his mail streams as "transactional", "coi",
"soi", it entirely depends on how much I trust their assessment, and
in some cases whether the sender is actually emitting "coreg",
"leads", "harvested"

That kind of corner case often involves a judgement call on the part
of the admin, and a shared understanding of the i= notation, and of
the underlying reputation model.

--srs

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 27 Jan 2009 21:34:38 +0530

> straight d= value. Is that your thinking too?

Does my followup email (which I just sent) clarify things better?

i= values MAY denote something different from a straight d= value, and
when there's a shared understanding of the i= values, and of the
underlying reputation model, d= will generally amount to sum(i= 1..n)

But i= is entirely useless and, more importantly, untrustable without
some out of band trust worked out - either through a reputation vendor
certifying the i=, or through mutual contact (such as your setting up
a feedback loop with an ISP that bases its loop on dkim, and then
telling them what your signing policies are)

--srs

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 27 Jan 2009 08:10:00 -0800

Suresh Ramasubramanian wrote:
> these .. 

How does (or should) this affect the proposed Errata specification?

d/
-- 

   Dave Crocker

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 27 Jan 2009 21:58:07 +0530

> How does (or should) this affect the proposed Errata specification?

Sufficient de-emphasis of i= (or new FLA equivalent thereof).
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Adkins, Michael" <[email-masked]>
Date: Tue, 27 Jan 2009 11:39:06 -0500

Your notes in 10 and 11 are correct in that UAID should be replaced with
SDID, with one caveat.  If you can't assume that the UAID is even an
identity, there is no reason to warn the reader that the UAID is
different from the From address or point it out.

The only cases where the handling mail system would want to follow the
Errata as currently written are when they have reason to believe that
the UAID is the responsible identity.

-----Original Message-----
From: Dave CROCKER [mailto:[email-masked]] 
Sent: Tuesday, January 27, 2009 11:10 AM
To: Suresh Ramasubramanian
Cc: Adkins, Michael; DKIM IETF WG
Subject: Re: [ietf-dkim] draft Errata on RFC 4871

d/
-- 

   Dave Crocker

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 27 Jan 2009 11:50:29 -0500

>the underlying reputation model.

ah, I think I understand now. This is simply a mechanism to limit the
amount of potential i= values. If d= is in a some sort of list, then
i= would be included the reputation model.

I'd still think even given that model, you'd let the actions of the i=
determine the trustworthness of the steam independent of what the owner
of d= claims.

-- 
Jeff Macdonald
[email-masked]

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 27 Jan 2009 22:25:07 +0530

> determine the trustworthness of the steam independent of what the owner

Always crosscheck, is a good general rule. But let's put it this way
.. if I trust you enough to even look at your i= (let alone engage in
the contortions of d= and i= permutations and combinations that ADSP
would require) then I dont need to keep more than a general eye on
your mail stream.

Especially as I know its backed by a feedback loop where you will be
alerted about issues and deal with them (we at outblaze tie our loop
to a strong whitelist, and you cant get a loop unless we whitelist you
.. so we have been using that reputation model early on).

---

From: "Adkins, Michael" <[email-masked]>
Date: Tue, 27 Jan 2009 12:00:05 -0500

[Changing subject as per Dave's request]

I've thought about just sort of passively watching UAID values and
building heuristics to guess whether they are worth assessing or not.
It might be really useful, or it might just be a complete waste of
resources.  There's no good way to know for sure without doing the
research first.

That said, I plan to do the research at some point in the (hopefully
near) future.  So long as the spec accounts for experimentation and
doesn't forbid it, I think we'll be fine.

-----Original Message-----
From: Jeff Macdonald [mailto:[email-masked]] 
Sent: Tuesday, January 27, 2009 11:50 AM
To: Suresh Ramasubramanian
Cc: Adkins, Michael; [email-masked]; DKIM IETF WG
Subject: Re: [ietf-dkim] draft Errata on RFC 4871

-- 
Jeff Macdonald
[email-masked]

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 27 Jan 2009 09:01:06 -0800

> the UAID is the responsible identity.

If I'm understanding the exchange you two are having, I think it means 
suggesting two changes to the draft Errata:

   1.  For 10 and 11, change UAID to be SDID.

   2.  Add text about the use of i= stating that it's use for assessment goes 
beyond using d= and is MUST be based on additional knowledge of its creation 
that is outside the specification.

Does this reflect what you two are implying?

d/
-- 

   Dave Crocker

---

From: "Adkins, Michael" <[email-masked]>
Date: Tue, 27 Jan 2009 12:05:28 -0500

It does.

-----Original Message-----
From: Dave CROCKER [mailto:[email-masked]] 
Sent: Tuesday, January 27, 2009 12:01 PM
To: Adkins, Michael
Cc: DKIM IETF WG
Subject: Re: [ietf-dkim] draft Errata on RFC 4871

   2.  Add text about the use of i= stating that it's use for assessment
goes 
beyond using d= and is MUST be based on additional knowledge of its
creation 
that is outside the specification.

d/
-- 

   Dave Crocker

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 27 Jan 2009 22:38:34 +0530

ok by me

srs

---

From: Tony Hansen <[email-masked]>
Date: Tue, 27 Jan 2009 12:13:08 -0500

I think Suresh (and possibly Mike) are advocating a different sort of
model for i= that I (and I think many others) have for it.

They appear to be ignoring one part of the i= definition

	Identity of the user or agent (e.g., a mailing list manager) on
	behalf of which this message is signed

and that's the word "identity". They seem to be replacing it with what
appears to be an "assessment of the identity" as provided by someone
else. Hence their references to i=[email-masked], i=[email-masked], etc. This
is contrary to the spec.

I fully expect the i= value, if it is present, to represent the identity
of that user/agent. If a signer does not >>know<< the identity of that
agent, I don't expect there to be a value for i=. If you don't >>know<<
the user/agent identity, you cannot and must not put in a value for i=.
If all you have is a gut feeling for the user/agent identity, you cannot
and must not put in a value for i=. If you're a mail relayer, or a mail
gateway, you cannot and must not put in a value for i=.

The i= value can be opaque, but if it is present, most certainly is not
irrelevant.

	Tony Hansen
	[email-masked]

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 27 Jan 2009 23:02:54 +0530

> else. Hence their references to i=[email-masked], i=[email-masked], etc. This

In practice it ends up as "aggregation of a set of identities" to
arrive at a usable / finite quantity for ISPs signing good, bad and
ugly i=.  And for senders it can be i=identity by all means, hopefully
for a finite value of i

But for legitimate senders (or even ISPs with decent control of their
mail systems including smtp auth) there's no reason to doubt the
identity of the user/agent and multiple different ways to authenticate
it (such as dkim signing the headers) - so i= for that purpose is
moot.

And for any large mail system (sender or receiver) the potential
values of i= tend to be very large indeed, large enough to make them
unusable at the receiving side unless aggregated to some extent and
layered with a reputaiton model.

And it is the reputation model that's the bone of contention.  A lot
of senders appear to be under the impression that if they publish i=
for individual clients of theirs, the bad reputation of one or more
clients they have will not taint the reputations of other clients they
host in a shared mail stream.

>From a receivers perspective .. if that does happen, it is constrained
within the limits of d= = sum(i=) and one or more clients with a
sufficiently bad reputation will wipe out the good reputation of the
other clients, especially when these are sent from adjoining IPs / the
same CIDR.

I am only sorry I participated in this discussion so late .. most of
the discussion on the MAAWG mailing lists over the last several months
hasnt shown me where too many receivers are fans of i=, except for the
use case described above and some other corner cases.

srs

---

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

>   2.  Add text about the use of i= stating that its use for assessment goes 

This agrees with my understanding, too.  The i= may have to be an
identity, but nothing says the identity has to be meaningful to anyone
other than the signer.

Regards,

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 27 Jan 2009 23:11:29 +0530

> identity, but nothing says the identity has to be meaningful to anyone

In which case either the errata doc or the -bis rfc has to introduce a
"MAY" for i= being an identity instead of tying the two together and
effectively excluding the most common uses to which i= will be put.

srs

---

From: "Adkins, Michael" <[email-masked]>
Date: Tue, 27 Jan 2009 12:44:54 -0500

I don't think I've made any such specific reference, since I agree that
the examples you give are contrary to the definition in the spec.

It is already common practice for operators to segment their outbound
traffic to avoid filtering issues.  I expect them to apply similar
segmentations with DKIM.

The exact manner in which they should do that is what we need to agree
on.

If I choose to segment my signing based on my own assessment of the
user, as I do now with outbound ip addresses, then I would probably make
that a subdomain in d= (d=assessment.example.com).  If I also choose to
specify an i= value, then that segmentation will spill over giving us
something like i=[email-masked].  If my assessment of that
user changes, then the i= value will change as well.  So, i= does
contain the identity of the user but is not necessarily a stable value.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tony Hansen
Sent: Tuesday, January 27, 2009 12:13 PM
Cc: DKIM IETF WG
Subject: Re: [ietf-dkim] draft Errata on RFC 4871

	Tony Hansen
	[email-masked]

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 27 Jan 2009 09:46:42 -0800

> effectively excluding the most common uses to which i= will be put.

Interesting.  The key point I'm hearing is that having i= represent the identity 
of an (individual) user makes it inappropriate to use for identifying a mail 
stream, that is, aggregate traffic.

d/

-- 

   Dave Crocker

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 27 Jan 2009 10:47:25 -0700

> gateway, you cannot and must not put in a value for i=.

I think you may have landed on the core question (whew!)  Is the i= value:

1. a single identity, or
2. a free-form identifier?

If the receive-side use case is to filter out mail from an untrusted domain, 
then (as Suresh keeps saying) i= being anything besides the default probably 
won't be very useful at all.  Same story when the entire domain is trusted.

If the receive-side use case is to filter or prioritize different mail 
streams or mail types within a single domain (such as transactional vs. 
marketing vs. corporate, or the various customers of an ESP), i= can be 
treated as a stable but opaque identifier.  This also works for the AOL idea 
of lumping especially trusted users into one identifier & especially 
untrusted users into another.

If the receive-side use case is to prioritize mail from trusted individuals 
within an untrusted domain (Grandma using a big ISP), or untrusted 
individuals within a trusted domain (spammer using a big ISP), i= MUST a 
single, stable identity, equivalent to the individual user ID.

What are the other cases we've all been talking past?  Are there 
sending-side use cases which vary dramatically from the above?

-- 
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: "J.D. Falk" <[email-masked]>
Date: Tue, 27 Jan 2009 10:29:13 -0700

> Does this reflect what you two are implying?

I also think that makes sense.

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 27 Jan 2009 10:23:58 -0700

Suresh Ramasubramanian wrote:
> message is, frankly, irrelevant.

It's irrelevant for purposes of spam filtering, but not for the equally 
valid purpose of "is this message really from my grandma?"

(Or, more accurately, "is this message really from my grandma's email address?")

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 27 Jan 2009 10:25:36 -0800

Adkins, Michael wrote:
> something like i=[email-masked].  

The challenge, here, is not to constrain the choices too far.  Different 
senders/signers do, and will, have different schemes.  The spec needs to support 
them all, in a way that is compatible and interoperable.

Typically, that sort of exercise reduces down to standardizing where the value 
occurs, but has only a modest limitation on the schemes for generating the 
value, in order to support many different schemes.

d/
-- 

   Dave Crocker

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Wed, 28 Jan 2009 00:00:21 +0530

> (Or, more accurately, "is this message really from my grandma's email address?")

1. Does her grandson run mailops at the receiver ISP?

2. Does the receiver ISP make finegrained control based on dkim sigs
part of the client experience for the user?  Webmail possibly but from
a toolbar?  And how do they stop it being gamed, how do they keep
state for millions of accounts, and then keep changing things around
when grandsom breaks up with one girlfriend, suddenly decides another
dude is a twit etc?

That's not layering trust as much as it becomes a gigantic social
networking site based on dkim, scaled large enough

--srs

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Wed, 28 Jan 2009 00:04:17 +0530

And assuming you tie client side whitelists to dkim i= ..

1. smtp auth is already a best practice and it's hardly likely you'd
find dkim deployers who dont already deploy AUTH, or run webmail
systems where you cant change the return path / if you can change it,
your actual user account gets stamped somewhere else (a Sender:
header, a X-Actual-User: cleartext or hashed header, etc)

2. DKIM signs all the headers and validation of that hash tends to be
useful to verify grandma is who she is.  Or at least its her, or its
comrade botmaster who's just taken over grandma's PC.

--srs

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 27 Jan 2009 10:46:23 -0800

> comrade botmaster who's just taken over grandma's PC.

This is a common misunderstanding of DKIM:

1. DKIM doesn't have to sign all the header fields.

2. Independent of how much or little it signs, a DKIM signature does not mean 
that any of the content is "valid", merely that data integrity has been 
maintained.  In particular, there is nothing that says that the author field 
accurately states who created the message.

What is delivered can be verified as what was sent.  But what was sent is still 
free to be incorrect.

d/
-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Tue, 27 Jan 2009 10:46:58 -0800

At 07:05 27-01-2009, Dave CROCKER wrote:
>That section also does not tie the term to a particular tag.  So 
>what is the problem with not changing the section?

In Section 4 of the draft, the UAID is defined as a value which 
identifies the user or agent.  In Section 5, it is specified that the 
UAID must be the value of the i= tag.  In Section 7, the corrected 
text says that i= The responsible User Agent Identifier.

Section 3.5 of RFC 4871 mentions that the d= must be the same or or a 
parent domain of the "i=" tag (the signing identity, as described below).

There is a tie to a particular tag.  If you amend Section 3.5, then I 
cannot tell whether the Signing Identity in Section 1.1 (RFC 4871) 
refers to the Signing Domain identifier or the User Agent 
Identifier.  The draft discusses about the relationship between the 
two new identifiers.  It introduces an Identity Assessor which is 
primarily consuming the Signing Domain Identifier.  Some people may 
read that as the Signing Identity in Section 1.1 (RFC 4871) is the 
de-facto Signing Domain Identifier.

The reason we are having this discussion is because of a confusion 
about "identities".  What may be clear to you and the rest of the WG 
might not be so for implementors who have not been part of the 
WG.  RFC 4871 is on the Standards Track.  That document or its 
successors will be around for quite some time if DKIM is widely 
deployed.  If the goal is to get a technical specification published, 
then we can choose the easy route.  If it is is to create a standard, 
then things like this may be a problem at some point in future.

>The proposed errata changes the text.  So I'm not understanding what 
>point you are making here.

The point I am making is that d= was not defined as an identity which 
is why some people favor i= over d=.  Your text changes it to an 
identifier and by extension an identity as it is consumed by the 
Identity Assessor.

>I don't understand.

In my opinion if the changes after a document has been published 
introduce new definitions and establish relationships, it is not 
clear on whether it can be approved as an errata.

I'm posting the following for the record.

There was a discussion about d= and i= tags when DKIM was 
drafted.  It was viewed that in the absence of an i= tag, the d= tag 
is implicitly taken as the "identity".  The i= tag might be used to 
perform a fine grained assessment.  For example, I may decide not to 
give all DKIM signed mail from a large ESP the same way "weight" by 
assessing identities instead of the entire domain.  That method may 
not scale.  Some people will go for the d= tag as it's easier to manage.

In a previous message I mentioned the g= tag and its relationship 
with the signing identity (i=).  Section B.1.1. (the text is 
informational) elaborates on how it can be used to facilitate 
restricted authorization.  It even mentions that a specific From 
header field Local-part can be authorized.

I understand that the identity from i= is opaque and it is not 
required to match
the identity in any message header fields.  If the identity is 
stable, a verifier could implement a policy to identify that 
"source".  This can be useful if we are thinking in terms of "good" 
and not "bad" messages.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Tue, 27 Jan 2009 11:13:28 -0800

>that is outside the specification.

I'm commenting on item 2 because of the RFC 2119 keyword.  I don't 
see how to implement a requirement based on the additional knowledge 
as it may fall under local policy unless there is a mechanism for the 
sender and receiver to exchange that information.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 27 Jan 2009 11:23:03 -0800

Jim,

Jim Fenton wrote:
>>    1. 1399 received no substantive discussion and was then declared
>> redundant with 1519.  So citing it winds up confusing the current
>> discussion.
> 
> Issue 1399 was open for over 4 months, surely enough time for anyone who
> wished to comment to do so.  If there is a requirement for a specific
> amount of substantive discussion on an issue, please cite it.

Since 1399 has no discussion of i= vs. d=, and since it was declared redundant 
with 1519, the issue is moot.  It's irrelevant to the current discussion.

>>    2. 1519 had nothing to do with the choice between d= vs. i=.  It
>> asked a very different question about i=.
>>
>>    3. One could argue that all discussion "assumed" i=, but that's a
>> very different claim that one that says we considered d= vs. i= and
>> chose i=.
> 
> In message http://mipassoc.org/pipermail/ietf-dkim/2008q3/010582.html ,
> Stephen summarizes the issues around issue 1519 well, notes that the
> draft includes matching the local-part of i=, and invites further
> discussion.  There was none, so the issue was closed about 10 days
> later.  Since d= does not have a local-part, it would not seem that it
> qualifies.

You think that failing to discuss an topic that was outside the scope of the 
cited issue and, in fact, was not raised then, is somehow relevant to the 
current discussion?  I don't understand that logic.

More importantly, it seems a distraction from the current discussion:  There is 
a real problem and it needs real resolution that the current specification does 
not provide.

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Tue, 27 Jan 2009 10:58:23 -0800

Dave CROCKER wrote:
> Unfortunately your presenting citations raises the question of whether
> they resolve the current question.  My own conclusion is that they do
> not, for several reasons:
>

-Jim

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 27 Jan 2009 12:44:45 -0700

> 1. Does her grandson run mailops at the receiver ISP?

It's possible, but I don't think it matters.

> part of the client experience for the user?

Sure, why not?  The end user doesn't have to understand DKIM any more than 
they currently understand headers.

 > And how do they stop it being gamed, how do they keep

With something like DKIM providing a stable, authentic identifier, all that 
stuff is (clearly) difficult.  But if they continue to rely solely on the 
From: header, it's basically impossible.

> networking site based on dkim, scaled large enough

Exactly!  A number of mail systems have already started experimenting with a 
social inbox -- both filtering and display concepts -- while at the same 
time, a number of social networks are already leaning towards traditional 
internetwork email.  It's inevitable.

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 27 Jan 2009 12:51:48 -0700

> What is delivered can be verified as what was sent.  But what was sent is still 

With DKIM i=, it becomes possible to convey a stable identifier (though of 
course there's no guarantee that the identifier is stable, leading to John's 
t= suggestion.)  Without DKIM (or something like it), as we know, any 
potential identifiers are trivially forged.

As Suresh pointed out, DKIM doesn't convey anything about who is using 
Grandma's login credentials (in the case where Grandma's login credentials 
can be associated with a stable, authenticatable identifier), but I'd say 
that's out of scope here.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 27 Jan 2009 11:58:22 -0800

JD,

I fear you missed my point:

      "Identity of the user or agent (e.g., a mailing list manager) on
      behalf of which this message is signed"

does not mean that that user or agent was the author.  So the value might be 
wonderfully stable, but its semantics say nothing about authorship.

To repeat:

      There is nothing in DKIM that says or implies that it makes
      an assertion of valid From: field data.

Any use of DKIM for validation of From: field contents goes beyond the base 
specification.  For example, ADSP travels that path.

d/

-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Tue, 27 Jan 2009 11:55:08 -0800

> networking site based on dkim, scaled large enough

Exactly. And that's something that's already demonstrated to scale
and be useful. Merging that functionality into (a large subset of) email
is almost inevitable, I think.

Cheers,
   Steve

---

From: Jon Callas <[email-masked]>
Date: Tue, 27 Jan 2009 13:21:51 -0800

> potential identifiers are trivially forged.

I want to point out as well that a stable identifier doesn't have to  
be a field in the DKIM header.

It's trivial to make a new header for the stable identifier and have  
that be in the list of headers signed.

I believe that this is even a *better* solution than trying to make i=  
be something that it is and cannot be, and better than adding in a new  
DKIM option.

That DKIM-base allows, supports, and encourages a way to have  
additional headers that are signed is a major feature. We should  
encourage it.

	Jon

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Wed, 28 Jan 2009 06:56:43 +0530

Doesnt have to sign *all* - but some key fields like an authenticator
and/or received headers that stamp Received: from (foo@localhost) say
are certainly going to make sense to sign.

My concern was that we are reinventing the wheel a lot when we use i=
as a substitute for these other headers, when it can be used for a
rather different and more useful purpose.

Yes I know dkim doesnt validate content .. grandma v/s botmaster is
reputation hijack, an entirely different kettle of fish and not
germane here.

--srs

On Wed, Jan 28, 2009 at 12:16 AM, Dave CROCKER <[email-masked]> wrote:
> 2. Independent of how much or little it signs, a DKIM signature does not
> mean that any of the content is "valid", merely that data integrity has been
> What is delivered can be verified as what was sent.  But what was sent is
> still free to be incorrect.
>
> d/
> --
>
>  Dave Crocker

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Wed, 28 Jan 2009 07:02:23 +0530

> is almost inevitable, I think.

Social networking is all very good. But you dont get the goal of a
stable authenticator there.

A kid's opinions may not - heck, will not - keep pace with his
regularly updating his trust levels. And then there are the lion /
toplinked.com type people in linkedin who go around building networks
just for my network is bigger than yours, and a consequently diluted
trust model if you layer in reputation rather than simply a pgp style
web of trust.

That way lies madness, and is certainly way out of scope for the dkim
spec but hell, as we are already this far afield ...

--srs

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 28 Jan 2009 12:37:04 +0100

<wearing AD hat>

I think the proposed text changes would make RFC 4871 significantly
easier to understand, and less prone to multiple interpretations.
(I don't have a strong opinion about the content, though -- but
a clear spec is better than an ambiguous one.)

However, it seems we're not just fixing simple errors in the wording,
but adding new design that was... well, somewhat underspecified in
RFC 4871, or at the very least, not well understood at the time (or
understood in different ways by different folks).

That probably goes a bit beyond what should be changed using errata,
and I would suggest doing 4871bis instead.  If there's rough consensus
about the content, I think it'd be possible to get it published as RFC
relatively quickly (say, well before the summer).

(Nonetheless, for discussing what needs to be fixed in RFC 4871, a
draft containing only the changes, like draft-ietf-dkim-rfc4871-errata,
is probably quite useful. Merging the changes to produce a 4871bis draft
can happen also after we've reached rough consensus on them.)

Best regards,
Pasi

> [mailto:[email-masked]] On Behalf Of ext Dave CROCKER
> Sent: 26 January, 2009 09:24
> To: DKIM IETF WG; DKIM IETF WG
> Subject: [ietf-dkim] draft Errata on RFC 4871
>
> Folks,
>
> Howdy.
>

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Wed, 28 Jan 2009 18:23:14 +0530

> can happen also after we've reached rough consensus on them.)

To begin with, might be useful to post a revised -errata draft,
there'll be quite a few changes from the original now after all this
discussion.

thanks
suresh

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 28 Jan 2009 05:48:17 -0800

Pasi,

> relatively quickly (say, well before the summer).

Pasi,

Please reconsider your suggestion.

This Errata effort developed out of real and immediate community need.  Your 
opening comment indicates an understanding that the problem does exist.  In 
other words, it does fix a specific, actual problem with the current 
specification, and that's what Errata are for.  If you know of documentation 
that specifies a limit on the scope of an Errata (erratum?), please point to it, 
because I could not find one.  We should not invent one on the fly.

Coupling the publication fate of this one, specific change with an a 
substantially larger -- and potentially much larger -- set of additional changes 
ensures a delay of months, where 6 months is optimistic.  Adding arbitrary delay 
to the publication of an approved Errata note is not helpful for community need.

The specific clarification being attempted by the current draft Errata is needed 
now, not months from now.

d/

ps. Independent of the formal IETF publication barriers that we encounter, the 
working group can still resolve the current topic, by formulating working group 
consensus, and then post it to the dkim.org web page.  That's not the same as 
formal IETF publication but can still declare it for community use.

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 28 Jan 2009 06:12:48 -0800

> and/or received headers that stamp Received: from (foo@localhost) say
...
> reputation hijack, an entirely different kettle of fish and not

My point was more basic than whether the signer can be subverted.

My point is that DKIM semantics do not include a statement about the 
truthfulness of *any* message data, except the d= and probably the i= tags in 
the DKIM-Signature: field.

It provides data integrity, for the portions covered by the hash, and it 
authenticates the asserted "signing identity".  It does *not* assert 
authorization of the From: field.

Given the community tendency to make assumptions about DKIM that aren't in the 
specification, this really is worth being extremely careful about.

d/
-- 

   Dave Crocker

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Wed, 28 Jan 2009 19:55:27 +0530

> authorization of the From: field.

Unless the from field is signed .. and perhaps this is appropriate in
quite a few scenarios.

Even in cases where the from is not changeable by the end user (in a
webmail client, or corporate mail system) and is therefore yet another
header that is subject to signing?  And does this go for other
alternatives such as Sender: where the envelope sender is inserted
where header from differs from envelope from?

> Given the community tendency to make assumptions about DKIM that aren't in
> the specification, this really is worth being extremely careful about.

That's one more reason for a use case document.

thanks
suresh

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 28 Jan 2009 06:35:59 -0800

> Unless the from field is signed .. and perhaps this is appropriate in

NO NO NO NO NO!!!  A thousand times NOOOOOOO!!!!!

Including the From: field in the DKIM hash does *not* carry the semantic that it 
has valid content!!!!!

Simple example:

      Mail sent through mipassoc.org, such as this DKIM wg mailing list message, 
  are signed by my ISP.  I guarantee you that the ISP does not evaluate whether 
the From: field is authorized to be used by the author.  All that a DKIM 
signature means is that the "signing identity" -- in this case, mipassoc.org, 
which has nothing to do with the author -- is taking some responsibility for the 
message.  And the nature and degree of that responsibility is intentional left 
unstated.

      That's massively different from saying that particular portions of the 
message are "correct".

d/
-- 

   Dave Crocker

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Wed, 28 Jan 2009 20:18:03 +0530

On Wed, Jan 28, 2009 at 8:05 PM, Dave CROCKER <[email-masked]> wrote:
> Including the From: field in the DKIM hash does *not* carry the semantic
> that it has valid content!!!!!

As I said .. in certain cases. The other alternative being some other
field (such as a received header with smtp authentication data) that
does get signed.

>     Mail sent through mipassoc.org, such as this DKIM wg mailing list
> message,  are signed by my ISP.  I guarantee you that the ISP does not

Send email through our webmail after having logged into your webmail
account with us, an you can't change the from field.  Then?

--srs

---

From: Michael Adkins <[email-masked]>
Date: Wed, 28 Jan 2009 10:28:38 -0500

Siegel, Ellen wrote:
> Interesting. This model would seem to break down, or at least get complicated, in cases where i= values are supposed to match email addresses... presumably the "assessment" part of the d=domain would not be visible in the actual email address, or it would require major changes to migrate users from one bucket ("assessment" subdomain) to another.
>
> Does that mean you're implicitly assuming that there's no direct link between the d= (or i=) domain and the email address?
>
> Ellen
>
>   
There isn't. We host mail for numerous domains, but we're planning to 
sign all of it as d=assessment.aol.com for the reasons Suresh mentioned 
(same use policies, filtering, etc.). Plus, a single user identity in my 
system can have multiple email addresses associated with it, so it makes 
more sense (in my mind at least) to set i=[email-masked] 
instead of i=[email-masked]. For example, a single 
dial-up customer can have up to seven mailboxes at a time but there's 
still only one responsible identity for the account. I believe broadband 
access providers have similar setups.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tony Hansen <[email-masked]>
Date: Wed, 28 Jan 2009 10:51:27 -0500

Michael Adkins wrote:
>> Interesting. This model would seem to break down, or at least get
>> complicated, in cases where i= values are supposed to match email
>> addresses... presumably the "assessment" part of the d=domain would
>> not be visible in the actual email address, or it would require major
>> changes to migrate users from one bucket ("assessment" subdomain) to
>> another.
>>
>> Does that mean you're implicitly assuming that there's no direct link
>> between the d= (or i=) domain and the email address?
>>
>> Ellen
>>
>>   

This looks just fine to me. By using the user_id, you're satisfying the
semantics of

and still maintains the uniqueness of that identity.

I don't think this is the same as what Suresh was describing, though. He
was talking about using assessment labels for the i= value, such as
[email-masked], rather than a value directly linked to the
known user/agent.

	Tony Hansen
	[email-masked]

---

From: Michael Adkins <[email-masked]>
Date: Wed, 28 Jan 2009 11:00:57 -0500

> [email-masked], rather than a value directly linked to the

And in all fairness to Suresh, I probably did initially describe the 
idea to him as using i= for the assessment at some meeting in the last 
year or so, but have since changed my mind on the implementation details.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 28 Jan 2009 08:15:08 -0800

Suresh Ramasubramanian wrote:
> As I said .. in certain cases. 
...
> account with us, an you can't change the from field.  Then?

There is a difference between what semantics a particular signer has for their 
selection and use of signatures, versus what the standardized protocol conveys.

The signer might choose to sign only those messages that are created by authors 
with blue eyes, or that contain the word "fickle", but there is nothing in the 
DKIM base protocol that communicates this to the message validator or the 
message assessor.

There are exactly two bits of semantic information in a DKIM signature:

1.  The portion covered by the hash is the same as it was at the time the hash 
was computed.

2.  The d= field is being used by someone who has obtained the private key for 
that domain name.  This is the mechanical definition that DKIM uses for "taking 
some responsibility" for the message.

d/

-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 28 Jan 2009 17:07:03 -0000

>As I said .. in certain cases.

No, in no cases.  None whatsoever.  All a signed From: field tells you
is that it had the same content when it was signed as when you checked
the signature.

You may well have opinions about the utility of a particular signer's
signature, and you might have an external reputation system that says
"foo.com only signs From: headers that they believe" but that is
external to DKIM.  If a mail manager as sophisticated as you has
trouble understanding the layering of DKIM, we're going to have
horrible problems explaining it to the masses.

> The other alternative being some other field (such as a received
>header with smtp authentication data) that does get signed.

If you want a signature that identifies the individual user, there's
S/MIME and PGP.

It's clear that it might be useful to have add-ons to DKIM that
provide more complex semantics, and "signer validates From: address"
would be a reasonable one, but as it stands, the only common semantics
among DKIM signatures is "I signed this message".

R's,
John

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Wed, 28 Jan 2009 23:33:46 +0530

> horrible problems explaining it to the masses.

I do understand that point. But I must confess that I made it to see
how far we can take this idea ..

It does seem, on the surface, functionally equivalent to some
statements that "i=" can be used to establish that its grandma sending
out email, with complex, almost social networking like reputation
models layered on top.  I'm just trying to reductio ad absurdum one
assertion or the other.

> If you want a signature that identifies the individual user, there's

Instead of i=?  In situations described where "author of the message"
= "user" = "grandma"?

--srs

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 28 Jan 2009 10:15:22 -0800

> Instead of i=?  In situations described where "author of the message"

An ISP signs "on behalf of" the owner of a mailing list.  While many different 
d=/i= values could satisfy this, let's say that this particular operator chooses 
something like:

    d=  paying-users.this-isp.example

    i=  [email-masked].

The From: field, of course, is something like:

    From:  [email-masked].

So, how is a receiving assessment module supposed to know whether your scheme is 
in force or the one I've described here, or the one John uses, or the one...?

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 Jan 2009 12:41:55 -0500

Hi,

I don't know if am repeating anything here, but from my standpoint, 
there are two different parts here:

   1) Transparent Verification at the receiver,
   2) Presentation, if any, to the user.

I believe the latter is still unresolved here.

But the verification part needs to be settled first regardless of the 
presentation methods. This is the part that needs to get resolved 
before we can even consider implementation.

 From that standpoint, the 'i=' attribute is meta information, opaque 
in nature and unrelated to the verification, at least that is what I 
am assuming was the case and continues to be the case.

Our implementation plan has always been is to do policy checking 
first, DKIM validation second, using Failure Analysis as a key method 
for automated rejecting.

Although the ADSP has replaced SSP, the logic was outlined in the 
deprecated I-D:

http://www.isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html

In short, I am hoping that protocol consistency can be resolved among 
the discussions here related to this i= meta data.

-- 
Sincerely

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

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 28 Jan 2009 12:59:07 -0700

> be something that it is and cannot be, and better than adding in a new 

Right, of course...I think I've now come (back?) around to this idea...at 
the very least, as the rest of this thread shows, we need a lot more 
discussion & experimentation around the idea of a stable(-ish) 
individual(-ish) identifier.

But since so many people passionately want a stable individual identifier, 
it seems we're going to need to clarify language in a bunch of places.

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 28 Jan 2009 13:06:56 -0700

> access providers have similar setups.

Aha!  That's a sending-side use case that's clearly different from the 
receive-side use cases I listed yesterday.

That kind of signing would prevent using i= for social networking, because 
even if Grandma pays for the account (and thus the user_id roughly 
identifies her), drunken Uncle Ernie lives in the basement and sponges off 
her AOL subscription, and they'd both have the same i= value.

---

From: "John R. Levine" <[email-masked]>
Date: Wed, 28 Jan 2009 20:09:36 +0000 (GMT)

> out email

Then we desperately need to rewrite whatever part of 4871 leads anyone to 
that erroneous conclusion.  Anything that suggests in any way that i= has 
any connection to grandma's address needs to be stamped out, and stamped 
out now.

> Instead of i=?

Gee, how many ways are there to say that i= doesn't identify the user?
The i= field doesn't do that.  DKIM doesn't identify individuals, only 
domains.

> In situations described where "author of the message"
> = "user" = "grandma"?

We have two IETF standard signing schemes to identify individual mail 
authors, S/MIME and PGP.  Take your pick.  But please note that that list 
does not include DKIM.

Really, we understand that there are situations where it would be nice to 
know the exact identity of the individual person pushing the Send button. 
But DKIM doesn't do that.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 Jan 2009 13:52:04 -0700

On Jan 26, 2009, at 9:10 PM, Suresh Ramasubramanian wrote:
>
> They represent something more useful in such a context - an  
> aggregated identity that helps distinguish reputation in a more fine  
> grained way than simply d=largeisp.com .. while not going to the  
> ridiculous lengths that several million different values of i= would  
> take this line of reasoning.

There will be work involved when dealing with opaque i= values when  
assessing reputations.  Any amount of consolidation of this  
information will induce a higher degree of collateral blocking.  It  
seems best to keep this an opaque value that the sender fully controls.

Those providing or assessing reputations have the task of isolating i=  
identifiers currently being abusive.  This effort will likely use a  
temporal set of bad actors within the domain.  Providing reputation  
based upon an opaque value is much safer that using a mail-box address  
not easily changed once a problem has been corrected to the  
satisfaction of the signer.   The finer grain the resolution the  
better, however for larger domains, this value may represent an  
account and not a specific email address. This might be the value used  
to index the account granted access.  Not allowing a fine grain i=  
value will inhibit any practical means to deal with replay abuse, once  
the DKIM domain becomes the basis for acceptance.

The ADSP draft failed to understand the how i= might be used, and  
prevents its practical application.

-Doug

---

From: John Levine <[email-masked]>
Date: 28 Jan 2009 23:53:25 -0000

>That kind of signing would prevent using i= for social networking,
>because even if Grandma pays for the account (and thus the user_id
>roughly identifies her), drunken Uncle Ernie lives in the basement
>and sponges off her AOL subscription, and they'd both have the same
>i= value.

But as you have surely seen, that happens even with a single mailbox
with a single address.  A fair amount of the correspondence my 12 year
old daughter exchanges with her classmates comes from what is clearly
a parent's address shared by the kid.  On my church mailing list,
there are plenty of addresses shared by husband and wife.

When an ISP provides multiple addresses there's no way for the ISP to
know whether they're Grandma and Ernie, or one address is Grandma's
address for the church potluck mailing list and the other is the one
for her leather'n'whips* list.  All the ISP knows is that whoever knows
Grandma's password controls all of her addresses, so as far as they
can tell, it's one identity.

On the other hand, as we get more extensive experience with DKIM, it
seems inevitable to me that we'll build up categories of useful
information that we can deduce from known signers.  For example, AOL
and Outblaze prevent their users from modifying the From: line, so you
know that if one of them signed a message, the From: address is a
stable identifier.  Yahoo might put one signature on their free web
mail, another signature on the paid ISP mail from Sympatico and BT,
and a third on employee mail, each using an i= that is stable per
signup or per employee.

It's not going to be as simple as some people would evidently like it to
be (in particular, i= will never be a reliable e-mail address), but DKIM
is a great tool on which we can build all sorts of useful identity and
reputation management stuff.

Now let's see if we can clarify once and for all that d= is the
identifier, and i= only means what the signer wants it to mean, so you
can only interpret it to the extent you recognize the signer.

R's,
John

* - Grandma's hobby is driving her horse cart, you pervert.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 28 Jan 2009 15:53:46 -0800

> The i= field doesn't do that.  DKIM doesn't identify individuals, only 

John,

Oh boy.

Your statement is not correct.

The spec says that it *does* identify a user.

    It does not say the identification is an email address.

    It does not say that the user is the author.

    It does not say that anyone other that the creator of the identification can 
parse and comprehend the identifier.

But it does say that it is the user who the signing was done "on behalf of".

d/

-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Wed, 28 Jan 2009 16:16:17 -0800

> additional headers that are signed is a major feature. We should  

+1.  DKIM-base also allows new tag/value pairs to be added to the
DKIM-Signature header field, so if somebody wants to define a tag for a
stable identifier to be used as a hint to reputation systems, that can
be done as an alternative to defining a new header field for this
purpose.  This has the advantage that there's no confusion if there are
multiple DKIM signatures, there isn't confusion about which stable
identifier header field goes with which signature.

Note that I say this is a hint to reputation systems:  Nobody can
prevent a reputation from using, or trying to use domain only, and one
can't require that the reputation system will actually pay attention to
a stable identifier, regardless of how it is expressed (in or with the
signature).  Reputation systems that do a good job will succeed, and
those that do a poor job will fail.  Note also that the stable
identifier would be effectively an additional output of DKIM verification.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 Jan 2009 16:49:05 -0800

> Your statement is not correct.

Sorry, but I agree with John on this.

> The spec says that it *does* identify a user.

Your statement is also not correct!

RFC 4871 defines the i= value as representing the identity of the  
_user_ or _agent_ on behalf of which this message is signed.

The agent involved could represent an account rather than a user.  The  
account would be the entity granted access to their outbound SMTP  
server that is acting as agent for the users sharing the account.   
This account could be expressed as a number which does not have a  
corresponding mailbox.  An agent could also be a mail-list or any  
number of abstract concept of agent entities.  You have overlooked a  
very important aspect about how access is controlled, and which entity  
on behalf  the signature was added.  The signing agent may only  
recognize the account would could be identified by the IP address  
assigned a MAC address. This could also be identified by a number  
referenced in their Radius server.  Only in some cases will there be a  
one to one correspondence between From email-addresses and on-behalf- 
of entities (i= values).

>   It does not say the identification is an email address.

Agreed.

>   It does not say that the user is the author.

Agreed.

>   It does not say that anyone other that the creator of the  
> identification can parse and comprehend the identifier.

It also does not say that the i= value represents that of a user!

> But it does say that it is the user who the signing was done "on  

Or Agent!

-Doug

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Thu, 29 Jan 2009 06:42:33 +0530

> The spec says that it *does* identify a user.

Now that I have john levine and dave crocker in disagreement on just
what i= does .. :

>> Then we desperately need to rewrite whatever part of 4871 leads anyone to that erroneous conclusion.

Right, thanks, John.

--suresh

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Thu, 29 Jan 2009 06:48:10 +0530

> identifier would be effectively an additional output of DKIM verification.

Thank you. That's even more reason for this errata doc to express the
view that i= / UAID is metadata that's useful at the sender end (both
during transmission as well as during the analysis of feedback loops,
or other self analysis) and only MAY be considered or checked by
receivers if there's a shared understanding of what it constitutes.

I would even go as far as to say that it need not necessarily be a
stable identifier of the individual author.  And attempts to find a
stable identifier might need to look elsewhere (ok, not the from .. a
brand new x-header perhaps?)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Thu, 29 Jan 2009 06:52:45 +0530

On Thu, Jan 29, 2009 at 2:22 AM, Douglas Otis <[email-masked]> wrote:
> assessing reputations.  Any amount of consolidation of this information will
> induce a higher degree of collateral blocking.  It seems best to keep this
> an opaque value that the sender fully controls.

Those opaque i= values will be of some use to the sender. I see no
reason why the receiver can't simply ignore them.

> The ADSP draft failed to understand the how i= might be used, and prevents
> its practical application.

ADSP's fatal flaw is that it is a collection of sender pipe dreams
that seek to force a complex and none too workable reputation model on
receivers, with a high potential to be gamed simply by playing with
the various permutations and combinations of d= and i= .. there is
little or no incentive for receivers to deploy it.  If that effort is
still on, might be safe to simply kill it off.

Of course there are practical applications .. at the sender side for
identification of individual authors and managing / analyzing  their
reputation.  Just please dont expect receivers to do anything at all
useful with that data e&oe previous out of band understanding between
specific senders and receivers (or groups of senders and receivers
like maawg).

--srs

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Thu, 29 Jan 2009 06:56:23 +0530

> can only interpret it to the extent you recognize the signer.

Good. Can the errata document that seeks to clarify SDID v/s UAID
please, please drive this point home?  With enough MUST NOT BE ASSUMED
type wording?

-srs

---

From: "John R. Levine" <[email-masked]>
Date: Thu, 29 Jan 2009 01:53:55 +0000 (GMT)

> The spec says that it *does* identify a user.

It says that i= is the "user or agent on behalf of which this message is
signed".  It gives the example of an agent that's a mailing list, and
we've seen all sorts of other things that people put into i=.

It's certainly true the i= might identify a user, but it's equally true 
that it might identify a piece of software, or a 'bot that cracked 
someone's CAPTCHA, and without extra info external to DKIM there's no way 
a receiver or verifier can tell which of those it was really intended to 
be.

So, really, DKIM doesn't identify individuals.

R's,
John

---

From: Al Iverson <[email-masked]>
Date: Wed, 28 Jan 2009 19:56:42 -0600

Forgive me in advance for a really basic, quite possibly dumb,
question. What does DKIM do that receivers find valuable? What does an
ISP or large corporate receiving entity hope to get out of DKIM
adoption?

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: Suresh Ramasubramanian <[email-masked]>
Date: Thu, 29 Jan 2009 07:37:21 +0530

> ISP or large corporate receiving entity hope to get out of DKIM

Authentication + reputation of single monolithic senders (d=) - yes, valuable.

Reputation model that can be slightly more fine grained
(i=good.aol.com, bad.aol.com, ugly.aol.com) - yes valuable.

And do you forget that receivers are senders too?   My users send lots
of email to AOL / Yahoo, and their users to me.

DKIM is valuable.  d= is valuable.  As for i= - well, its quite useful
to the sending side.

--srs

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Thu, 29 Jan 2009 08:11:48 +0530

On Thu, Jan 29, 2009 at 8:03 AM, Mark Delany <[email-masked]> wrote:
>
> Colo(u)r me dumb/confused/take-your-pick, but is i= effectively the moral
> equivalent of IDENT (RFC1413)?
>

Not that I saw people trying to build a reputation model around IDENT
(thank god?), but yeah .. interesting idea.

---

From: Steve Atkins <[email-masked]>
Date: Wed, 28 Jan 2009 18:43:12 -0800

> ISP or large corporate receiving entity hope to get out of DKIM

It provides an (optional) persistent identity for senders, one that
doesn't need any updating or cross-referencing between identity
and IP address. History for those identities can be maintained
mechanically, with fairly minimal human overhead.

There's no reason that a sender/author ever has to change that identity,
so the problem of moving IP addresses doesn't arise, meaning
that the receiver doesn't have their reputation data invalidated
for no good reason on a daily basis by authors moving IP address
(or ESP) and the receiver doesn't have to deal with the manual
overhead of either supporting senders/authors who change
their source IP address or supporting customers when mail that
was being delivered fine yesterday is discarded today.

That'll allow receivers to maintain a view of the reputation of  
legitimate
senders much more reliably and at lower cost, meaning that their
users will get more of the mail they want at lower cost to the ISP,
which is good for the bottom line.

It provides all of the advantages, in a much cleaner and more
specific way, as the current use of SPF by AOL to map whitelisted
domains onto IP addresses mechanically. And it also allows those
advantages for domains that aren't big or loud enough to sign up
for whitelisting, as their reputation can be monitored by receivers
with no need for any communication between author and receiver
other than the DKIM signed messages themselves.

There are other advantages to a small subset of large receivers,
around feedback loops and suchlike, but they're gravy.

All of these advantages to the receiver could probably be provided
by something a tenth the complexity of DKIM, but that's what
seems to happen to protocols in this segment of the industry
when you make the mistake of paying too much attention to
everyones input.

Cheers,
   Steve

---

From: Mark Delany <[email-masked]>
Date: Wed, 28 Jan 2009 18:33:58 -0800

On Jan 28, 2009, at 5:22 PM, Suresh Ramasubramanian wrote:

>> information will

Colo(u)r me dumb/confused/take-your-pick, but is i= effectively the  
moral equivalent of IDENT (RFC1413)?

Mark.

---

From: Steve Atkins <[email-masked]>
Date: Wed, 28 Jan 2009 19:21:59 -0800

> moral equivalent of IDENT (RFC1413)?

That's how I've been thinking about it for a while. It's an opaque
cookie that's primarily of value to the sender when the receiver
passes it back to them in the context of a particular connection.

Some implementations leave data in that cookie that's immediately
useful ("this mail was from apache@, huh?") and some don't, and
there's no way other than human eyeballs or heuristics to guess
whether there's that data in any particular case.

Ident is pretty widely feared and misunderstood, which is
why I've never tried to use the parallel between the two. And is,
itself, another parallel I guess.

Cheers,
   Steve

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 28 Jan 2009 20:49:56 -0800

Steve Atkins wrote:
> by something a tenth the complexity of DKIM, 

Really?   Wow.

While I tend to believe that bits of the current spec weren't really necessary, 
I believe that the core mechanism is pretty lean, for the goal it has.

So I'd be interested in seeing your basis for believing that it is an order of 
magnitude more complex that it needs to be...

d/
-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Wed, 28 Jan 2009 21:44:52 -0800

On Jan 28, 2009, at 8:49 PM, Dave CROCKER wrote:

> While I tend to believe that bits of the current spec weren't really  
> necessary, I believe that the core mechanism is pretty lean, for the  
> goal it has.
>
> So I'd be interested in seeing your basis for believing that it is  
> an order of magnitude more complex that it needs to be...

Look at the current thread. Removing just i= and it's friends would  
reduce the confusion *of people who are deeply involved in the spec*  
by a large factor. It's going to be a lot worse when you start talking  
to implementors, coders, sysadmins and marketing folks. That's a good  
measure of complexity. I think that considering just "i=" and it's  
friends could get me close to an order of magnitude of unneeded  
complexity on it's own.

But there's other complexity that's been added either because someone  
thinks it might be useful some day, or because someone has an overly  
complex use case they're thinking of, one that really doesn't add much  
value to the sender or recipient. I know why a lot of this stuff was  
added, but if simplicity of spec and ease of implementation were an  
overriding goal there's an awful lot that could be removed without  
causing significant weakening of the protocol in typical usage.

Going through the spec point by point, and painting big red circles  
around each element that adds more complexity than value isn't really  
the point[1], but look and see that many of the fields are OPTIONAL or  
RECOMMENDED and have reasonable defaults. What would the spec look  
like if they all went away and were replaced by the defaults? For the  
signer it would look much the same, as they can ignore all those  
fields anyway. For the verifier it would be much, much less complex.

There's also ill-defined implementation/semantics of multiple  
signatures, though I suspect local policy will likely make the  
vagueness in spec less of an issue, and it'll probably be cleaned up  
by a best practices document eventually (if it hasn't already).

Cheers,
   Steve

[1] At least not in the body of the email. Please don't consider any  
of the following as picking a fight, or even demanding a response,  
it's mostly just for completeness.
Signature a=. Doubles the work and the QA for that section of verifier  
code, and there's no real need for it.
Signature c=. Four times the work and QA for that section of verifier  
code and maybe twice the bugs, quite apart from the additional mind  
space it takes up.
Signature l=. This adds little to no value, yet makes the analysis of  
security and evasion techniques much, much more complex, especially in  
an environment as rich in tools ripe for misuse as email is (MIME,  
HTML). The complexity this adds to a security analysis of the protocol  
as a whole is huge, for fairly small benefit. (Arguably you can reduce  
that analysis cost just by observing that senders should never use l=,  
and that doing so will likely cause security issues, but that seems to  
sidestep the point).
Signature h=. I can see why it's there for extensibility, but hard- 
wiring it would remove complexity, with only some loss of flexibility  
in use. The spec has a SHOULD list for this which would be suitable.  
(Actually, this and key n= are the two cases where I think the  
additional value *does* clearly outweigh the complexity, myself).
Signature q=. Does anyone believe that they'll see anything other than  
q=dns/txt in a signature with v=1? Again, extensibility is good, but I  
don't think there's a need for this, and should reality demonstrate  
otherwise, that's what v=2 is for. Slash it out and you reduced  
complexity a little further.
Signature t=. Anti-replay defense is nice, I guess, but this isn't  
going to be that useful in providing such a thing, and it adds  
complexity to the spec and so consumes mind space, even if a verifier  
decides to ignore it.
Signature x=. Like t=, but more so. And even if one were considered  
useful, why both?
Signature z=. I'm sure there are edge cases where it's useful, but are  
they important enough to justify the complexity they add? Key g=. More  
complexity that adds little to no value.
Key h=. Same issues as Signature a=.
Key k=. Same as Key h=.
Key s=. Extensibility is fine, but until we've got some use case (and  
experience with the default value) leave it for v=2? Key t=y. I know  
why it's there, but I'm not sure that it's justified.
Key t=s. All the same complexity vs value issues as Signature i=.
And if you, or anyone else reading this, had to think for even a  
moment about what any of those fields were, that goes some way towards  
demonstrating my point.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 29 Jan 2009 10:55:53 -0000

> because I could not find one.  We should not invent one on the fly.

This Erratum makes greater changes to the text of the document than is  
customarily the case. It is pushing the whole concept or RFC Errata right  
up to its limit, and perhaps beyond it.

Nevertheless, it MIGHT be justified in this case on the grounds that this  
clarification is required NOW, and a new draft will inevitably take time.

OTOH, it seems that this discussion has established that a new draft is  
needed. But when it comes it will undoubtedly include further  
clarifications and perhaps extensions or liberalisations (though not such  
as to breakl what is already up and running, of course).

Therefore, we really need BOTH; an Erratum NOW, with minimal but agreed  
content and a promise that a future draft will not go back on it, and  
LATER a new draft, but subject to constraints as to not undoing what is  
already agreed and understood.
> to the publication of an approved Errata note is not helpful for  

Exactly.

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

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 29 Jan 2009 15:14:07 +0100

Dave Crocker wrote:

> This Errata effort developed out of real and immediate community
> need.  Your opening comment indicates an understanding that the
> problem does exist.  In other words, it does fix a specific, actual
> problem with the current specification, and that's what Errata are
> for.  If you know of documentation that specifies a limit on the
> scope of an Errata (erratum?), please point to it, because I could
> not find one.  We should not invent one on the fly.

While considering this, I tried to find exactly such documentation,
but I did not find much.

draft-rfc-editor-errata-process-02 has the following text:

   We note that allowing technical errata is a slippery slope: there
   may be a temptation to use errata to "fix" protocol design errors,
   rather than publishing new RFCs that update the erroneous
   documents.  In general, an erratum is intended to report an error
   in a document, rather than an error in the design of the protocol
   or other entity defined in the document, but this distinction may
   be too imprecise to avoid hard choices.  For the IETF stream, these
   choices should be made by the IESG, and are discussed in their
   proposed guidelines on errata processing [IESG-Err-Proc].

The distinction isn't very precise; you could consider
rfc4871-errata-00 either an error (in this case, omission) in the
design, or an error (omission) in the document.

The IESG statement on IETF Stream errata
(http://www.ietf.org/IESG/STATEMENTS/iesg-statement-07-30-2008.txt)
has this:

   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.

This isn't much clearer, but it does suggest a possible test: if these
changes had been proposed when the document was about to be approved,
would they have been accepted?

Most reported RFC Editor errata are simple errors in the document,
where it's fairly obvious that if someone had pointed this out during
e.g. AUTH48, the text would have been fixed.

If someone had suggested the changes in rfc4871-errata-00 during
AUTH48, would they have been accepted? Or would the person proposing
them have been told "no, you're too late, maybe we can consider these
when we do 4871bis"?

I wasn't following DKIM when RFC 4871 came out, so I'm not in
very good position to guess here. But educated guesses from folks
who were around back then are welcome -- if most folks guess
this would have been accepted, I'm willing to reconsider.

> substantially larger -- and potentially much larger -- set of
> additional changes ensures a delay of months, where 6 months is
> optimistic.  Adding arbitrary delay to the publication of an
> approved Errata note is not helpful for community need.
>
> The specific clarification being attempted by the current draft
> Errata is needed now, not months from now.

Right -- but if it's a change that probably doesn't reflect community
consensus at the time when RFC 4871 was approved, it needs to go
through the process.

We could craft the charter text on 4871bis to specifically include
only the errata reported to RFC Editor as of today, plus the things in
rfc4871-errata-00 -- and exclude everything else. It would still take
some months, but I think less than six.

> ps. Independent of the formal IETF publication barriers that we
> encounter, the working group can still resolve the current topic, by
> formulating working group consensus, and then post it to the
> dkim.org web page.  That's not the same as formal IETF publication
> but can still declare it for community use.

Yes, I think this could be indeed valuable. You could e.g. do a WGLC
for the rfc4871-errata draft, reach rough DKIM WG consensus on that,
and post a statement saying so. That's not the same as IETF consensus,
but probably a good working assumption while 4871bis goes through
the process.

Best regards,
Pasi

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 Jan 2009 09:36:25 -0800

On Jan 28, 2009, at 6:41 PM, Suresh Ramasubramanian wrote:

> Not that I saw people trying to build a reputation model around  
> IDENT (thank god?), but yeah .. interesting idea.

Building a reputation model around DKIM creates concerns related to  
replay abuse.  DKIM's signature time constraint will not mitigate the  
replay concern either.  When there are problematic accounts,  a  
reputation service could add a secondary query to mitigate problematic  
and non-rate-limited accounts of the larger domains within minutes of  
detection.  When the number of problematic accounts becomes too large,  
rejecting at the initial query may become necessary.

Today, malware, that morphs within 7 hours, is distributed through  
exponentially growing botnets where new threats are generated every  
few seconds.  A signature distribution scheme is unable pace with this  
problem.  For malware, this is especially true since reversible  
signatures can intentionally collide with essential files.  Even so,  
it would be ill considered to expect a mitigation effort based upon  
the DKIM signature can endure the torrent of signatures already being  
generated by the spam emitted from these large domains.  The numbers  
would be daunting to support for just one large domain, without  
considering the thousands of such domains.

When a signing domain accurately, even opaquely, indicates the on- 
behalf-of entity within the DKIM signature, this dramatically reduces  
the size of the problem.  Such a reputation model will be expensive,  
so it better have a chance to scale to the problem at hand.

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 29 Jan 2009 11:39:38 -0600

...

Pasi,

First, many thanks for such a thorough and helpful response.

The idea of considering "what would have been consensus at the time the working 
group was developing the spec" is an interesting.  Given that most groups have 
trouble figuring out what consensus is at the time it is happening, trying to 
guess what would have been consensus a year or two in the past is quite a challenge.

I suggest that trying to assess consensus *now* is a more tractable exercise.

> some months, but I think less than six.

Except that the last few days of discussion seem to be raising quite an array of 
items that seem relevant to a revision effort, and substantial.  This does not 
bode well for a quick effort.

> but probably a good working assumption while 4871bis goes through

Hmmm.  I guess I hadn't realized that getting Errata posted as being "approved" 
required a full IETF process.

If the Errata could be posted with the RFC Editor as "approved by the working 
group" that might suffice, for the quick effort.

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 29 Jan 2009 11:59:53 -0600

Folks,

Given how far-ranging discussion has gotten, it's probably worth taking a moment 
and getting a sense of the group about the original issue, namely:

      What are the group's thoughts on the draft Errata that
      has been submitted to the group?  Is there consensus?

If you like it in it current form, it would help to see a +1.

If you believe the current base specification does not need any changes for the 
concern that the draft Errata pursue, then it would help to see a -1.

If you believe an Errata of this type would be helpful but that the current 
draft is insufficient, it would help to see your suggestions for *specific 
changes* to it.

(I think that covers the range of plausible responses.  If you hold a position 
that does not fit within this range, please post a note that express it.)

d/
-- 

   Dave Crocker

---

From: Al Iverson <[email-masked]>
Date: Thu, 29 Jan 2009 13:23:52 -0600

> concern that the draft Errata pursue, then it would help to see a -1.

I'm reading it over closely and am positive on it overall.

If you would be so kind, would you help me understand the concept of a
UAID a bit better. It's an email address, but it can be
non-resolvable? What's a real world example of that -- in how either
an ISP or ESP would want to sign in such a way? I'm a bit cornfused.

Thanks,
Al Iverson

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 29 Jan 2009 13:35:36 -0600

> an ISP or ESP would want to sign in such a way? I'm a bit cornfused.

Al,

1. I can easily believe that the Errata text needs to be even more clear about 
this string.  Submissions to improve it are eagerly sought...

2.  It is *not* an email address, in terms of the DKIM base spec. So some 
signers well might choose to make it be an actual email address, but that's not 
something that DKIM knows (or cares) about.

3.  It is an identifier that is created by the signer, to indicate the user or 
agent that wants the signing to be done. The 'role' of this user or agent is 
unspecified; the message might not have any other reference to this user or 
agent.  (Notably this means that there is no indication that it is the author, 
and it well might not be the author.)

4.  For receivers, this string is completely opaque -- that is, uninterpretable. 
  Therefore, within the scope of the DKIM base specification, the entire i= 
string is *always* unresolvable, in that it has no syntax and no semantics, 
other than string1@string2, and string2 equals d= or is a subdomain of d=.

5.  It might be worth including the i= value, when communicating back with the 
signer; it might facilitate auditing and/or debugging.

6.  There might be special cases that allow a receiver to extract useful 
information from the string, although this is entirely outside the DKIM base 
specification.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Thu, 29 Jan 2009 15:08:40 -0500

> other than string1@string2, and string2 equals d= or is a subdomain of d=.

Keep in mind, I view this statement with inconsistent points and idea 
- makes no engineering logical sense.

You have reconfirmed there is a protocol consistency rule check here - 
the string2 syntax, format and value requirements.  In that vain, it 
is not opaque and it is interpretable and subject to a possible 100% 
legitimate verifier protocol consistency checking.

-- 
Sincerely

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

---

From: Al Iverson <[email-masked]>
Date: Thu, 29 Jan 2009 14:46:25 -0600

On Thu, Jan 29, 2009 at 1:35 PM, Dave CROCKER <[email-masked]> wrote:

> 1. I can easily believe that the Errata text needs to be even more clear
> about this string.  Submissions to improve it are eagerly sought...

I hear you. I wish I understood better, so I could contribute more usefully.

So the UAID is essentially a sender-created identifier used for
whatever purpose a sender wishes.

I think I am +1 fine with your errata. But I think from the
perspective of almost, "who cares...it's just a random sender-used
string." As an ESP, perhaps I would populate it with a client
identifier for my own purposes. But I'd be surprised if an ISP
actually cared/read the identifier.

Al

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 29 Jan 2009 13:50:57 -0700

+1

---

From: John Levine <[email-masked]>
Date: 29 Jan 2009 21:00:15 -0000

>an ISP or ESP would want to sign in such a way? I'm a bit cornfused.

See the signature on this message for an example.

R's,
John

---

From: SM <[email-masked]>
Date: Thu, 29 Jan 2009 13:08:52 -0800

Hi Pasi,
>would they have been accepted?

As someone else pointed out, the clarification may be justified 
sooner than later.  We could argue about what constitutes an 
errata.  That might be premature at this stage as the the WG Chair 
posted a question about the substance of the erratum [1].

>this would have been accepted, I'm willing to reconsider.

I suggest that the WG consider an errata that addresses the immediate 
problem while leaving the larger part of the work for a 4871bis.

>but probably a good working assumption while 4871bis goes through

The WG could also consider doing the above once there is agreement 
about the changes.

Regards,
-sm

1. http://mipassoc.org/pipermail/ietf-dkim/2009q1/010877.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 29 Jan 2009 16:15:01 -0500

> actually cared/read the identifier.

One of the concerns I always had with this group is when the party on 
the left side of the room has/had play down the potential on how 
verifiers, creatively or not, employ DKIM and simply extract the new 
level of information and run a protocol consistency check before 
applying a high overhead hash verification.

There was always a DKIM-BASE rule for i=. If used by the signer, it is 
not random, or at least not 100%.  Using Dave's format, it must 
conform to:

   i=string1@string2

where

   string1 is signer defined
   string2 MUST equals d= or is a subdomain of d=.

That is an deterministic rule which verifiers can legitimately employ 
in its implementation.  If protocol consistency can not be reached, I 
personally find no use for DKIM - or rather, it will be waste on many 
systems and such features will be ignored and/or lost for its lack of 
correctness and/or usefulness.  The last thing I would hate to see are 
DKIM signatures that are incorrectly formatted yet, hashing waste is 
done to a high degree of failure thus helping kill DKIM in the long 
run. Protocol consistency and expectations for correctness must be top 
consideration for DKIM to be successful.

It appeared to me that issue here is what is the string1 and as a 
whole, how does it apply to the entire payload, transaction or some 
post verification concept, i.e., possibly presentation to the user.

-- 
Sincerely

Hector Santos, CTO

---

From: Jon Callas <[email-masked]>
Date: Thu, 29 Jan 2009 13:28:35 -0800

> moral equivalent of IDENT (RFC1413)?

Yes.

	Jon

---

From: Al Iverson <[email-masked]>
Date: Thu, 29 Jan 2009 15:34:06 -0600

On Thu, Jan 29, 2009 at 3:14 PM, MH Michael Hammer (5304)
<[email-masked]> wrote:

> Actually, at the risk of sparking even greater flurries of electrons, it
> is not sender created, it is signer created.

Makes sense.

> Signer does not necessarily
> have to equal sender for DKIM base. This is one of the reasons I tend to
> fall into the "d=" camp.

I don't follow.

Al

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 29 Jan 2009 16:14:02 -0500

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Al Iverson
> Sent: Thursday, January 29, 2009 3:46 PM
> To: DKIM IETF WG

Actually, at the risk of sparking even greater flurries of electrons, it
is not sender created, it is signer created. Signer does not necessarily
have to equal sender for DKIM base. This is one of the reasons I tend to
fall into the "d=" camp. 

Mike

---

From: Jon Callas <[email-masked]>
Date: Thu, 29 Jan 2009 14:03:10 -0800

> design, or an error (omission) in the document.

Pasi, I think you have the answer in your text and quotation above.

Presently, we need some clarifications and minor corrections to DKIM- 
base.  They are in some cases not precisely errors, but it's good to  
have them. They're closer to corrections than to new protocol additions.

There are people who present additions to DKIM-base and want to phrase  
it as lacks in the protocol, but I disagree.

Something that we security people don't do very well is layering. But  
layering is a concept that the IETF does very well. DKIM-base is a  
basic framework for signatures on the messages. It's authentication.

All security people know that authentication alone might not be  
terribly useful -- you have to have authorization to have it really  
useful, for example. But I think we have rightly kept it out of DKIM- 
base.

What it means to be authorized to send me an email is pretty squishy.  
One facet of this is addressed in our present discussions. We're going  
to continue to debate and develop that onward into reputation systems  
and so on and so forth.

I believe that the text you quoted is the reason why we should have  
errata not a -bis document. DKIM-base *intentionally* is  
authentication only. DKIM-base *intentionally* does not say squat  
about (e.g.) i= vs d=. Whatever side you may be on all of that (and I  
believe it's clear where I stand), it shouldn't be jammed into DKIM- 
base.

An errata document can cleanly clear up a few things, and leave the  
higher-level questions for the higher levels of the as-yet incomplete  
total protocol. Creating a -bis document would tend to push things in  
the wrong direction; we need more documents that build on the base,  
not more stuff in the base document.

	Jon

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 Jan 2009 14:09:46 -0800

On Jan 29, 2009, at 1:14 PM, MH Michael Hammer (5304) wrote:

> Actually, at the risk of sparking even greater flurries of  
> electrons, it is not sender created, it is signer created.

Agreed.

> Signer does not necessarily have to equal sender for DKIM base. This  
> is one of the reasons I tend to fall into the "d=" camp.

I see DKIM as requiring a two tier check.  The first query would be to  
determine whether any resources should be expended on the entity in  
the d= value.

The second query would not directly relate to who originated the  
message (the sender).  After all, such questions are better answered  
by S/MIME and Open/PGP.  The second query might use the "i=" value to  
resolve sub-reputations within larger domains.

Without being able to pose a secondary query, an effective means to  
deal with replay abuse seems highly remote.  Many of the larger  
domains rate limit the messages that any user can send within some  
period of time.  DKIM messages that can be replayed will defeat a rate  
limiting practice that is widely used to minimize the damage that 1%  
of the accounts might be causing.

While resolving down to the "i=" value may seem like too much effort,  
this would require less resources than what is likely required to  
implement negative reputations for IPv6.

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 29 Jan 2009 16:14:34 -0600

[email-masked] wrote:
> Been trying to avoid it but .... my understanding was that i=author d=signer 
> i=foobar.coxhosted.com d=dkim.signer.coxmail.com and that was how 3rd party
> signing was going to work

1. the spec does not say that i= author.

2. a requirement that i=author renders DKIM useless for signing by any agent in 
the sequence other than the author's.  This goes entirely against the usage 
flexibility that has (always) been a goal of DKIM.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 29 Jan 2009 09:31:25 -0600

Steve Atkins wrote:
> by a large factor.

As a measure of energy, that makes sense.  I was thinking you meant technical 
details; by that measure, i= doesn't take much.  On the other hand, I suspect 
that the amount of code affected by the d=/i= confusion probably is 
disproportionately high.

> fields anyway. For the verifier it would be much, much less complex.

So it turns out that an exercise like this is often part of the work done in 
moving an IETF specification from Proposed Standard to Draft Standard:  Look for 
the features that have not gained traction and remove them from the spec.

I don't know whether DKIM is too young for such an exercise, but it might be 
worth considering.

> by a best practices document eventually (if it hasn't already).

In effect, that's an additional specification.  That is, the base spec says how 
to create and process one signature.  That's the core capability.  One can treat 
multiple signatures as an additional, follow-on concern.  I don't mean it's not 
important; merely that it's factorable.

I also note that there are others who have raised the topic.  After the current 
brouhaha settles down, it might be worth considering an additional document to 
deal with the topic.

> it's mostly just for completeness.

Very nice list and discussion of each item.

I suspect it would be worth having the 4871bis effort carefully consider each of 
your points.  On the other hand, that would guarantee that the bis effort is a 
substantial probject.

On the other hand, it could produce a substantially cleaner and simpler bit of 
technology.  As you note, that could dramatically reduce implementation and 
testing effort (and thereby dramatically increase interoperability.)

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 29 Jan 2009 17:36:58 -0600

> please, please drive this point home?  With enough MUST NOT BE ASSUMED

Sure...

Please suggest specific text to add/change in the draft Errata.

-- 

   Dave Crocker

---

From: <[email-masked]>
Date: Thu, 29 Jan 2009 17:01:47 -0500

Been trying to avoid it but ....
my understanding was that i=author d=signer
i=foobar.coxhosted.com d=dkim.signer.coxmail.com and that was how 3rd party signing was going to work

Bill Oxley
Messaging Engineer
Cox Communications, Inc
404-847-6397

-----Original Message-----
From: [email-masked] on behalf of Dave CROCKER
Sent: Wed 1/28/2009 6:53 PM
To: John R. Levine
Cc: [email-masked]
Subject: Re: [ietf-dkim] DKIM does not identify senders, and we have big semantic problems

John,

Oh boy.

d/

-- 

   Dave Crocker

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Fri, 30 Jan 2009 07:54:39 +0530

Christ.  I'd support Steve Atkins when he suggests entirely gutting
this spec to remove half the alphabet, retaining just d= and one or
two others (i= with caveats, t= I dare say)?

suresh

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 30 Jan 2009 12:28:42 -0000

> whatever purpose a sender wishes.

Not quite. I expect conventions to arise for its use in particular  
situations. For example, it might become common (even mandatory) to use it  
when messages are distributed to a mailing list (such cases would be  
easily recognisable by evaluators because of the presence of List-*  
headers as well). Doubtless there are other special purposes which  
evaluators could use and act upon (including perhaps well known senders  
such as Yahoo and Hotmail).
>
> I think I am +1 fine with your errata.

It probably needs a little more word smithing, but it should probably move  
ahead.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 30 Jan 2009 13:38:25 +0100

I'm neutral on the errata debate at the moment.  However, of the 
arguments I've heard, the below is perhaps the MOST bogus:

> Creating a -bis document would tend to push things in the wrong 
> direction; we need more documents that build on the base, not more 
> stuff in the base document.

Not only does that logic not follow, it ignores precisely what Pasi had 
suggested, which was to scope a -bis document to the sorts of changes 
for which errata is proposed.

Furthermore, no matter how the errata debate goes, we should do a -bis 
if there is working group rough consensus on even one erratum, because 
it will make it easier for implementers to look in one place for a 
correct specification.

---

From: John Levine <[email-masked]>
Date: 30 Jan 2009 13:19:29 -0000

>situations.

You are quite right that we'll probably have conventions in the
future.  But right now we don't, and we can't standardize what we
don't have, so as far as what should go in the documents, Al's
description is correct.

R's,
John

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Fri, 30 Jan 2009 19:31:21 +0530

> situations. For example, it might become common (even mandatory) to use it

Let's put it this way - that'd be "a purpose the sender wishes" and
not entirely inconsistent with what you say.

But it's place wouldnt be in the RFC - it'd be in a use case document
such as I suggested some few dozen emails back ...

--srs

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 30 Jan 2009 11:11:21 -0500

>is one of the reasons I tend to fall into the "d=" camp.

Don't forget i= is also in control of the signer too. An author/sender
does not control it.

-- 
Jeff Macdonald
[email-masked]

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Fri, 30 Jan 2009 22:07:15 +0530

> Don't forget i= is also in control of the signer too. An author/sender

Which would kind of make it redundant?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 30 Jan 2009 10:45:28 -0800

On Jan 30, 2009, at 8:37 AM, Suresh Ramasubramanian wrote:

> On Fri, Jan 30, 2009 at 9:41 PM, Jeff Macdonald <[email-masked] 
> > wrote:
>>> Signer does not necessarily have to equal sender for DKIM base.  
>>> This is one of the reasons I tend to fall into the "d=" camp.
>>
>> Don't forget i= is also in control of the signer too. An author/ 
>> sender does not control it.
>

No.  The i= parameter allows the signer to establish an identity that  
they have verified in some manner.

A domain has a few choices as to how this i= value might be used:

1) Have it match the originating email-address whenever this email- 
address represents who the signer verified.

2) Not include the i= value and prevent finer grain assessments.

3) Have the i= represent an opaque attribute that represents who the  
signer verified.

Large domains will almost always have some small percentage of  
problematic accounts.  If the d= parameter becomes a significant basis  
for acceptance, then replay abuse will need to be controlled.

A reputation service will provide little value when replay abuse  
prevents reliance on the DKIM domain for the majority of email being  
handled.

To rescue the service, the reputation of a DKIM domain might be Good /  
Check-I / Bad

A secondary check of the i= reputation for problematic domains would  
help mitigate an otherwise uncontrolled amount of abuse.  Path  
registration represents the only other alternative.

-Doug

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Sat, 31 Jan 2009 00:20:18 +0530

On Sat, Jan 31, 2009 at 12:15 AM, Douglas Otis <[email-masked]> wrote:
> Large domains will almost always have some small percentage of problematic
> accounts.  If the d= parameter becomes a significant basis for acceptance,
> then replay abuse will need to be controlled.

You are confusing authentication with reputation.

Authentication is going to be managed with a whole lot of other ways
rather than being solely dkim based

As for rep - one individual sender's rep really shouldnt taint all the
ISP (or all the d=) rep unless it is pretty damned bad.  And if the
ISP / ESP lets the cause of that bad rep continue .. well, they
deserve the bad rep.

Ever tried putting a single gram of (say) cyanide in a gallon of
water?  The entire water is poisoned as a result.

In other words replay attacks arent the attack vector I am concerned
about here - they are moot, to be frank and all due respect to the bee
in your bonnet.

--srs

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 30 Jan 2009 13:18:57 -0600

Folks,

Speaking of dogs, this horse has been beaten to death, turned into dogfood, 
consumed, and processed by the community waste disposal center.

We *really* don't need to pursue it again.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Fri, 30 Jan 2009 15:58:57 -0800

>> On Sat, Jan 31, 2009 at 12:15 AM, Douglas Otis <dotis at mail- 
>> abuse.org> wrote:
>>>
>>> problematic accounts.  If the d= parameter becomes a significant  
>>> basis for acceptance, then replay abuse will need to be controlled.
>>
>> Authentication is going to be managed with a whole lot of other  
>> ways rather than being solely dkim based
>>
>> As for rep - one individual sender's rep really shouldnt taint all  
>> the ISP (or all the d=) rep unless it is pretty damned bad.

Suresh,

Normally, acceptance is based upon the IP address of the SMTP client  
where DKIM offers an identifier that is independent of SMTP clients.

Unfortunately, this independent freedom allows DKIM messages to be  
replayed.  Resolving acceptance for DKIM (d=, i=) instead of just DKIM  
(d=) can remedy possible replay abuse with smaller data-sets than what  
is likely required to extend SMTP client data-sets to include IPv6  
addresses.

>>  And if the ISP / ESP lets the cause of that bad rep continue ..  
>> well, they deserve the bad rep.

There are hundreds of large domains with good reputations, where 1% or  
more of their outbound is comprised of spam or malware.  This level of  
abuse appears fairly representative, where some large domains send  
billions of messages daily.  1% of these messages quickly becomes  
fairly expensive to track, where even Bloom filters do not offer much  
relief.  However, when an account is rate limited to 500 daily  
messages, using the i= parameter reduces the size of the distributed  
information by a factor of 500.  In addition, the i= value allows  
receivers to anticipate what is likely to be abusive as well.

Currently, there are hundreds of millions of botnet systems  
erratically distributing email.  The number of sources, as well as the  
number of messages, used by botnets has grown in a dramatic and  
exponential fashion since 2005.

Large domains with good reputations control this situation by rate  
limiting accounts.  Unfortunately, replaying a DKIM message defeats  
rate limits whenever acceptance is based upon a DKIM domain.

>> water?  The entire water is poisoned as a result.  In other words  
>> replay attacks arent the attack vector I am concerned about here -  
>> they are moot, to be frank and all due respect to the bee in your  
>> bonnet.

Unless there is a way to defend the use of a DKIM domain, there is no  
point in expending resources on DKIM domains.  The i= parameter allows  
the poison to be reduced to normal levels.  Without the i= parameter,  
the IP address of the SMTP client will need to be associated with the  
DKIM domain.  Such path registration makes DKIM less robust.

While replay abuse is not currently a pressing concern, this is likely  
due to DKIM domains not playing a significant acceptance role yet.    
As such, it seem premature to start changing RFC 4871 until there is  
greater reliance upon the DKIM domain, and after learning what is  
needed to defend its use.

-Doug