John Levine wrote:
But of my address were instead fenton(_at_)mipassoc(_dot_)org and the list
applied a signature with no local-part in i=, one couldn't tell
whether the signature represented the message passing from me to the
mailing list (an Originator Signature), or from the mailing list to
the users.
Right. That's a feature, not a bug. 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.
The SSP draft that's on the table matches the local-part of the From
address against the local-part of i= if it is provided, so it goes
against what you just said. RFC 4871 also requires the local-part to
match the g= tag on the key if it is present.
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:
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.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html