On Tue, 8 Nov 2005, Jim Fenton wrote:
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.
There is really only two statements of value:
1. signature is present for all emails originating from that source.
2. signature is present in none of the emails
(no emails originate from source)
How strong above statement should be viewed as should be controlled by
separate "axis" (which is the one you use for testing right now).
I'm really not sure what SHOULD means.
- Signature "should" be present (maybe "may" be present) -
Same as your current neutral. I actually don't care about names, so this
just gives you an overview.
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.
He's correct that it would open for DoS attack where the origin
could direct multiple others to do it.
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.
That is not what my post said. What it said is in some cases its usefull
to allow user policies to specify only certain part of the global domain
policy (only 3ps required/not for example) but not allow it to override
other parts of it. Obviously the global policy would be consulted first
in all the cases. In other words I view redirection to user policy as
an attribute of any "axis" and not neccessarily as global attribute.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
ietf-dkim mailing list
http://dkim.org