On Wed, Oct 20, 2010 at 09:38:04PM -0700, Murray S. Kucherawy allegedly wrote: > > -----Original Message----- > > From: John R. Levine [mailto:[email protected]] > > Sent: Wednesday, October 20, 2010 5:08 PM > > To: Murray S. Kucherawy > > Cc: [email protected] > > Subject: Re: [ietf-dkim] double header reality check > > > > > Here's maybe a better way to frame the question: Should we empower > > > ourselves to label a DKIM implementation that doesn't do format > > > enforcement as (a) non-compliant, or (b) low-security/low-quality? > > > > The latter. Hey, we agree. I think I always said SHOULD rather than > > MUST. >
> Damn, lost it. I think we should talk about it, and even in detail, > but without using those words. > And I'd be fine converting the MUA advice to which you refer into > something more general, like hammering home the point about what > exactly a validated signature is telling you, and leave it to the > implementers of those modules to figure out what to do with that > information. It's stating the obvious by now, but I'm with (a). While it might be technically elegant to delegate (a) to another layer or some "magic sauce", or some informative text, it misses the bigger picture. That bigger picture is that DKIM has no certainty of success simply by being a technically neat and layer-compliant protocol. DKIM will succeed only if it is picked up and used by a vibrant and wide-spread community of DKIM consumers - MUAs, list servers, reputation systems, email appliances, whatever. Given the well-recognized inertia in the email biz, to maximize our chance of success, we need to make it as easy as possible for this new community of DKIM consumers to succeed. To my mind that means that those consumers can write no-brainer code and reap the benefits of DKIM. So, every time we relegate or delegate parts of DKIM compliance to those consumers - perhaps by way of informative text about 2822 compliance - we are simply creating barriers for the very consumers that we need to make DKIM a success. Are we so confident about DKIM adoption that we feel we can effectively "order" this future community to do this sort of work? I for one am not. I for one think that if we make DKIM as easy as possible to consume and we market the heck out of it, we may, we just may succeed in wide-spread adoption, maybe. So, forget technical elegance. Forget layering violations. What are we doing that makes DKIM compelling and easy to consume? Mark. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
