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
