Yesterday, 250k IPs we talked to for SMTP advertised BINARYMIME. The
largest advertiser we saw was Hotmail/Outlook.
Trying 65.55.37.104...
Connected to mx1.hotmail.com.
Escape character is '^]'.
220 COL004-MC3F10.hotmail.com Sending unsolicited commercial or bulk e-mail
to Microsoft's computer network is prohibited. Other restrictions are found
at http://privacy.microsoft.com/en-us/anti-spam.mspx. Wed, 25 Mar 2015
13:24:42 -0700
EHLO foo
250-COL004-MC3F10.hotmail.com (3.21.0.161) Hello [72.14.229.81]
250-SIZE 36909875
250-PIPELINING
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-STARTTLS
250-AUTH LOGIN
250-AUTH=LOGIN
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...
Brandon
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
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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp