On 8/21/2010 6:06 PM, Daniel Black wrote:
Taking an approach saying we don't care if DKIM survives MLMs
is a step in the opposite direction. This is not a proposal I support.
Not really, since it was known from the start that survival through an MLM is
highly problematic and the steps towards helping survival were known to be
quite
limited.
Requiring survival is a change in DKIM's goals, as well as raising a massive
barrier to adoption, given the history of a) challenge in adoption for any
infrastructure sequence, and b) resistance by MLM developers and operators.
In other words, this line of efforts is seeking to raise the requirements for
DKIM. Absent compelling and demonstrated functional need, that makes it at
best
a distraction and at worst counter-productive for DKIM's main purpose.
DKIM's main purpose is assessment by reputation filtering engines. The most
important reputations to assess are the entities that are 'responsible' for
message. An MLM creates the message. That the message might look a lot like
one sent /to/ it is nice, but it's also confusing. The original author is not,
ultimately, responsible for what the MLM chooses to send.
S/MIME already does that, with a suitable pointer.
S/MIME was design to protect body content, not an entire message.
All of this prompts a repeat of an underlying question: What is the purpose of
this exercise and how is it justified within the charter?
With respect to MLMs, I thought the focus was on documenting realities and
passing through MLMs and to explore issues and opportunities better integrate
MLMs into DKIM. That's quite different from trying to alter the core DKIM
capability to support survival through MLMs. I'm pretty sure that changing
DKIM
Core is not within our charter.
As for MUA considerations, anyone making claims about what is needed for
utility
in an MUA needs to cite their sources, providing empirical justification, not
merely mathematical logic for why utility "ought" to be improved.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html