On 8/23/10 8:05 PM, Dave CROCKER wrote: > > 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.
Agreed. > DKIM's main purpose is assessment by reputation filtering engines. > The most important reputations to assess are the entities that are > 'responsible' for message. Strongly Disagree. The SMTP client represents the most important entity responsible for issuing the message. DKIM was never intended to provide a reputational basis for email acceptance. DKIM does not indicate where a message had been initially sent. It may indicate who initially handled a beginning portion of the message body, but this limitation fails to provide an adequate basis upon which reputations can be based. A primary criteria for assessing unsolicited email is where the message had been sent, especially when content is of little benefit to its recipient. As such, efforts to accept IPv6 email is unlikely to find DKIM a suitable basis. Perhaps soon SMTP can develop an SMTP Auth that combines use of a DKIM key together with a work product of keyassure. Identification of the SMTP client truly represents the entity responsible for issuing undesired messages. After all, the bulk of today's email would be extremely difficult to categorize based upon the possible presence of DKIM signatures. In special cases, where the entirety of users within a domain is trusted, DKIM then provides a method in which a recipient can both accept these messages, and possibly identify suspicious messages that might be attempting to mislead the recipient. Unfortunately, DKIM lacks a suitable policy construct that is better able to assist recipients, even with this small fraction of emails, due to issues related to third-party services. DKIM ensures the authentication status of users on whose behalf a message was signed remains unknown. For a small fraction of the domains, DKIM might offer recipients a basis for sorting messages into trusted and suspicious categories. As such, for the majority of messages, the only reputation upon which acceptance can be based is that of the SMTP client. > 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. Agreed. This affirms the SMTP client represents the important entity for what is being sent. > >> 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. Agreed. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
