Based on that (rather precise) description, aren't ADSP's requirements a proper
subset of the DKIM requirements? If so, I'm not sure I agree with "badly
conflicting", but it does frame future discussion quite nicely.
For example, if DKIM enables the identification of mail streams, isn't the one
ADSP covers just a specific instance of a mail stream?
________________________________________
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Steve Atkins
[steve(_at_)wordtothewise(_dot_)com]
Sent: Tuesday, September 14, 2010 3:01 PM
To: DKIM List
Subject: Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
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