[
https://issues.apache.org/jira/browse/JAMES-4218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18104679#comment-18104679
]
Benoit Tellier commented on JAMES-4218:
---------------------------------------
While James is RFC-wise in its right,
My feeling is that we miss manages unsollicited notifications here.
- APPEND should likely trigger flag related unsollicited notifications
- SELECT should reset state of applicable flags not to double emmit them
I did put together a fix regarding this:
https://github.com/apache/james-project/pull/3109
> SEARCH issue with Roundcube
> ---------------------------
>
> Key: JAMES-4218
> URL: https://issues.apache.org/jira/browse/JAMES-4218
> Project: James Server
> Issue Type: Improvement
> Components: IMAPServer
> Reporter: Benoit Tellier
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Reported by Felix Audriger cf
> https://www.mail-archive.com/[email protected]/msg17270.html
> {code:java}
> I am currently testing the performance of IMAP search with the postgres
> distribution of James to see whether it is sufficient for our relatively
> small
> use case.
> The following are two excerpts of the communication between our webmail
> client
> Roundcube and the James IMAP service:
> C: A0005 UID SEARCH RETURN (ALL) HEADER SUBJECT "Something completely unknown"
> S: * ESEARCH (TAG "A0005") UID
> S: * FLAGS (\Answered \Deleted \Draft \Flagged \Seen $Forwarded NonJunk)
> S: * OK [PERMANENTFLAGS (\Answered \Deleted \Draft \Flagged \Seen $Forwarded
> NonJunk \*)] Limited
> S: A0005 OK SEARCH completed.
> C: A0005 UID SEARCH RETURN (ALL) HEADER SUBJECT DAB
> S: * ESEARCH (TAG "A0005") UID ALL 285
> S: * FLAGS (\Answered \Deleted \Draft \Flagged \Seen $Forwarded NonJunk)
> S: * OK [PERMANENTFLAGS (\Answered \Deleted \Draft \Flagged \Seen $Forwarded
> NonJunk \*)] Limited
> S: A0005 OK SEARCH completed.
> I am a little bit surprised by the reply lines starting with `* FLAGS` and `*
> OK`.
> According to the ABNF in the IMAP RFC
> (https://datatracker.ietf.org/doc/html/rfc3501#section-9), they are valid
> versions of `response-data`.
> However, I do not see any documentation for it in the SEARCH response
> description (https://datatracker.ietf.org/doc/html/rfc3501#section-7.2.5) or
> the UID command description
> (https://datatracker.ietf.org/doc/html/rfc3501#section-6.4.8).
> I also don't see anything in the RFC regarding ESEARCH
> (https://datatracker.ietf.org/doc/html/rfc4731).
> Roundcube chokes on the line starting with `* FLAGS` if there is no result
> (second communication) because it tries to parse the flags as message UIDs
> and
> fails.
> Roundcube should probably stop parsing at the end of the line. However, I do
> not understand why James returns all the flags and I am unsure whether this
> is
> standard-compliant behavior.
> Does somebody know the meaning of those response lines or encountered a
> similar
> problem?
> As contrast, here are the same requests against a Dovecot IMAP server:
> C: c UID SEARCH RETURN (ALL) HEADER SUBJECT "Something completely unknown"
> S: * ESEARCH (TAG "c") UID
> S: c OK Search completed (0.026 + 0.000 secs).
> C: a UID SEARCH RETURN (ALL) HEADER SUBJECT DAB
> S: * ESEARCH (TAG "a") UID ALL 7774
> S: a OK Search completed (0.006 + 0.000 secs).
> Both of them are parsed correctly by Roundcube.
> Best regards,
> Felix
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
