Re: [Jmap] Submission

["Adrien de Croy" <[e-mail]>]

------ Original Message ------
From: "John Levine" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Sent: 21/04/2017 12:13:29 PM
Subject: Re: [Jmap] Submission

>In article <emf1bd45c2-f07e-45ca-a51f-46c5107b65c7@bodybag> you write:
>>
>>My first impression is that if we considered the entire gamut of ESMTP
>>submission extensions, most would not be relevant for the client, and
>>therefore most would not need to be reflected in JMAP.
>
>I haven't heard anyone demand that JMAP support every SMTP extension.
>That would be ridiculous -- no SMTP or submission server supports them
>all, either.
>
>But what we do need is an architecture that can pass through whatever
>extensions the server wants to support, without needing to revise JMAP
>each time there's a new extension.
which server?  The upstream SMTP one?

I think trying to pass through SMTP extensions when there may not even 
be an upstream SMTP server is going to be problematic let alone ugly.

Which extensions do we think are even in scope for this?


>
>
>>  Even things like 8BITMIME should be the default, mandatory in the
>>  client<->JMAP server and if the upstream SMTP system needs to redo
>>  the message then that's what it needs to do.
>
>Those of us who apply DKIM signatures would be very unhappy with that
>misdesign.  Sure, an MUA on a phone isn't likely to do that, but
>consider my example of list management software running through JMAP,
>they do it all the time.
So in 100 years we will still be using the 7-bit limbo pole everyone has 
to go under

We need to move past the 1960s.

When will we abandon 7-bit?

Sounds like DKIM didn't think through the need to transform mail. What 
does a server do right now when an SMTP server needs to send 8bit mail 
to a server that doesn't advertise 8BITMIME?  Bounce it? There should be 
a lossless transform that DKIM could cope with.

I suspect many MTAs will happily accept binary mail, but just don't 
advertise 8BITMIME because all the other requirements were far too 
onerous.

Adrien

>
>
>R's,
>John
>
>_______________________________________________
>Jmap mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/jmap