william(at)elan.net wrote:
Its quite clear from above that one policy would be better represented
as separate components:
1. Signature required/optional:
sig=MUST/SHOULD/NEVER/USER (sig=STRONG/NEUTRAL/NEVER)
2. 3rd parties allowed/not
3ps=ALLOW/DENY/USER
(Or if you like o=STRONG/3PS | o=NEUTRAL/NO3PS | o=USER/USER)
I like the separation of third-party policy (for lack of a better word)
from the rest. But I disagree with the "signature required/optional"
aspect. All the represented domain can say is whether they sign
everything they originate, which is a declarative and not an imperative
statement. I'm really not sure what SHOULD means.
Somewhat at odds with this is the t= flag, signifying testing. We
should recognize it for what it is, a request to the verifier/recipient
to "be gentle" in the event of a failure. It's worth discussing whether
it is appropriate for such requests to be part of SSP, or conversely
whether there should be finer granularity in such requests, e.g.,
"suggest you delete non-conforming messages" or "suggest that you tag
the subject line of such messages".
While we're on the subject of SSP, Doug Otis remarked to me yesterday
that he feels that the existence of r= (reporting address) in SSP only
invites abuse; it's reasonable to solicit [abuse] reports on signed
messages but not on unsigned ones. I think this deserves consideration.
I think there are legitimate cases when one may want to specify 3PS
as DENY for entire domain and not allow user policy to change.
Opposite cases can also exist, when one knows that all email from
domain would be signed but if 3ps signature is allowed or not is
dependent on particular user.
As the -ssp-01 is written, domain policy is consulted first and user
policy is consulted only if the policy is USER. DNS lookups would go
way up if we ever consulted user policy without a domain telling us to
do so.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org