Hallam-Baker, Phillip wrote: > OK please help me with the following point of semantics: > > I have a mail with some form of 'sender' address, lets call it > 'mail.example.com' > > I have a DKIM policy 'I sign all mail' bound to mail.example.com > 1) as a policy record at example.com > 2) as a policy record at *.example.com > 3) as a policy record discovered at example.com by means of > upwards traversal > > > What does the DKIM policy mean with respect to the placement of DKIM > keys? There must be some form of constraint or any signature with keys > anywhere will work, I don't think the policy is satisfied by > a signature at mallet.com.
It depends on what type of policy is being expressed. A signature at mallet.com might be applied by the [EMAIL PROTECTED] mailing list, and would be acceptable as a third-party signature if example.com's policy permits it. In practice, third-party signatures are more dependent on reputation and accreditation, since they're (IMO) more prone to abuse. A DKIM policy that specifies "no third parties" should place a constraint on the signing identity, not the location of keys. Key locations are already constrained by the rules in DKIM-base, in particular that they must be in the same domain as the signing identity, or a parent domain if certain flags are not specified. I don't see any need for the key record location to change even if the policy record is discovered via upward traversal. > > Implicit in the tree traversal approach is a re-positioning of the > start root for the key constraint. So if I eventually find my policy > at example.com that is where I constrain my key records to. > > This is one of the reasons I don't like the upwards traversal > semantics, the semantics of the policy now depend on where it is > found. Everything becomes a moveable feast and is confusion. > > > The solution is to specify the anchor point for the key record in the > policy statement as proposed previously for other reasons. > > For example "DKIM=_keys.example.com" means you will always find a DKIM > signature that is positioned at a subnode of the specified DNS node. > > This approach now works fine with wildcards. If someone misses out the > key anchor then the default is the sender domain being verified. > Otherwise the absolute value specified is used. > > As a bonus this gives the policy specification the power to deal with > issues such as when the policy of XYZ.com is that all their mail is > DKIM signed by comcast.net. This is getting back to the "designated signing domains" proposal from several months back. I thought (?) we had decided not to do that. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
