Re: [Jmap] Submission

Hi,

> On 19 Apr 2017, at 09:31, Adrien de Croy <adrien@qbik.com> wrote:
> 
> 
> OK on delayed send.
> 
> NTP I wouldn't rely on.  I still often see clock divergence.
> 
> but frankly the server parsing the envelope out of the message seems like a hack, which also limits options to a subset of what a sender can do with SMTP.
> 
> Surely it's simple to have a submit command which takes envelope attributes.  That way is deterministic.

Personally I don't care whether it is a separate command versa extra (possibly optional) parameters for envelope on an existing one.

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.

> I agree about option hell, that's one thing I'd like to leave behind with IMAP.
> 
> But parsing messages, scraping an envelope, and stripping unwanted headers seems fragile.  A server failing to strip BCC headers leaks private information.  It's also a lot more work for the server, and no real difference either way for the client.
> 
> Adrien
> 
> 
> 
> 
> ------ Original Message ------
> From: "Neil Jenkins" <neilj@fastmail.com>
> To: "jmap@ietf.org" <jmap@ietf.org>
> Sent: 19/04/2017 7:11:16 PM
> Subject: Re: [Jmap] Submission
> 
>> Yes, the intention is the server will build the RFC5322 message, add and strip headers as appropriate and set the SMTP envelope information. After sending, the server moves the message from the Outbox to Sent, or deletes it and writes a new one if it adds in extra information (since the message is immutable with the same id). This covers everything normal email clients need to do. There are other niche use cases, but JMAP doesn't have to deal with everything. SMTP Submission will still exist, but this simplifies things in the overwhelmingly common case.
>> 
>>> * It requires the client and server clocks to be in synch
>> 
>> Almost every device these days uses NTP or equivalent to set their system clock. We have not observed significant clock skew issues with our client for years.
>> 
>>> * it delays the message (who ever wants to do this?)
>> 
>> You're joking, right? The ability to "undo send" is enormously popular. Being able to do this in a standardised way for desktop clients would be a huge win over the current situation. Normally you would use a window of something like 30 seconds in the future. Scheduled send is also moderately popular in a certain niche.
>> 
>>> * opening a window to cancel the message before it's sent seems a bit nonsensical / contrived to me sorry.  A UA using this is just mainly going to make itself useless for mail conversations by unnecessarily delaying mail.
>> 
>> The UA does not have to delay the send. It can omit setting an explicit date on the message, in which case the server will set the date to now(), and immediately send the message. But the ability to do so for clients that want to make use of this is very important.
>> 
>>> I think submission should be a separate command so that the client can specify needed envelope information independently of the message content.  Even if this were an additional option.
>> 
>> The trouble is options increase complexity and testing requirements. The current spec does not require servers to support delayed send. The canDelaySend capability property lets clients know if it does. Servers that don't support it could even not have a real "outbox" folder but just a synthetic one as anything moved to it is sent immediately (or the move is rejected if the message is invalid).
>> 
>> Neil.
> _______________________________________________
> Jmap mailing list
> Jmap@ietf.org
> https://www.ietf.org/mailman/listinfo/jmap