>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
