> 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 [EMAIL PROTECTED] always has a DKIM header and that there is no per-user policy for mail from [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
