imapproxy is **terrible** when it comes to handling the instance where 
it's connection to the backend is broken.  From the client 
perspective, it is impossible to know that the underlying connection 
has been destroyed.

Horde/IMP tries to cache connection details when using imapproxy so we 
don't have to send the same commands over and over again.  If 
imapproxy doesn't report the error from the underlying server, Horde 
doesn't know that it has to clear its internal IMAP state cache.

There's really no reason to be using imapproxy anymore these days 
though for performance reasons, at least if using Dovecot 2+.

(Clearing the IMAP cache actually doesn't have much to do with this.   
All you are doing is preventing QRESYNC from being used in that 
initial connection, until the cache is primed again.  It's not fixing 
the underlying imapproxy issue).

In short, either stop using imapproxy or add XIMAPPROXY to the list of 
ignored capabilities in backends.php.  Or simply accept this imapproxy 
issue if it is extremely rare on your systems.

First, let me say I've read tickets #12097 and #12031. Second, I got 
yesterday a series (many) of IMAP errors:

2014-04-22T12:54:01+02:00 host/a.b.c.d horde: [imp] IMAP error 
reported by server. Error in IMAP command SELECT: QRESYNC not enabled 
[pid 27468 on line 570 of "./imp/lib/Imap.php"]
2014-04-22T12:55:23+02:00 host/a.b.c.d horde: [imp] IMAP error 
reported by server. Error in IMAP command EXAMINE: Invalid QRESYNC 
parameters [pid 27022 on line 570 of "./imp/lib/Imap.php"]
2014-04-22T12:56:33+02:00 host/a.b.c.d horde: [imp] IMAP error 
reported by server. Error in IMAP command SELECT: Invalid QRESYNC 
parameters [pid 25372 on line 570 of "./imp/lib/Imap.php"]

The problem was fixed by /usr/bin/horde-clear-cache and the errors 
have (temporarily?) gone. However more interesting is genesis of the 
problem.

Horde connects to dovecot server via imapproxy which told sometime:

2014-04-21T14:50:01+02:00  host/a.b.c.d in.imapproxyd[1795]: 
Raw_Proxy(): IMAP_Read() failed reading from IMAP server on sd [11]: 
Connection reset by peer
2014-04-21T14:50:01+02:00  host/a.b.c.d in.imapproxyd[1795]: LOGIN: 
'user@domain' (127.0.0.1:47602) no previous connection: creating a new 
one
2014-04-21T14:50:01+02:00  host/a.b.c.d in.imapproxyd[1795]: LOGIN: 
'user@domain' (27.0.0.1:47602) on new sd [8]
2014-04-21T14:50:01+02:00 c host/a.b.c.d in.imapproxyd[1795]: 
IMAP_Line_Read(): connection closed prematurely.
2014-04-21T14:50:01+02:00 host/a.b.c.d in.imapproxyd[1795]: 
Raw_Proxy(): Failed to read line from client on socket 16

What about dovecot server? It coredumped with

2014-04-21T14:50:01+02:00 imap/e.f.g.h dovecot: imap(user@domain): 
Fatal: master: service(imap): child 14593 killed with signal 6 (core 
dumped)

Well, we see what has happened: dovecot dumped core, imapproxy 
connection died, Horde signalled IMAP error and... I'd say Horde has 
written damaged data into cache file. Then, subsequent IMAP accesses 
ended with QRESYNC problems until horde-clear-cache was run.

The question is, are you able to prevent writing of corrupted data to 
cache files? And, what I can do to find out what failed next time the 
problem arises?