This discussion seems to be going round in circles. Lets go back to some basic principles that we try to make general laws:
1) Each party that claims responsibility for a message does so in their own name 2) If a party wishes to delegate signing capability (in effect a PP signature) then this structure should be visible in the policy architecture 3) The only DKIM policy record useful to a recipient states 'everything I send has a DKIM header' These principles seem to me to suggest the following approach: 1) The domain owner adds a dummy DKIM header 2) The actual sender accepts responsibility in their own name. OK so what might a dummy header look like? * The signature is not 100% effective * It has a selector If the email sender is sending out identical content to every recipient then it would make sense for the domain name owner to sign the content but not the sender field to create the dummy header. If the messages are going to be customized for each recipient then the dummy header would not cover either the content or the sender. If this practice is to be widespread we should define a NULL algorithm to save the recipient the need to check a useless signature. The selector can contain statements that are in effect policy language. For example: * This key record can only be used with the outbound email address [EMAIL PROTECTED] * If this key record is used there MUST also be a signature from party Y. I think that the above meets the use cases described. Each key record is in effect a policy statement insofar as publishing a key record means that you are defining a set of acceptable criteria for authentication. The SSP record contains only the statement that everything has a DKIM header. As I see it there are only two useful routes to extending the policy record beyond that. * The SSP record states that every message sent has 1...n DKIM headers where the key selectors meet stated criteria. * If no header is present then a key record can be obtained by applying a given set of rules. (this is a powerful idea but the complexity does not seem to be justified by the return). _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
