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
