On Sep 14, 2010, at 12:35 PM, J.D. Falk wrote: > ...but not for the reasons the anti-ADSP folks keep bringing up. > > DKIM is failing because every discussion about actually /using/ DKIM > inevitably gets stuck in the same old argument about ADSP. Doesn't even > matter what the argument is about anymore; it stops all forward progress > every time. And we keep letting it happen -- actively participating, even, > including me. > > Continuing to argue these same points over and over is disrespectful of our > colleagues both on and off this list, and of the IETF process. > > So I'm going to stop, and I beg you all to join me. > > Stop arguing, and start writing drafts. Let us discuss the drafts instead of > attacking each others' intractable positions for the Nth time. If you think > ADSP will bring about the end of all human communication, WRITE A DRAFT > EXPLAINING WHY. If you think something else, write that instead. > > Yes, I know it requires more effort, but what we've been doing so far clearly > isn't working.
The problem is that the two things have badly conflicting requirements. DKIM is based on a domain-based identifier that's independent of the From: domain, and that's where much of it's value comes from. ADSP is based on a domain-based identifier that must remain identical to the From: field at all times, and that's where it's sole value comes from. ADSP intrinsically conflicts with the original design case for DKIM, despite being piggy-backed on to it. So any document that puts forth even basic good practices for DKIM usage for monitoring sender reputation (use d= to differentiate mail streams) is going to be anathema to ADSP requirements (d= must be the same as the From: domain). And any ADSP-driven set of requirements (mailing lists should not only re-sign any mail they re-send, they should alter the From: address to match) is going to be considered nonsensical by people who consider DKIM a way to tie an identity cookie to a message. And, as we've seen, any compromise document is hated by pretty much everyone, even assuming you can get there. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
