Benoit Tellier created JAMES-3543:
-------------------------------------
Summary: Implement EmailSubmission storage (/get /set
update+destroy /changes)
Key: JAMES-3543
URL: https://issues.apache.org/jira/browse/JAMES-3543
Project: James Server
Issue Type: Sub-task
Components: JMAP
Affects Versions: 3.6.0
Reporter: Benoit Tellier
Assignee: Antoine Duprat
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)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
