[ietf-dkim] RE: I think we can punt the hard stuff as out ofscope.
Bill.Oxley at cox.com
Bill.Oxley at cox.com
Tue Jun 5 14:47:06 PDT 2007
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:pbaker at verisign.com]
Sent: Tue 6/5/2007 5:31 PM
To: Hector Santos
Cc: Oxley, Bill (CCI-Atlanta); ietf-dkim at kitterman.com; ietf-dkim at mipassoc.org
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:hsantos at santronics.com]
> Sent: Tuesday, June 05, 2007 5:29 PM
> To: Hallam-Baker, Phillip
> Cc: Bill.Oxley at cox.com; ietf-dkim at kitterman.com;
> ietf-dkim at mipassoc.org
> 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:hsantos at santronics.com]
> >> Sent: Tuesday, June 05, 2007 5:10 PM
> >> To: Bill.Oxley at cox.com
> >> Cc: Hallam-Baker, Phillip; ietf-dkim at kitterman.com;
> >> ietf-dkim at mipassoc.org
> >> 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
> >>
> >> Bill.Oxley at cox.com 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: ietf-dkim-bounces at mipassoc.org on behalf of Hallam-Baker,
> >>> Phillip
> >>> Sent: Tue 6/5/2007 3:54 PM
> >>> To: Hector Santos
> >>> Cc: Scott Kitterman; ietf-dkim at mipassoc.org
> >>> 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:hsantos at santronics.com]
> >>>> Sent: Tuesday, June 05, 2007 3:48 PM
> >>>> To: Hallam-Baker, Phillip
> >>>> Cc: Michael Thomas; Scott Kitterman; ietf-dkim at mipassoc.org
> >>>> 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
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>
>
>
>
More information about the ietf-dkim
mailing list