Re: [ietf-smtp] Fwd: I-D Action: draft-melnikov-smtp-metadata-00.txt

[Ned Freed <[e-mail]>]

> Ned Freed writes:
> > Of course another way to look at it is that this is Yet Another Way that
> > DKIM/DMARC is incompatiable with our existing standards and infrastructure.
> > Calling for Yet Another Fix.

> Perhaps. Although in this case I suggest that BINARYMIME isn't part of our
> existing standards and infrastructure, for lack of implementation and
> deployment.

Arnt, I'm sorry, but that's bunk. And I must say I'm getting pretty tired of
this specious line of argument.

RFC 3030 specifies a standards track protocol. That alone is sufficient to
refute your suggestion that this isn't part of our existing standards suite.

As for it not being part of our infrastructure, what you actually mean is that
"I haven't seen it in the wild and some google searches I did and some web
sites I visited turned up no signs of usage".

The problem with that is you don't know everything that's out there. (And
neither do I.) (And neither does anyone else on this list.) What we do know is
that the Internet is a big place, with lots of nooks and crannies we can't see
into.

And in this instance you now know (because I told you) that you missed a use
case you had no insight into: Mobile device submission. Which happens to be a
space where support in a single client can have a rather  large impact.

So your suggestion that there's no deployment is wrong as well.

Now, as it happens the existing deployment is a type that doesn't overlap
existing DKIM usage much if at all. So we haven't had to deal with the
interoperability problem we've created.

And that's OK, I guess, as long as nobody tries to expand the scope of DKIM to
end-to-end scenarios. If you try to do that there's going to be a conflict, and
this time it's going to be DKIM that's in the position of not being deployed in
the relevant space.

And the combination of that along with the apparent desire to use BINARYMIME
outside of the submission space being expressed by some major players here may
be sufficient cause to want to define an encoding-insensitive MIME
canonicalization for use with DKIM.

But more generally, I categorically reject the notion that apparent lack of
deployment of a standard is ipso facto sufficient cause to completely ignore
that standard and to deploy things that fail to interoperate with it. This
strategy is a a sure-fire recipe for creating ongoing operational problems.

Of course this doesn't mean we are bound to respect every standard we ever
created, unchanged, forevermore. But we have ways - technical, expository, and
procedural - for dealing with such conflicts when they arise, and my own
suggestion is that we use them.

				Ned