[Top] [All Lists]

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

2015-03-25 15:32:03
Yesterday, 250k IPs we talked to for SMTP advertised BINARYMIME.  The
largest advertiser we saw was Hotmail/Outlook.

Connected to
Escape character is '^]'.
220 Sending unsolicited commercial or bulk e-mail
to Microsoft's computer network is prohibited. Other restrictions are found
at Wed, 25 Mar 2015
13:24:42 -0700
EHLO foo ( Hello []
250-SIZE 36909875
250 OK

Not reporting BINARYMIME ourselves, but we don't reject binary messages at
the moment and it mostly works through the whole system, but we haven't
gone as far as actually validating the whole pipeline on corner cases to be
happy enough to start advertising it.

Supporting it just for MSA may be a good partial solution...


On Tue, Mar 24, 2015 at 7:38 AM, Ned Freed 
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:

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
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

Arnt, I'm sorry, but that's bunk. And I must say I'm getting pretty tired
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

As for it not being part of our infrastructure, what you actually mean is
"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

And in this instance you now know (because I told you) that you missed a
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
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
outside of the submission space being expressed by some major players here
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
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,
procedural - for dealing with such conflicts when they arise, and my own
suggestion is that we use them.


ietf-smtp mailing list