Re: [Jmap] Submission

[Daniel Kahn Gillmor <[e-mail]>]

On Wed 2017-04-19 08:28:46 -0400, Ricardo Signes wrote:
> * Alexey Melnikov <[e-mail]> [2017-04-19T05:11:42]
>> I think having parameters for envelope would be a good idea (and it would be
>> consistent with earlier discussions on Submit in IMAP.) But I am wondering if
>> we can make common cases simple for clients by not requiring the parameters.
>
> We discussed envelope parameters at IETF 98, and I hope that we do continue
> forward by making them both possible and optional.

I somehow missed that discussion at IETF 98, but i want to say that i
think that envelope parameters during submission is an important
feature.  MUAs that want their RFC5322 message to go out exactly as they
composed it, but using an arbitrary SMTP envelope should be able to
exercise that level of control via JMAP, without worrying that the
server side is going to parse, interpret, rearrange, or mangle the
standard in-message headers.

Regarding one common mismatch between SMTP envelope and RFC5322 mail
headers:

I think that encouraging an MUA to include an explicit, in-band
Bcc: header in a message that it hands off to a server for delivery is
asking for trouble.



Making the SMTP envelope parameters "optional" needs more specification.
For who are they optional?  how?  optional for JMAP servers to
implement?  optional for JMAP servers to accept?  optional for JMAP
clients to include?  optional for JMAP clients to implement?

My preference (for simplicity, omitting the explicit mechanism and just
calling it "submission"):

 * JMAP servers MUST accept SMTP envelope parameters via the submission
   mechanism

 * JMAP clients MAY decline to provide SMTP envelope parameters when
   invoking the submission mechanism, in which case the JMAP server will
   synthesize SMTP envelope parameters from the submitted message.

 * synthesis of SMTP envelope headers at submission time by the JMAP
   server should leave the message otherwise unchanged.

 * delayed send should be implemented as an explicit envelope parameter,
   not as a parsing of the in-band Date: header.  There are a range of
   reasons why an MUA might want to submit a message with a in-band
   Date: that the server finds objectionable (including server-side
   clock failure).


Regards,

        --dkg