[jira] [Commented] (JAMES-4218) SEARCH issue with Roundcube

    [ 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)