ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] double header reality check

2010-10-21 01:03:22
On Wed, Oct 20, 2010 at 09:38:04PM -0700, Murray S. Kucherawy allegedly wrote:
-----Original Message-----
From: John R. Levine [mailto:johnl(_at_)iecc(_dot_)com]
Sent: Wednesday, October 20, 2010 5:08 PM
To: Murray S. Kucherawy
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
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