Only because people insist that it *must* work in every
scheme they can make up.
I believe that we could implement what we have discussed and
the fact that it won't work for everybody should be an
asterisk. It will work for most systems and I am comfortable
with that. Implementation is not a requirement.
I think that we can reduce the complexity of the policy language by 50% and
increase the power of the policy statements in the process.
It appears to me that we have to change SSP because the punctuation mark policy
descriptions are not sustainable.
Thus far I am not convinced that we need to have per user policy at all. The
ability to add per user signatures does not imply the need for per user policy.
In fact the only place where I can see a real advantage is the case where there
are exceptions to the 'I always sign' scheme.
If we do have per user policy I think that it needs to be defined in such a way
that it is clear that it is an extension. So for example if DKIM is the tag
describing the domain based DKIM and USER is the per user version of the policy
language we would in my scheme have a master policy record of the form:
_policy._SMTP_OUT.example.com TXT "policy.smtp_out USER"
alice._policy._SMTP_OUT.example.com TXT "policy.smtp_out DKIM"
keith._policy._SMTP_OUT.example.com TXT "policy.smtp_out"
These records state that email from alice(_at_)example(_dot_)com always has a
DKIM header and that there is no per-user policy for mail from
keith(_at_)example(_dot_)com(_dot_)
OK so now that I have demonstrated that we can introduce per-user policy as a
DKIM extension we can decide to punt on it if we choose. We can get the domain
level policy right first knowing that we can address the second level option
later
Furthermore in this scheme it is obvious how the master record would encode for
SMIME or PGP
If we are dealling with cases where subdomains exchange mail it is convenient
to allow the DKIM-USER tag to take a DNS node specifying the root of the policy
distribution as a parameter so that
keith(_at_)willcomment(_dot_)example(_dot_)com can be wildcarded:
*.example.com PTR example.com
_policy._SMTP_OUT.example.com TXT "policy.smtp_out
DKIM-USER=_policy._SMTP_OUT.example.out"
We can even use this scheme to specify policies at the domain level AND the per
user level:
AND conjunction:
_policy._SMTP_OUT.example.com TXT "policy.smtp_out DKIM & USER"
alice._policy._SMTP_OUT.example.com TXT "policy.smtp_out
DKIM=alice._domain.example.com"
bob._policy._SMTP_OUT.example.com TXT "policy.smtp_out PGP"
carol._policy._SMTP_OUT.example.com TXT "policy.smtp_out SMIME"
There is always a DKIM signature AND a per user policy MAY be specified. In
this case we use the per user policy to specify that email signed by Alice has
an additional selector restriction, Bob always uses PGP in addition to the DKIM
record and Caro; always uses SMIME in addition.
Alternatively we can have an OR conjunction:
_policy._SMTP_OUT.example.com TXT "policy.smtp_out DKIM | USER"
With this infrastructure we can solve every one of the use cases I have seen to
date.
I don't see why any authentication policy would require more than four terms,
six at the absolute maxiumum. It is not necessary to implement braces, merely
specify whether AND or OR has higher precedence.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html