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