Re: [ietf-smtp] [Proposal] confusing parts of the mail system, was 250-MARKDOWN

[John Bucy <[e-mail]>]

On Thu, Jan 10, 2019 at 9:43 AM Gene Hightower <[e-mail]> wrote:

> On 10/01/2019 08.03, Ned Freed wrote:
>
> >> On 09/01/2019 06.35, John Levine wrote:
> >
> >>> My mail server doesn't support or understand any media types at all.
> >>> MIME and media types are all handled in the MUA.
> >
> >> I agree, except for BINARYMIME: the one MIME type advertised in the
> >> greeting stage of ESMTP.
> >
> > Binary is a content transfer encoding, not a media type.
>
> Yes, correction: transfer encoding, not media type.
>
> Let me try to restate my point using a few more words.
>
> The area where MTA (the “mail server” from above) software needs to
> announce support for a protocol feature to enable features at the
> level of the message body is CHUNKING and BINARYMIME, RFC 3030.
>
> If many of the leading figures in the email world can engage in a
> lively discussion about a proposed MARKDOWN extension to SMTP, I
> thought I'd try to raise some interest in BINARYMIME.
>
> On 10/01/2019 08.03, Ned Freed wrote:
>
> > But the availability of the technology doesn't mean people will use
> > it. The asessment of most seems to be that the benefits don't
> > outweigh the costs.
>
> First step is CHUNKING; small benefit, modest cost.  Involves MTAs.
>
> Next step is BINARYMIME; much larger benefit, much larger cost.
> Involves storage formats (no mbox) and IMAP software and MUAs; the
> whole email ecosystem.
>
> We know CHUNKING is doable, Microsoft and Google both do it.
> (I also do it.)
>
> Question is, is BINARYMIME doable?  Or a lost cause?
>

As I see it, the problem is a message getting stuck "in the middle" where
the next hop doesn't support the extension e.g. user has a .forward file.
The most obvious options to me are:
1. downgrade the message from binary to base64. dmarc made this infeasible
at least for senders that use it but I'm hopeful that arc can fix that. Not
sure about s/mime.
2. An MTA could not accept an extension for a particular recipient if it
isn't sure that there is no next hop or the next hop supports it (i.e. fail
RCPT) so that this can be pushed all the way back to submission. I think we
identified the correct extended status for this for (at least) binarymime
and smtputf8 in a previous thread.

With respect to deploying extensions, sites with millions of mailboxes
- want to gradually deploy any new feature rather than knifeswitch to
everyone at once
- may have a long tail of mailboxes that take a long time to upgrade (e.g.
gateways to a legacy system) and it would be nice for the 99% to get the
benefit sooner



cheers
john