----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
Seems like it'd be a good idea to include such a table in
the base draft at some stage. I'm not saying these row,
column or value labels are the right ones, but something
along these lines would help the reader out since there
are a whole bunch of potential outcomes to take into
account.
I think so.
Ultimately, software will need automation (implicit or explicit with local
sysop policy defined help) and having hard vs. indeterminate decision
actions separated will help.
Incidently, not sure if you aware of this, but the column names (SSP policy
labels) are based on the SSP o= tag policies as defined today.
In addition, I added two additional ones not currently defined but
nonetheless required.
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.
This will address Social Engineering phishing threats where bad actors
are exploiting DKIM borrowing the good names of non-DKIM original
domains.
[2] Arvel suggested another policy called WEAK which satisfies a
optional signature domain policy but not allowing 3rd party
signers.
I agree some of the actual policy labels can be more appropriately defined.
I was trying to use terms that will naturally flow in verbal conversations.
Its easier to say over a phone conversation "this domain has a NEUTRAL
policy" as oppose to "this domain has a OH equal tilde policy."
I think WEAK and NEUTRAL are both WEAK, but NEUTRAL is here first and its
the common term used in other technology such as SPF.
I think the label EXCLUSIVE policy is ok since it is the strongest (and I
believe also provides the highest value for DKIM). I believe Jim Fenton
indicated a preference of using STRONGER but had no problem with EXCLUSIVE.
I think EXCLUSIVE has no other meaning but only to suggest a system does not
allow any kind of 3rd party signing. It is 100% exclusive for one domain
only.
NEVER conflicts with Michael Thomas's DKIM algorithm constant called NOMAIL.
I probably would of suggested NOMAIL if I had saw his algorithm prior to
proposing the labels to remain consistent.
USER was thrown in simply because the o=^ is loosely defined in the SSP
specs, but as your WG DRAFT suggest, it is out of scope.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org