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

[Brandon Long <[e-mail]>]

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 <[e-mail]> 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
>