Interesting. And no, it’s not brutal at all, Dovecot should be able scale to millions of messages. Could you check if that happens again with Dovecot 2.2.13 (upgraded in early May)? If yes, could you type the following in a shell and see if that works for you? (The ‘S:’ prefixes denote server output; the ‘C:’ prefixes denote client input.)

$ openssl s_client -connect imap.fripost.org:993 -CApath /etc/ssl/certs
S: […]
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
C: a LOGIN guilhem "my top secret password"
S: a OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS SPECIAL-USE BINARY MOVE NOTIFY] Logged in
C: b EXAMINE INBOX
S: […]
S: b OK [READ-ONLY] Examine completed (0.000 secs).
C: c UID SEARCH RETURN (ALL) UNDELETED TEXT blah
S: c OK Search completed (7.224 secs).
C: d LOGOUT
S: * BYE Logging out
S: d OK Logout completed.

If I try in roundcube, it serches for a while and then tells me it didn’t find anything (but it should!).

If I try with openssl (same query), it seems to work (note that the problem happens with virtual/all, not with INBOX).

Roundcube might have killed the connection due to the IMAP timeout. (Since HTTP is stateless, each user event triggers a IMAP connection.) How long did the the search take on the terminal (7.224 secs in my example)? We might have to raise the timeout.