We might want to recognize the three orthogonal axes currently covered
by the policy character: sending mail, signatures, and 3rd party
signing. There is also the meta policy of ^/user, which redirects the
search to a different level.
On the sending mail axis you have the range of values of never and allowed.
On the signature axis you have the range of values of unspecified,
never, optional and always/required.
On the 3rd party signing axis we currently have the range of values of
unspecified, never, and allowed.
The current policy character merges all three axes into a single value.
Of course, some combinations are not allowable (e.g., never send +
anything else), and some are implicit rather than explicit (e.g.,
unspecified).
Throwing ^/user in the column with sending mail, and removing the
combinations I think should probably be disallowed, you have the
following table of possible policies:
sending mail signature 3rd party current
1 allowed unspecified unspecified NONE
2 allowed never never
3 allowed never allowed
4 allowed optional never ?/WEAK
5 allowed optional allowed ~/NEUTRAL
6 allowed always never !/EXCLUSIVE
7 allowed always allowed -/STRONG
8 never ./NEVER
9 user ^/USER
#1 is implicit with no policy record.
We could continue to extend the single word names for the different
policy combinations, or we could use a syntax that allowed you to
specify each value separately. A couple possible syntaxes might be
2 -signature,-3ps signature=never,3ps=never
3 -signature,+3ps signature=never,3ps=allowed
4 ~signature,-3ps signature=optional,3ps=never
5 ~signature,+3ps signature=optional,3ps=allowed
6 +signature,-3ps signature=always,3ps=never
7 +signature,+3ps signature=always,3ps=allowed
8 nomail nomail
9 user checkuser
These are some things to think about if we choose to keep SSP.
Tony Hansen
tony(_at_)att(_dot_)com
Hector Santos wrote:
----- Original Message -----
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
To: "IETF DKIM WG" <ietf-dkim(_at_)mipassoc(_dot_)org>
Tony Hansen mentioned this in the BoF Jabber session, and it is
something that I have long thought also.
Would it be better to change the o= values to be words instead of
single letters? I find the letters to not be very mnemonic and I
don't think we are that short on space.
That's a great idea! Talking in symbols is fun, but my APL days is long
over. :-)
Do you have any suggestions for terms? I've seen these floating around for
the last 3-4 months:
SSP Policies:
NONE (no policy [1])
o=? WEAK (signature optional, no third party, see [2])
o=~ NEUTRAL (signature optional, 3rd party allowed)
o=- STRONG (signature required, 3rd party allowed)
o=! EXCLUSIVE (signature required, no 3rd party)
o=. NEVER (no mail expected)
o=^ USER
[1} a NONE policy is possible where there is no declaration for a SSP.
[2] Arvel suggested another policy called WEAK which satisfies a
signature optional but not allowing 3rd party signers.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org
_______________________________________________
ietf-dkim mailing list
http://dkim.org