Re: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871-errata-03.txt

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

Re: [ietf-dkim] Consensus points on "errata" draft from the IETF 74 meeting

> Is this an errata?  What is the rush?  Why prevent the WG from > commenting on finalized changes?  It is not clear what now represents > "agreement" or "consensus".  Excluding any WG input might be overly > optimistic. This is the "errata" draft, renamed to "Update" and processed as an RFC, as w

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

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

Re: [ietf-dkim] Consensus points on "errata" draft from the IETF 74 meeting

On Apr 3, 2009, at 3:30 PM, DKIM Chair wrote: >> 1. On the content, we hashed out a few things that needed tweaking, >> and Dave has already posted about these. The response looks good. > > The chairs note that Dave's proposed changes have rough consensus. > We understand that Dave has a n

Re: [ietf-dkim] Consensus points on "errata" draft from the IETF 74 meeting

DKIM Chair wrote: > Dave, please post that, done. assorted formats, as well as a diff for the new version, are at: d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This l

Re: [ietf-dkim] Consensus points on "errata" draft from the IETF 74 meeting

> 1. On the content, we hashed out a few things that needed tweaking, and Dave > has already posted about these. The response looks good. The chairs note that Dave's proposed changes have rough consensus. We understand that Dave has a new draft with the current version of those changes ready

Re: [ietf-dkim] Consensus point on ADSP

> The current proposal is to remove i= here, and rework the text so that ADSP > uses d= only. The chairs note that this proposal has rough consensus. Jim has suggested that if we do this, and in view of the discussion of "Author" vs "Author Domain", we should make sure the documents consistentl

Re: [ietf-dkim] Author Signature vs. Author Domain Signature / Internal vs External threats

J.D. Falk wrote: > bill.ox...@cox.com wrote: >> 3rd party signing was removed from discussion some time ago > > ...with the intention of discussing it again after seeing how the industry > deals with 'em, both with & without ADSP. But you been discussing it all along. It never went away. What do

Re: [ietf-dkim] Author Signature vs. Author Domain Signature / Internal vs External threats

On Apr 3, 2009, at 2:21 AM, Eliot Lear wrote: >> >> Second, either the d= matches the domain in the rfc5322.From field, >> or it doesn't. There is no complexity or subtlety to the test, so >> there are no "implications" that need to be pointed out. > > This is unresponsive to Jim's point. A

Re: [ietf-dkim] Author Signature vs. Author Domain Signature / Internal vs External threats

bill.ox...@cox.com wrote: > 3rd party signing was removed from discussion some time ago ...with the intention of discussing it again after seeing how the industry deals with 'em, both with & without ADSP. 1st party, as addressed in ADSP with d=: simple, easy to understand, but doesn't apply to

Re: [ietf-dkim] errata revision: Identity Assessor vs. Message Filtering engine

> It may be better to have "Assessor" or "DKIM Assessor" unless you > want to constraint the module to consume the SSID only or identities > only. The whole point of defining this term is to isolate the assessment of the identity from other decisions. I think it's best as it is, with "Identity As

Re: [ietf-dkim] Author Signature vs. Author Domain Signature / Internal vs External threats

3rd party signing was removed from discussion some time ago On 4/3/09 4:01 AM, "Hector Santos" wrote: Dave CROCKER wrote: > > Jim Fenton wrote: >> Dave CROCKER wrote: >>> ps. That includes dropping the "ADSP is incompatible" note. >>> >> If you mean the note that I included in the alternative t

Re: [ietf-dkim] Author Signature vs. Author Domain Signature / Internal vs External threats

On Thu, Apr 02, 2009 at 08:15:02AM -0700, Dave CROCKER wrote: > >Use d=. +1 -- Jeff Macdonald jmacdon...@e-dialog.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Consensus point on ADSP

On Wed, 01 Apr 2009 23:38:39 +0100, Jim Fenton wrote: > One more try to clarify things, then I'll stop trying. > > Charles Lindsey wrote: > >> The existence of an ADSP record states that "If you see this domain in >> the >> From: header of any email, you should expect to see also a valid >> s

Re: [ietf-dkim] Author Signature vs. Author Domain Signature / Internal vs External threats

Again, call it what you want, UAID, SDID, Author Domain Signature vs Gmail domain signatues or mipassoc.org domain signatures, etc, when you have this: DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=mipassoc.org; s=k1; From: "J.D. Falk" or this: DKIM-S

Re: [ietf-dkim] Author Signature vs. Author Domain Signature / Internal vs External threats

bill.ox...@cox.com wrote: > 3rd party signing was removed from discussion some time ago Only by name, just like Dave stated here: "All that is left is the more general question of deciding how to distinguish among outgoing mail streams with different SDID values." Call it want what you ple

Re: [ietf-dkim] Author Signature vs. Author Domain Signature / Internal vs External threats

Dave, > First, this is one of the simplifications we get by the change that the > working > group agreed to, with the RFC4871 Update about to be formally approved, and > with > the use of SDID, rather than AUID, in ADSP: the issue of a "parent" > disappears. >All that is left is the more g

Re: [ietf-dkim] Consensus point on ADSP

Jim Fenton wrote: > > Charles Lindsey wrote: >> BUT IT DOESN'T! > > If "people on this list" is referring to me, please say so. I do not > think as you assert that ADSP is keyed to the d= of the signature. That > wouldn't make sense, because ADSP has to function in the absence of any > [valid]

Re: [ietf-dkim] Author Signature vs. Author Domain Signature / Internal vs External threats

I agree. This reduces the issue down to a well defined subtle problem that always existed. From.domain does not match d= domain So what? --- On 4/2/09, Mark Delany wrote: > On Apr 2, 2009, at 1:46 PM, Wietse Venema wrote: > > >>> I think you may have put your finger on the root of much

Re: [ietf-dkim] Author Signature vs. Author Domain Signature / Internal vs External threats

Dave CROCKER wrote: > > Jim Fenton wrote: >> Dave CROCKER wrote: >>> ps. That includes dropping the "ADSP is incompatible" note. >>> >> If you mean the note that I included in the alternative text that I >> posted, I disagree. Parent domain signing is a technique described in >> RFC 4871. If