Douglas Otis wrote: > > On Oct 19, 2007, at 8:46 AM, Jim Fenton wrote: > >> Dave Crocker wrote: >> > > >>> 2. Does RFC 4871 contain any claims that a DKIM signature carries a >>> claim by the signer that any of the body or header content is >>> "correct" or "truthful"? >>> >>> I ask because I believe it does not carry any such claim and that, >>> rather, a DKIM signature asserts a very generic degree of signer >>> "responsibility" which does not extend to formal claims of correctness. >> >> 4871 indeed uses a broad notion of "responsibility". However, in the >> case where the signing address is the same* as some other header >> field, such as 2822.From, I don't see how a signer can be responsible >> for a message that uses its own address without an implied claim that >> the address is correct. >> >> * "same" meaning that the i= address is either the identical, or that >> the i= address has the same domain if i= has no specified local part. > > It would be a bit more accurate to use the term "signing domain", > rather than "signing address". An address (the i= parameter) is > optional, after all.
The parameter is optional, but if absent, the signing address (what i= represents) takes the default value of the d= parameter (preceded by an @). There is always a signing address. I get tired of typing "i= (or d= in its absence)" every time I talk about i=, since this is in the specification, but every time I don't spell this out very explicitly I need to write a clarifying message. > > The optional i= parameter represents the identity of the user or > agent (e.g., a mailing list manager) on who's behalf the message was > signed. The base specification makes no statement that this optional > parameter SHOULD NOT be applied when the user or agent identity has > not been validated. (See the informative note about whether the i= > parameter can be trusted.) Without a stipulation that the i= > parameter MUST BE validated, and exactly which validation mechanisms > must be used within the base specification, it would be a significant > change to assume inclusion of the i= parameter thereby confers > responsibility to validate identities onto signing domains. There are > also cases where the i= parameter can not be applied, such as when the > signing domain is within a sub-domain of the identity, or when the > identity is within another domain. Would you envision the blocking of > messages which did not include the i= parameter containing the > local-part? The validation of the local-part of i= is that it must (wildcard) match the value of g=, if present, in the key record. An agent in possession of a private key that does not constrain the local part (no g= in the key record, or g=*) is one that is trusted by the domain to take responsibility for any message on behalf of any address in the domain. So the i= parameter is already validated. The cases you cite: signing domain is within a subdomain of the identity, or when the identity is within another domain, are intentional. example.com should not be taking responsibility for messages on behalf of bigbank.com. If it has a legitimate reason to do this, it is delegated a key by bigbank.com and signs as that domain. I would not envision (and can think of absolutely no reason to) blocking messages without an i= parameter specifying a local-part. The ability to specify i= without a local-part was done for a reason. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
