New MessageSubmission object for sending mail #99

neilj · 2017-07-04T02:14:54Z

No description provided.

chibenwa

I tend to overall like this proposal, which is more explicit.

chibenwa · 2017-07-04T02:43:03Z

spec/mail/messagedelivery.mdown

+- **messageId**: `String`
+  The id of the message to send. This is immutable.
+- **threadId**: `String`
+  The thread id of the message to send. This is immutable and set by the server based on the message.


Can we detail what based on the message means?

chibenwa · 2017-07-04T02:43:44Z

spec/mail/messagedelivery.mdown

+
+    If the *envelope* property is `null` or omitted on creation, the server MUST generate this from the referenced message as follows:
+
+    - **mailfrom**: The email in the *From* header, if present.


Case : mailFrom

chibenwa · 2017-07-04T02:43:56Z

spec/mail/messagedelivery.mdown

+    If the *envelope* property is `null` or omitted on creation, the server MUST generate this from the referenced message as follows:
+
+    - **mailfrom**: The email in the *From* header, if present.
+    - **rcptto**: The deduplicated list of emails from the *To*, *Cc* and *Bcc*


Idem, there is a case issue

chibenwa · 2017-07-04T02:45:22Z

spec/mail/messagedelivery.mdown

+
+- **sendAt**: `Date|Duration|null`
+  The date to release the message for delivery. This is immutable. The server MUST override this property to the current date-time if the value given by the client is omitted, `null`, or in the past, or if the server does not support delayed sending. If a duration is specified, the server MUST set this property to the time of this duration from "now".
+- **maybeCanUnsend**: `Boolean`


I find the naming awkward... I would prefer isCancellable or something like this.

The trouble is it's only "maybe" cancellable; we can never guarantee it's going to be possible to unsound the message.

IMO then sentMaybeCancellable better reflects this. It is the canUnsend that looks strange to me.

chibenwa · 2017-07-04T02:46:41Z

spec/mail/messagedelivery.mdown

+- **maybeCanUnsend**: `Boolean`
+  If `true`, attempting to unsend the message by destroying the MessageDelivery object, *might* succeed. This is server set. On systems that do not support unsending, this will always be `false`. On systems that do this, it will start as `true`, and MAY transition to `false` when the server knows it definitely cannot recall the message, but MAY just remain `true`.
+
+For efficiency, a server MAY destroy MessageDelivery objects a certain amount of time after the message is successfully sent. For very basic SMTP proxies, this MAY be immediately after creation, as it has no way to assign a real id and return the information again if fetched later. For more advanced systems, this might be a week or two later.


In this case we need a isSent method or something similar, no?

chibenwa · 2017-07-04T03:02:49Z

spec/mail/messagedelivery.mdown

+
+If the creation succeeds, the message will be sent to the recipients given in the envelope *rcptTo* parameter. The server MUST remove any *Bcc* header present on the message during delivery. The server MAY add or remove other headers from the submitted message during delivery.
+
+The message being sent does not have to be a draft, for example when "redirecting" an existing message to a different email address.


This needs to be stated above.

chibenwa · 2017-07-04T03:03:29Z

spec/mail/messagedelivery.mdown

+
+The message being sent does not have to be a draft, for example when "redirecting" an existing message to a different email address.
+
+Once the MessageDelivery is created, the referenced message MAY be deleted in the mailstore. This MUST NOT change the behaviour of the message delivery (i.e. it does not cancel a future send).


We need it to be an explicit property of MessageDelivery...

chibenwa · 2017-07-04T03:06:04Z

spec/mail/messagedelivery.mdown

+  The id of the message to send. This is immutable.
+- **threadId**: `String`
+  The thread id of the message to send. This is immutable and set by the server based on the message.
+- **envelope**: `Envelope|null`


I could not find where you define the envelope object...

chibenwa · 2017-07-04T03:07:35Z

spec/mail/messagedeliverylist.mdown

+
+## getMessageDeliveriesList
+
+Standard JMAP getList method.


This is not very clear to a newcomer...

chibenwa · 2017-07-04T03:08:48Z

spec/mail/messagedelivery.mdown

+After the *messagesDeliveriesSet* response is emitted, if the *update* object is not empty, an implicit call is made to *setMessages*, with the following arguments:
+
+- **accountId**: Same as for the call to *setMessageDeliveries*.
+- **update**: The *update* object as calculated above.


You do not define what an update is. In my opinion, the knowledge of the required update should be explicitly embedded to MessageDelivery.

The update object is defined in the paragraph above:

For each successful create/destroy, the server should see if there is an entry with the same id in the onCreateUpdateMessage/onDestroyUpdateMessage properties respectively. If so, add an entry to an (initially empty) update object, with the key being the messageId on the MessageDelivery object that was created/destroyed, and the value being the value from the onCreateUpdateMessage/onDestroyUpdateMessage object.

neilj · 2017-07-04T05:14:09Z

I've tried to clarify the wording a bit. Hopefully some of the more gnarly bits are clearer now.

chibenwa · 2017-07-04T07:03:32Z

spec/mail/messagedelivery.mdown

+    This is how a message may be unsent.
+
+- **onCreateUpdateMessage**: `String[Message]`
+  A map of *creation id* to an object containing properties to update on the Message object referenced by the MessageDelivery if the create succeeds.


Tell me if I'm wrong: Here the Message only needs to be a subset of Message Mutable properties, hence Keywords, right? **Keywords is the only mutable unit of a message, right? Then why do we need to pass more when a bag of keyword is enough?

MailboxIds are also mutable. IMO we should explain here only mutable property should be changed, and we should list them.

chibenwa · 2017-07-04T07:04:07Z

spec/mail/messagedelivery.mdown

+- **onCreateUpdateMessage**: `String[Message]`
+  A map of *creation id* to an object containing properties to update on the Message object referenced by the MessageDelivery if the create succeeds.
+- **onDestroyUpdateMessage**: `String[Message]`
+  A map of *MessageDelivery id* to an object containing properties to update on the Message object referenced by the MessageDelivery if the destroy succeeds.


Updating a message is cool.

We should be also able to delete them. IE: delete draft upon send. Then maybe we need a: onDeleteDeleteMessage String

chibenwa · 2017-07-04T07:15:55Z

As stated on the ML, the envelope needs to specify (as optional) the identity to be used by the sender (http://jmap.io/spec-mail.html#identities)

jeffpc · 2017-07-27T11:41:59Z

spec/mail/message.mdown

- **mailboxIds**: This property MUST be included. The value MUST include the id of either the mailbox with `role == "drafts"` (to save a draft) or the mailbox with `role == "outbox"` (to send the message). If this mailbox does not have `mustBeOnlyMailbox == true`, others may be included too.
- **keywords**: This property MUST be included. It MUST include the `$Draft` keyword and SHOULD also include `$Seen`.
+- **mailboxIds**: This property MUST be included, and contain at least one mailbox.
+- **keywords**: This property MUST be included. If the message is a draft, it SHOULD include the `$Draft` and `$Seen` keywords.


"If the message is a draft..." is a bit redundant given that the section name is "Saving a draft".

Good catch. The title of the section should really be just Creating a message, but should reference saving a draft the primary example.

jeffpc · 2017-07-27T12:00:50Z

spec/mail/message.mdown

@@ -276,12 +273,12 @@ The properties of the Message object submitted for creation MUST conform to the
 - **bcc**:  Optional. Overrides a "Bcc" in the *headers*.
 - **replyTo**: Optional. Overrides a "Reply-To" in the *headers*.
 - **subject**: Optional. Defaults to the empty string (`""`).
- **date**: Optional. If included, the server SHOULD wait until this time to send the message (once moved to the outbox mailbox). Until it is sent, the send may be cancelled by moving the message back out of the outbox mailbox. If the date is in the past, the message must be sent immediately. A client may find out if the server supports delayed sending by querying the server's *capabilities* object (see section 1).
+- **date**: Optional. Overrides a "Date" in the *headers*.


headers's keys are supposed to be lowercased, so this should probably say "date".

What does "overrides" mean here? I'm reading it as (assuming that the server stores mails in RFC5322 format) the server is supposed to replace the "date" header's value with whatever is supplied here (after converting it from RFC 3339 to RFC 5322 format) before storing it on disk. Is the intention here to be able to supply the original headers, but fix up the date without having to parse 5322-style dates?

Yep, I'll lower case these.

The date/to/cc/bcc/from/replyTo fields are all parsed representations that could also be represented in raw form in the headers property. This is simply specifying what the server should do if the client supplies both for some reason: Take the parsed one and blat the one in the "headers" property. I'll rewrite this description to be clearer.

jeffpc · 2017-08-02T12:38:55Z

spec/mail/messagesubmission.mdown

+
+    This is how a message is sent.
+
+- **update**: `String[MessageSubmission]`


Should update also allow null?

Yes, will fix.

jeffpc · 2017-08-02T12:43:12Z

spec/mail/messagesubmission.mdown

+
+### Destroying a MessageSubmission object
+
+Destroying a MessageSubmission object MUST NOT affect the delivies it represents. It purely removes the record of the message submission. The JMAP server MAY reject attempts by a client to destroy a MessageSubmission with a `forbidden` error. The server MAY automatically destroy MessageSubmission objects after a certain time or in response to other triggers.


Sanity check: So, a valid implementation of message submission is:

setMessageSubmissions takes the content, and (if valid) synchronously hands off the mail to the MTA

getMessageSubmissions always returns notFound

getMessageSubmissionUpdates always returns cannotCalculateChanges

getMessageSubmissionLists always returns an empty array

A quality client will need to deal with responses 2-4 regardless of what the spec says so it's not a big ask of client authors to allow this. The tricky part with standard design is to balance deployability with mandatory functionality and predictability. I believe we want to allow this server behavior to simplify deployability. In addition, if JMAP is playing the role of mail submission API in a larger cloud server, this behavior is just fine. However, this server behavior will result in an inferior experience for a client that supports status/recall of sent messages.

@jeffpc: Yes, this is a valid (very basic) implementation. As cjnewman said, clients have to be able to deal with these responses anyway.

rsto · 2017-08-28T16:09:36Z

spec/mail/messagesubmission.mdown

+    - **email**: `String`
+      The email address being represented by the object. This as a "Mailbox" as used in the Reverse-path or Foward-path of the MAIL FROM or RCPT TO command in [@!RFC5321
+    - **parameters**: `Object|null`
+      Any parameters to send with the email (either mail-parameter or rcpt-parameter as appropriate, as specified in [@!RFC5321]). If supplied, each key in the object is a parameter name, and the value the parameter value. In both cases, any xtext or unitext encodings are removed ([@!RFC3461], [@!RFC6533]) and JSON string encoding applied.


RFC 5321, section 4.1.2 defines a SMTP parameter as

esmtp-param = esmtp-keyword ["=" esmtp-value]

I guess a SMTP parameter without value is encoded in JMAP as an object key with value null?

Yes. I'll add this explicitly to the spec.

Resolves #124

Resolves #128

chibenwa reviewed Jul 4, 2017

View reviewed changes

neilj force-pushed the sending branch from 3ab85c1 to c264664 Compare July 4, 2017 05:10

chibenwa reviewed Jul 4, 2017

View reviewed changes

neilj force-pushed the sending branch from c264664 to bd03b1f Compare July 5, 2017 06:18

neilj force-pushed the sending branch from bd03b1f to 41b8a0f Compare July 19, 2017 15:16

neilj changed the title ~~New MessageDelivery object for sending mail~~ New MessageSubmission object for sending mail Jul 19, 2017

neilj force-pushed the sending branch 4 times, most recently from 3d76751 to 7089f3f Compare July 21, 2017 09:25

jeffpc reviewed Jul 27, 2017

View reviewed changes

jeffpc reviewed Aug 2, 2017

View reviewed changes

neilj force-pushed the sending branch from 7089f3f to 8d7f32d Compare August 28, 2017 01:40

neilj mentioned this pull request Aug 28, 2017

Add submissionExtensions to capability object #128

Closed

neilj force-pushed the sending branch from 8d7f32d to b9b0e2e Compare August 28, 2017 06:54

rsto reviewed Aug 28, 2017

View reviewed changes

neilj force-pushed the sending branch from 6b97fb2 to 0209c1f Compare August 31, 2017 01:24

neilj added 4 commits September 4, 2017 13:28

Replace "move to Outbox" with MessageSubmission object

02b428c

Resolves #124

Add submissionExtensions capability

e655b86

Resolves #128

Revisions based on Chris Newman's comments

7052fc4

Fix out of date description

e1399a8

neilj force-pushed the sending branch from 9a81440 to e1399a8 Compare September 4, 2017 03:28

neilj added 3 commits September 4, 2017 13:36

Clarify ACL restrictions on mailboxes

89ce529

SMTP parameters without a value map to null

0ae9b47

DSNs can update smtpReply value

40ded1f

neilj force-pushed the sending branch from 6350679 to 40ded1f Compare September 18, 2017 04:45

neilj merged commit ab01e36 into master Sep 18, 2017

neilj deleted the sending branch September 18, 2017 04:47

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

New MessageSubmission object for sending mail #99

New MessageSubmission object for sending mail #99

neilj commented Jul 4, 2017

chibenwa left a comment

chibenwa Jul 4, 2017

chibenwa Jul 4, 2017

chibenwa Jul 4, 2017

chibenwa Jul 4, 2017

neilj Jul 4, 2017

chibenwa Jul 4, 2017

chibenwa Jul 4, 2017

chibenwa Jul 4, 2017

chibenwa Jul 4, 2017

chibenwa Jul 4, 2017

chibenwa Jul 4, 2017

chibenwa Jul 4, 2017

neilj Jul 4, 2017

neilj commented Jul 4, 2017

chibenwa Jul 4, 2017

chibenwa Jul 4, 2017

chibenwa Jul 4, 2017 •

edited

Loading

chibenwa commented Jul 4, 2017 •

edited

Loading

jeffpc Jul 27, 2017

neilj Aug 28, 2017

jeffpc Jul 27, 2017

neilj Aug 28, 2017

jeffpc Aug 2, 2017

neilj Aug 28, 2017

jeffpc Aug 2, 2017

cjnewman Aug 2, 2017

neilj Aug 4, 2017

rsto Aug 28, 2017

neilj Sep 11, 2017


		If the envelope property is `null` or omitted on creation, the server MUST generate this from the referenced message as follows:

		- mailfrom: The email in the From header, if present.


		If the creation succeeds, the message will be sent to the recipients given in the envelope rcptTo parameter. The server MUST remove any Bcc header present on the message during delivery. The server MAY add or remove other headers from the submitted message during delivery.

		The message being sent does not have to be a draft, for example when "redirecting" an existing message to a different email address.


		The message being sent does not have to be a draft, for example when "redirecting" an existing message to a different email address.

		Once the MessageDelivery is created, the referenced message MAY be deleted in the mailstore. This MUST NOT change the behaviour of the message delivery (i.e. it does not cancel a future send).


		This is how a message is sent.

		- update: `String[MessageSubmission]`


		### Destroying a MessageSubmission object

		Destroying a MessageSubmission object MUST NOT affect the delivies it represents. It purely removes the record of the message submission. The JMAP server MAY reject attempts by a client to destroy a MessageSubmission with a `forbidden` error. The server MAY automatically destroy MessageSubmission objects after a certain time or in response to other triggers.

New MessageSubmission object for sending mail #99

New MessageSubmission object for sending mail #99

Conversation

neilj commented Jul 4, 2017

chibenwa left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

neilj commented Jul 4, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chibenwa Jul 4, 2017 • edited Loading

Choose a reason for hiding this comment

chibenwa commented Jul 4, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chibenwa Jul 4, 2017 •

edited

Loading

chibenwa commented Jul 4, 2017 •

edited

Loading