> For now, isn't it probably ok to add this to the to-do list and > continue to work on the threat analysis which was a show-stopper > last time?
Yes, I suppose you're right. This disagreement about multiple signatures cuts to the heart of what DKIM is for. If, as Mike Thomas seemed to be saying, the most we can get from DKIM is another factor to toss into the spamassassin hopper, we're wasting our time. If we have a signature and a reputation for the signing domain, we should be able to skip the rest of the spam filtering mess. As I said in a previous message, the point of a DKIM signature is to pin the blame on a specific domain. This cuts both ways -- recipients can then use info about the domain to decide what to do with the message, and they can also use the message to update their info about the domain. Disregarding spammers who don't care about their reputations, this leads to a virtuous feedback loop in which domains benefit from signing mail that recipients like, feel some pain for signing mail that recipients don't want, and have an incentive to improve their practices. If we permit multiple signatures, that works a lot worse. In Jim Fenton's example where a friend resigns a spam from an all-419 domain, multiple signatures let the friend deflect the responsibility onto the original sender rather than fixing whatever caused him to sign and resend it. Eliot Lear points out, correctly, that a message's signing history is useful trace information. But trace info is different from responsibility info. This suggests to me that it is useful to define a way to record signature history, either as a new clause in a Received: header or perhaps a new trace header, different from a signature header to make it clear that it's for forensics, not for pinning blame. Finally, Dave Crocker suggests that multiple signatures may be useful for rotating through signing keys. With DK, I thought the plan was that you publish a new signing key and start signing with it, wait long enough for mail with the old key to be delivered, then withdraw the old key. Assuming that we agree that putting two mechanisms in a standard to do the same thing is a bad idea, what's the advantage of allowing multiple sigs? R's, John _______________________________________________ ietf-dkim mailing list http://dkim.org
