consider it punted however the same tree/wildcard issue exists to get any policy statement so lets try to think our way out of it. We have policies we want either 1-4 or in my case 1-5 so lets get them extracted without ddosing DNS thanks, Bill
-----Original Message----- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Tue 6/5/2007 5:31 PM To: Hector Santos Cc: Oxley, Bill (CCI-Atlanta); [EMAIL PROTECTED]; [email protected] Subject: RE: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope. I am trying to punt the wildcard baggage and tree traversal bagage that is being acreted to meet a requirement that is out of scope. > -----Original Message----- > From: Hector Santos [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 05, 2007 5:29 PM > To: Hallam-Baker, Phillip > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [email protected] > Subject: Re: [ietf-dkim] RE: I think we can punt the hard > stuff as out ofscope. > > Yeah, but don't you see Phillip, this was already done, in > SSP for each of its drafts, and in DSAP in its expired draft. > > Why are we wasting time trying to remove this NO MAIL > concept? So that you can just create a slot later on in your spec? > > I don't get it. > > -- > Sincerely > > Hector Santos, CTO > http://www.santronics.com > http://santronics.blogspot.com > > > allam-Baker, Phillip wrote: > > Now add the three pages of boilerplate. > > > > That is why I said four. > > > >> -----Original Message----- > >> From: Hector Santos [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, June 05, 2007 5:10 PM > >> To: [EMAIL PROTECTED] > >> Cc: Hallam-Baker, Phillip; [EMAIL PROTECTED]; > >> [email protected] > >> Subject: Re: [ietf-dkim] RE: I think we can punt the hard stuff as > >> out ofscope. > >> > >> Its not 4 pages!!! <grin> > >> > >> Good show Bill! > >> > >> > >> -- > >> Sincerely > >> > >> Hector Santos, CTO > >> http://www.santronics.com > >> http://santronics.blogspot.com > >> > >> [EMAIL PROTECTED] wrote: > >>> Edit/draft follows > >>> The result of a Sender Signing Policy Check is one of > five possible > >>> policies: > >>> > >>> (1) Some messages from this entity are not signed; > the message > >>> SHOULD be presumed to be legitimate in the absence > of a valid > >>> signature. This is the default policy. > >>> > >>> (2) All messages from this entity are signed; all > >> messages from > >>> this entity SHOULD have a valid signature, either > directly on > >>> behalf of the originator or on behalf of a third > >> party (e.g., a > >>> mailing list or an outsourcing house) handling the message. > >>> > >>> (3) All valid messages from this entity are signed, > and SHOULD > >>> have a valid signature from this entity. Third-party > >> signatures > >>> SHOULD not be accepted. > >>> > >>> (4) Signing policy for this domain is expressed at > >> the individual > >>> address level. A second Sender Signing Policy > Check should be > >>> performed specifying the individual address > >>> > >>> (5) This Domain does not send messages/This domain > only signs > >>> third party messages > >>> > >>> > >>> Done, now the rest of the WG should be happy thanks, Bill > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] on behalf of Hallam-Baker, > >>> Phillip > >>> Sent: Tue 6/5/2007 3:54 PM > >>> To: Hector Santos > >>> Cc: Scott Kitterman; [email protected] > >>> Subject: RE: [ietf-dkim] RE: I think we can punt the hard > >> stuff as out ofscope. > >>> > >>> OK how about this as a plan > >>> > >>> 1) We do policy according to the view of scope currently > >> being expressed by the chairs and myself. > >>> 2) You and I submit a four page ID that registers a NOMAIL > >> policy for DKIM. > >>> 3) The group decides whether to accept the paragraph of > >> text into the text of the main draft or not during the Draft phase. > >>> > >>> > >>>> -----Original Message----- > >>>> From: Hector Santos [mailto:[EMAIL PROTECTED] > >>>> Sent: Tuesday, June 05, 2007 3:48 PM > >>>> To: Hallam-Baker, Phillip > >>>> Cc: Michael Thomas; Scott Kitterman; [email protected] > >>>> Subject: Re: [ietf-dkim] RE: I think we can punt the > hard stuff as > >>>> out of scope. > >>>> > >>>> Hallam-Baker, Phillip wrote: > >>>> > >>>>> NOMAIL is out of scope, wildcards for signature policy are not. > >>>> Deja-vu. NOMAIL is not out of scope in SSP and you need to STOP > >>>> saying > >>>> it. The CONFUSING VOTE that was taking - I still don't now > >>>> show what > >>>> it meant but it was not what it would to be removed from SSP! > >>>> > >>>>> There are two deployment stories we need to be able to give, > >>>> > one that meets 95% of needs with legacy infrastructure > >> support, > > >>>> the second that meets 100% of needs with a minor incremental > > >>>> change to the legacy infrastructure. > >>>> > >>>> I don't see how SSP violates this principle. > >>>> > >>>>> The second of these provides a slot ready made > >>>> > for NOMAIL, (and for STARTTLE, PGP and SMIME if you like). > >>>> > >>>> Oy vey! So then it is not out of scope as you said. > >>>> > >>>>> I am meeting your set of requirements in full. I am just > >>>> > not doing so in such a way that my proposal is out of > scope, > > >>>> that is all. > >>>> > >>>> Well, I would like to know who proposed this lame rule > >> that it should > >>>> be out of scope when it wasn't and was clearly part of all > >> the sepcs > >>>> - SSP and DSAP specs. > >>>> > >>>> If people voted under the disquise of a general "NO MAIL" > >>>> concept across > >>>> the board, well, it is clear now this is not what they voted for > >>>> because you are making provisions for it. > >>>> > >>>> I don't understand why is so secret. I don't want a NO-MAIL DKIM > >>>> policy to be dependent on a KLUDGED MX concept or LMAP support. > >>>> > >>>> > >>>> -- > >>>> Sincerely > >>>> > >>>> Hector Santos, CTO > >>>> http://www.santronics.com > >>>> http://santronics.blogspot.com > >>>> > >>>> > >>> _______________________________________________ > >>> NOTE WELL: This list operates according to > >>> http://mipassoc.org/dkim/ietf-list-rules.html > >>> > >>> > >>> > >> > >> > > > > > > > > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
