linagora / james-project

Mirror of Apache James Project
Apache License 2.0
72 stars 62 forks source link

IMAP4Rev2 and needed modifucation for support... #4532

Open chibenwa opened 2 years ago

chibenwa commented 2 years ago

https://datatracker.ietf.org/doc/html/rfc9051

Especially https://datatracker.ietf.org/doc/html/rfc9051#appendix-E

vttranlina commented 2 years ago

Changes list

Changes Status Note
1. Support for 64-bit message and body part sizes.
2. Folded in IMAP NAMESPACE [RFC2342], UNSELECT [RFC3691], UIDPLUS [RFC4315], ESEARCH [RFC4731], SEARCHRES [RFC5182]... Supported
3. Added STATUS SIZE [RFC8438] and STATUS DELETED. NOT Implemeneted yet
4. SEARCH command now requires to return the ESEARCH response (SEARCH response is now deprecated). Supported rfc5182
5. Clarified which SEARCH keys have to use substring match and which don't. Supported
6. Clarified that the server should decode parameter value continuations as described in [RFC2231]. This requirement was hidden in [RFC2231] itself. Supported
7. Clarified that the COPYUID response code is returned for both MOVE and UID MOVE. Supported rfc6851
8. Tightened requirements about COPY/MOVE commands not creating a target mailbox. Also required them to return the TRYCREATE response code, if the target mailbox doesn't exist and can be created. Not implemented RFC2060, James return TRYCREATE, but untagged response
9. Added the CLOSED response code from [RFC7162]. SELECT/EXAMINE when a mailbox is already selected now requires a CLOSED response code to be returned. Supported
10. SELECT/EXAMINE are now required to return an untagged LIST response.
11. UNSEEN response code on SELECT/EXAMINE is now deprecated. Not a change
12. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS, and SEARCH NEW items are now deprecated. Not a change
13. Clarified that the server doesn't need to send a new PERMANENTFLAGS response code when a new keyword was successfully added and the server advertised * earlier for the same mailbox. Not a change
14. For future extensibility, extended ABNF for tagged-ext-simple to allow for bare number64.
15. Added SHOULD level requirement on IMAP servers to support $MDNSent, $Forwarded, $Junk, $NonJunk, and $Phishing keywords. Implemented (we support custom flags)
16. Mailbox names and message headers now allow for UTF-8. Support for modified UTF-7 in mailbox names is not required, unless compatibility with IMAP4rev1 is desired. NOT Implemeneted yet Right now is supporting UTF-7
17. Removed the CHECK command. Clients should use NOOP instead. Support both
18. RFC822, RFC822.HEADER, and RFC822.TEXT FETCH data items were deprecated. Clients should use the corresponding BODY[] variants instead. Not a change
19. LSUB command was deprecated. Clients should use LIST (SUBSCRIBED) instead. NOT Implemeneted yet - LIST (SUBSCRIBED)
20. IDLE command can now return updates not related to the currently selected mailbox state. NOT Implemeneted yet IDLE current now is only update a selected mailbox
21. All unsolicited FETCH updates are required to include UID. Not implemented
22. Clarified that client implementations MUST ignore response codes that they do not recognize. (Changed from a SHOULD to a MUST.) No server changes
23. resp-text ABNF non-terminal was updated to allow for empty text.
24. After ENABLE, IMAP4rev2 human-readable response text can include non-ASCII encoded in UTF-8. HumanReadableText is hard code => NOTHING
25. Updated to use modern TLS-related recommendations as per [RFC7525], [RFC7817], and [RFC8314]. Done
26. Added warnings about use of ALERT response codes and PREAUTH response. Supported RFC2060
27. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST- MD5 was deprecated. James is not support DIGEST-MD5 SASL mechanism => NOTHING
28. Clarified that any command received from the client resets server autologout timer. It is the case today
29. Revised IANA registration procedure for IMAP extensions and removed "X" convention in accordance with [BCP178]. Not a change
30. Loosened requirements on servers when closing connections to be more aligned with existing practices. No problem too
chibenwa commented 2 years ago
  1. do we return the TRYCREATE untagged response?
chibenwa commented 2 years ago
  1. Can != Should. We thus are not required to return all changes.
chibenwa commented 2 years ago

CF https://issues.apache.org/jira/browse/JAMES-3754

vttranlina commented 2 years ago
  1. do we return the TRYCREATE untagged response?

Yes,


// sample
a3 COPY 1 new-inbox
a3 OK [COPYUID 1149147738 1 1] COPY completed.
a4 COPY 1 new-inbox2
a4 NO [TRYCREATE] COPY failed. No such mailbox.
a5 MOVE 1 new-inbox2
a5 NO [TRYCREATE] MOVE failed. No such mailbox.