None of these loopholes would exist if signatures could vouch only
for rfc822.from domains that match the signature's d= domain (*).
Third party signatures are part of the problem.
Actually, I think the problem is that people want to read way too much
meaning into a DKIM signature. If a message is signed by blah.com,
all that means is "if you don't like this message, blame blah.com."
That's it. Despite quite a lot of loud wishful thinking from people
in my killfile, it doesn't mean anything about the accuracy or lack
thereof of various header lines, the path the message took, the
spamminness of the message, the worth of other signatures that might
be present, or anything else.
This is an important deliberate design decision. In my case, for
example, I expect to sign all the outgoing mail at my MTA with my main
domain, even though I have users who send mail in about 200 vanity and
small biz domains. So long as my users behave, which they do, there
is no point to trying to match up signatures with From: lines and the
effort to do so would be so great that I wouldn't, anyway. There is
enough info in the messages for me to tell who sent a particular
message (user names, time stamps, etc.), even though it might not be
possible for a random recipient to do so. I think this is a microcosm
of the situation at most ISPs.
A topic we've been dancing around but never really faced is what extra
semantics if any there are if a signature's d= matches the From line.
I don't think there are any, but I see a lot of people who seem to
think that it means the entire From: address is correct, for some
definition of correct.
Finally, don't forget that recipients have great latitude in their
interpretation of DKIM signatures. If you don't think that third
party signatures tell you anything useful, you can always ignore them.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html