You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Benoit Tellier (Jira)" <se...@james.apache.org> on 2021/04/04 14:35:00 UTC

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

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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org