ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: New Issue: signed vs. unsigned header fields asinput to SSP

2008-01-23 19:18:45

On Jan 23, 2008, at 5:03 PM, Frank Ellermann wrote:

Arvel Hathcock wrote:

One question I have is this: do we need the added algorithmic complexity of this Sender: match check?

It was supposed to be better than "first author", and IMO it is.

If we now go for "all authors" (up to a limit) it doesn't help to pick a "better than the first" author. We could add Sender to the list of "author domains" for cases where the Sender is not one of the authors, just because it's SSP and no "ASP" (?)

Agreed; a From email-address minimum maximum must be defined. However, policy discovery for the Sender header is not needed.

With the exception of those signed using g= restricted keys, when the d= domain of the signature on-behalf-of the Sender's or any other header's email-address is at or above the domain the of From email- address, the message is "strict" and "all" complaint. By limiting compliance to a comparison of email-address and signatures domains (the d= domain parameter), it does not matter which header a signature is on-behalf-of. This mode of comparison establishes compliance without needing to discover SSP. Any From email-address will be contained within the signature's hash, as should the header being signed on-behalf-of. A signature by an unrestricted key SHALL indicate the message is complaint with the policy established by the signing domain. Verifiers should not be expected to second guess whether such messages are complaint regardless of _any_ SSP assertions.

In the case of the g= restricted keys, unless signed on-behalf-of the From email-address, SSP must be checked when a From domain signature is otherwise lacking. When an assertion of "all" or "strict" has been found, these messages should be considered to have failed SSP compliance.

-Doug

_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html