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
