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(_dot_)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(_dot_)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(_dot_)com]
Sent: Tuesday, June 05, 2007 3:48 PM
To: Hallam-Baker, Phillip
Cc: Michael Thomas; Scott Kitterman; ietf-dkim(_at_)mipassoc(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html