Re: [Jmap] Submission

[Alexey Melnikov <[e-mail]>]

Hi,


On 19/04/2017 14:49, Daniel Kahn Gillmor wrote:
> 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?
I meant the last two.
> 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).
+1.