Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scheduled / delayed sending is not documented? #373

Open
nekohayo opened this issue Nov 3, 2022 · 3 comments
Open

Scheduled / delayed sending is not documented? #373

nekohayo opened this issue Nov 3, 2022 · 3 comments

Comments

@nekohayo
Copy link

nekohayo commented Nov 3, 2022

Scheduled sending has otherwise been a luxury only available to non-standard implementations with custom interfaces, such as GMail, or Novell Groupwise (if I recall correctly). For me, the usecase for such a feature is this:

  • Marketing, events-related, or personal outreach emails typically have a context/timing-sensitive aspect, so I'd like to be able to schedule them (especially considering the timezone of the person I'm contacting). It also helps productivity tremendously to be able to schedule communications in advance.
  • Humanistic, respectful staff managers and directors know that it is better to schedule mails to staffers to their business hours, avoiding emails that would arrive outside work hours and cause undue stress or cognitive load. Basically, mindfulness for staffers' "right to disconnect".

It seems to me that a key selling point for JMAP could be a standardized way to "schedule send" individual emails, server side via the email client, without resorting to silly client-side hacks like what we've been seeing in the POP+IMAP world. As part of this, the intended UX would also include the ability to edit the scheduled time or cancel the sending, reverting it to a draft, or editing the email's contents before it is sent (all things that I can do with GMail's web UI, which is one of the reasons I'm stuck with GMail).

Surely you must have thought of this, but so far I'm unsure to which extent; I Ctrl+F'ed for "schedul" or "delay" in:

...and only found a single mention, in the "Mail Specification" page, a maxDelayedSend variable. There does not seem to be other similarly-named variables or explanations with the two keywords I used.

So is this part of the spec from the start, and if yes, is it just not well documented? Otherwise, shouldn't it be part of it?

This would probably make for a more compelling protocol pitch to email clients (like Evolution) if you could say "...and you get clean, standardized scheduled sending in Evolution (or Cypht) for free! The docs about that feature are there..."

@mdecimus
Copy link
Contributor

mdecimus commented Nov 4, 2022

Hi,

Scheduled sending is indeed supported by the JMAP Mail specification, the feature is referred to as future release and is covered on page 74 of RFC8621.

In order to schedule a message for delivery at a given time, the EmailSubmission/set request has to include in the envelope the parameter FUTURERELEASE with the syntax described in RFC4865. Once the message has been accepted, the date when the message will be released for delivery can be obtained from the sendAt property with a EmailSubmission/get.

Please note that future release may only be used if the JMAP server advertises the urn:ietf:params:jmap:submission capability and includes the FUTURERELEASE keyword in the submissionExtensions property.

@chibenwa
Copy link
Contributor

chibenwa commented Nov 4, 2022

Maybe we could add this interesting thread on jmap.io in the FAQ section?

@nekohayo
Copy link
Author

nekohayo commented Nov 4, 2022

The only mention of futurerelease I could find was in https://jmap.io/spec-mail.html where there is a sendAt variable (?), which, presuming it is relevant, I would never have found because it does not mention "delaying", "delayed", "scheduled", "scheduling", or "later" delivery.

If possible, I would recommend you pepper the texts with such keywords (without necessarily sounding unnatural, you can use these variations through multiple sentences) wherever possible to make it easier for people and indexers to discover. Currently, even a search engine couldn't find it. "futurerelease" or "sendAt" are not what most people naturally think of when they speak of this functionality, in terms of naming.

I think it would be beneficial to augment the documentation with terminology that most humans expect (and even robots, i.e. SEO). It might be a tiny bit more verbose but it would be clearer and facilitate adoption by being more discoverable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants