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