Re: [Jmap] Submission

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

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.

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" <[e-mail]>
To: "[e-mail]" <[e-mail]>
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.