Subject: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871-errata-04.txt

From: [email-masked]
Date: Tue, 21 Apr 2009 07:30:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF.

	Title           : RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update
	Author(s)       : D. Crocker
	Filename        : draft-ietf-dkim-rfc4871-errata-04.txt
	Pages           : 12
	Date            : 2009-04-21

This updates RFC 4871, DomainKeys Identified Mail (DKIM) Signatures.
Specifically the document clarifies the nature, roles and
relationship of the two DKIM identifier tag values that are
candidates for payload delivery to a receiving processing module.
The Update is in the style of an Errata entry, albeit a rather long
one.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871-errata-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 21 Apr 2009 07:36:22 -0700

Folks,

The usual set of formats and diffs are at:

    <http://dkim.org/ietf-dkim.htm#errata>

d/

-- 

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Apr 2009 11:40:14 -0400

>    <http://dkim.org/ietf-dkim.htm#errata>

I'm sending the PROTO write-up to Pasi to get processing started on
this.  Of course, serious errors can still be corrected, if necessary.

Barry (as chair)

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Apr 2009 09:37:36 -0700

> this.  Of course, serious errors can still be corrected, if necessary.

I continue to be amazed at how utterly useless this document is, and
more so that people are being asked to break a sweat to issue it. The
most serious error is that it is a solution in search of a problem.

Is there *one* person/organization here who can say that this text
changed or affected their implementation in any way?

		Mike

---

From: Al Iverson <[email-masked]>
Date: Tue, 21 Apr 2009 12:41:12 -0500

> changed or affected their implementation in any way?

Yes. It hasn't affected our current implementation, but it will help
to guide me on implementation choices I make in the future.

Regards,
Al Iverson
ExactTarget

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

---

From: Michael Adkins <[email-masked]>
Date: Tue, 21 Apr 2009 13:42:43 -0400

Current? No.

Future? Yes.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 21 Apr 2009 11:00:32 -0700 (PDT)

> to guide me on implementation choices I make in the future.

I wouldn't be surprised to find that people on this list realize no 
substantial benefit from the text changes proposed.  But then, the 
intended audience of the RFC and errata is much larger than the population 
of this list.

So it may not help "us", but I could see how it might help "them".
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Apr 2009 11:36:58 -0700

> to guide me on implementation choices I make in the future.

Please elaborate how. Especially valuable would be examples of where
your code would have not been interoperable before this errata, but
would conform in the future. Barring that, a list of any changes to
operational behavior would be nifty.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Apr 2009 11:45:09 -0700

> So it may not help "us", but I could see how it might help "them".

   There is a downside, however: churn. Issuing updates implies that
   the current document is not stable. Would that every RFC the IETF
   issued "require" such inconsequential and non-implementation affecting
   changes. Alas, updates, etc, almost always mean that the updated
   document is fundamentally broken in some or many ways. That is not
   even remotely the case here, yet we are rushing at this as if the
   email world's fate were held in the balance.

		Mike

---

From: Al Iverson <[email-masked]>
Date: Tue, 21 Apr 2009 14:17:30 -0500

> operational behavior would be nifty.

No thanks. Sadly, I must decline to try to keep up with your moving goal post.

Regards,
Al Iverson

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Apr 2009 15:27:21 -0400

I'm going to cut off this thread of discussion.  The changes here were
proposed as a result of a long conversation that made it clear that
there was disagreement, even among the active participants here, as to
what RFC 4871 really meant.  It's likely that if *we* disagree, others
reading the spec on their own will have trouble understanding what it
means.

There is consensus -- not unanimous agreement, but rough consensus --
in the working group that the document we're processing is a
reasonable effort at clarifying things for implementors who don't have
the benefit of ready access to discuss things with the original
authors/editors.  Because we've been here and moved on, the topic of
whether we need to make changes to the definitions at this point... is
off the table.

Let's save that energy for the RFC4871bis effort.

Barry (as chair)

---

From: John Levine <[email-masked]>
Date: 21 Apr 2009 19:54:02 -0000

>changed or affected their implementation in any way?

Yes.

R's,
John

PS: It's rarely a good idea to assume that everyone else's mail system
works the same way that yours does.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Apr 2009 10:05:42 -0700

>>    <http://dkim.org/ietf-dkim.htm#errata>

Surprised to still see that this has not been corrected.

Errata:

Original Text:
,---
The tendency is to have the MUA highlight the address associated with  
this *signing identity* in some way, in an attempt to show the user  
the address from which the mail was sent.
'---
Corrected Text:
,---
The tendency is to have the MUA highlight the SDID,  in an attempt to  
show the user the identity that is claiming responsibility for the  
message.
'---

This text dramatically revises the meaning of the original RFC and  
goes well beyond the role of an Errata.

Properly Corrected the text would be as follows:
,---
The tendency is to have the MUA highlight the AUID,  in an attempt to  
show the user the identity that is claiming responsibility for the  
message.
'---

Changes of this nature should be done within a bis, if needed.

The Signing Identity as defined in RFC 4871 is the i= value.

1.1. Signing Identity

DKIM separates the question of the identity of the signer of the  
message from the purported author of the message.  In particular, a  
signature includes the identity of the signer.  Verifiers can use the  
signing information to decide how they want to process the message.  
The signing identity is included as part of the signature header field.

Section 3.5:

  d=  The domain of the signing entity (plain-text; REQUIRED).  This  
is the domain that will be queried for the public key.  This domain  
MUST be the same as or a parent domain of the "i=" tag (the  signing  
identity, as described below), or it MUST meet the requirements for  
parent domain signing described in Section 3.8.
        When presented with a signature that does not meet these  
requirement, verifiers MUST consider the signature invalid.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 22 Apr 2009 11:39:17 -0600

> Let's save that energy for the RFC4871bis effort.

Thank you.

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