On Nov 29, 2007, at 10:09 AM, Jim Fenton wrote:
John Levine wrote:
As Jon has eloquently reminded us, the granularity of DKIM
validation is domains, not mailboxes. If for some reason it is
important to you to separate the reputation of your list mail from
your individual mail, sign the list mail with a different signing
domain. You can also put the lists into a different domain, but
that's optional.
The issue here isn't reputation (although this may come up in that
context, too); the issue is whether a given signature is interpreted
as an Originator Signature or not by SSP.
Per SSP:
,---
|2.8. Originator Signature
|
| An "Originator Signature" is any Valid Signature where the signing
| address (listed in the "i=" tag if present, otherwise its default
| value, consisting of the null address, representing an unknown user,
| followed by "@", followed by the value of the "d=" tag) matches the
| Originator Address. If the signing address does not include a local-
| part, then only the domains must match; otherwise, the two addresses
| must be identical.
'---
The term Originator Signature will not clarify whether the identity
within the email-address had been authenticated (per non-normative
notes within the base specifications regarding inclusion of the
localpart within the i= parameter).
When a large domain is signing with DKIM and is submitting a fair
amount of spam, there will be a desire to make erroneous assumptions
to block based upon email-addresses in conjunction with DKIM signing
domain. The term Originator Signature sheds no light on this matter
whatsoever. It would be very wrong to even think that it does.
The missing definition is:
: Authenticated Identity
:
: An "Authenticated Identity" is determined by a Valid Signature where
: the signing domain within the d= tag is the same or a parent domain
: of the email-address within the header, and where the localpart is
: also fully included within the "i=" tag.
4871 says that the local part in g= matches the local part in i=
but that local part is still an opaque token, not a mailbox.
That's a creative interpretation, but it isn't supported by 4871.
From the tag definitions in section 3.5:
No. There are _no_ stipulations that the "on behalf of" email-address
identity be elsewhere in the message.
i= Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed (dkim-quoted-printable;
OPTIONAL, default is an empty Local-part followed by an "@"
followed by the domain from the "d=" tag).
Although 4871 doesn't specify any semantics associated with the
local-part of i=, if it had been intended to be an opaque token, it
would have been worded differently. It's true that 4871 says that
the local-part doesn't have to match any particular header field,
but says in an informative discussion that this is a "verifier
policy issue". This leaves the door open to matching the local-part
to a header field as has been proposed in the SSP draft.
Sorry Jim, but as you can see from the quoted section, even the SSP
draft fails to make the distinction of i= semantics. See my suggested
definition.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html