[JAMES-3543] Implement EmailSubmission storage (/get /set update+destroy /changes)

• Type: Sub-task
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 3.6.0
• Component/s: JMAP
• Assignee: Antoine Duprat
• Reporter: Benoit Tellier
• Created: 04/Apr/21 14:34
• Updated: 04/Apr/21 14:34

Description

In order to deliver a good subset of the JMAP RFC-8621 implementation in a timely fashion, we did only implement EmailSubmission/set create in a shoot and forget fashion, without underlying storage setted up.

This, however, do not enable advanced usage of a submission server (tracking delivery status, cancelling sends, seeing related MDNs and DSNs, etc...).

To benefit from these features, one would need to implement persistance for EmailSubmission (API and contract test in server/data/data-jmap + memory + cassandra implementations). A per account changelog for EmailSubmission would also be needed for the /changes method. And finaly the /query endpoint would likely require indexation in ElasticSearch, and a scrolling search for memory.

Needless to say, this is expensive to write.

We might consider naive versions in a temporary fashion, in order to improve spec compliance:

• EmailSubmission/get could always return notFount.
• EmailSubmission/query always returns empty
• EmailSubmission/set update could be always rejected
• EmailSubmission/set destroy could be always rejected

That would technically be enough for spec compliance.

This might help interoperability with clients implementing advanced submission features (and expecting them to be here - ie via the use of back-references)