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
