On May 26, 2010, at 7:45 AM, Brett McDowell wrote:
On May 25, 2010, at 8:43 PM, Scott Kitterman wrote:
Like I said, "throw away anything that doesn't have our signature" has
some chance of broad adoption. Every extra word you add to the message
makes it less likely that people will do it.
I agree with this. I have yet to see any proposals for additions that didn't
either add enough complexity to act as a barrier to deployment or
alternately make it trivially possible to allow third parties to create
messages that render discardable moot.
I agree that adding anything to "throw away anything that doesn't have our
signature" add complexity to implementation and therefore, by definition, is
a barrier to adoption. That's not what we are debating. What we are
debating is whether such complexity is a necessary evil that we should
provide a specification to support -- as an optional mechanism for
stakeholders who want to opt-in to the authenticated email ecosystem. I
*think* the answer is "yes". But we haven't yet had the meaningful debate
that will resolve that question.
Let's debate whether transient trust through a MLM is actionable. Would a
new header that enabled the MLM to report to the receiver that they indeed
validated the original signature actually make any difference in the
deliverability of that message to the receiver, and if yes, is that actually
a good thing? I say "yes" and "yes". But I expect that if we debate this
specific point one of you might highlight an unintended consequence that
would tip the balance away from pursuing such a model.
Thoughts?
Aesthetically I like the idea of some way for the MLM to tunnel authentication
information through to the recipient.
But I don't think it's clear that doing so would change anything at the
recipients MX. As a concrete example, if two subscribers to a mailing list send
mail to the list, one DKIM signed and one not, and the list then signs each
message and sends it to the recipient, is there any reason that the recipients
MX would treat those two messages differently?
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html