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