Hello Felix, Thanks for the report.
I opened https://issues.apache.org/jira/browse/JAMES-4218 in order to track this. 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 notificationsSELECT should reset state of applicable flags not to double emmit themI did put together a fix regarding this: https://github.com/apache/james-project/pull/3109 Would this solve your issue? Can you give it a try?-- Best regards, Benoit TELLIER General manager of Linagora VIETNAM. Product owner for Twake-Mail product. Chairman of the Apache James project. Mail: [email protected] Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) On Aug 13, 2026 11:19 PM, from Felix Auringer <[email protected]>Hey, 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 (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 (datatracker.ietf.org/doc/html/rfc3501#section-7.2.5) or the UID command description (datatracker.ietf.org/doc/html/rfc3501#section-6.4.8). I also don't see anything in the RFC regarding ESEARCH (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 --- Gesellschaft für interkulturelles Zusammenleben gGmbH (GIZ) Felix Auringer IT Reformationsplatz 2 13597 Berlin Tel: 030/513 0100 00; Fax: 030/513 0100 09 giz.berlin; [email protected] Amtsgericht Charlottenburg HRB 200872 B Geschäftsführerin: Dr. Britta Marschke --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
