FWIW, at the moment failed authentication in IMP and/or occasionally 
when sending a message (especially when Spam reporting) I also get 
segfaults.  This is on PHP 5.4.  I can verify that disabling APC 
(and/or the new zend optimizer) fixes this.

VERY annoying, but since it is both 1) intermittent and 2) traceable 
to a Zend extension I have to assume that it is not an issue with our 
code.  Really wish I could grab a segfault backtrace to debug, but I'm 
using a system that uses systemd which currently (braindead) limits 
segfaults to something like 24 MB.  And it is not configurable.  So 
all coredumps are tossed:

[1306160.980116] php-fpm[17690]: segfault at 71 ip 000000000074b839 sp 
00007fff061879a0 error 4 in php-fpm[400000+911000]
[1306161.828895] systemd-journald[177]: File passed too large. Ignoring.

Looks like this is a combination of this very exception/error and 
Xdebug causing PHP to segfault. Since the IMAP error is still logged, 
I associated this error with Horde not responding. Without Xdebug the 
folder list is loaded now. Though that's obviously a bad trade-off 
with not having Xdebug available for development.

Yes, and this is what I fixed.  If 
Horde_Imap_Client_Base#getMyACLRights() throws an exception, this is 
ignored and we use the default values.

Not sure how you are seeing an exception still (we only call 
getMyACLRights one place in IMP).

No, because it's an exception from Imap_Client due to the NO response, 
not from IMP_Imap_Acl.

This is fixed.

Changes have been made in Git (FRAMEWORK_5_0):

commit 60b65dfb6c769c8090efc99f2d5f535c799c0145
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Tue Apr 16 19:33:30 2013 -0600

     If error retrieving ACLs for a mailbox from IMAP server, fallback 
to defaults instead of throwing exception (Bug #12184)

     Conflicts:
             imp/lib/Imap/Acl.php

  imp/lib/Imap/Acl.php |    8 ++++++--
  1 files changed, 6 insertions(+), 2 deletions(-)

http://git.horde.org/horde-git/-/commit/60b65dfb6c769c8090efc99f2d5f535c799c0145

Changes have been made in Git (master):

commit 0def156e9c81dbf7cebdd64c3173b64af32ec310
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Tue Apr 16 19:33:30 2013 -0600

     If error retrieving ACLs for a mailbox from IMAP server, fallback 
to defaults instead of throwing exception (Bug #12184)

  imp/lib/Imap/Acl.php |    2 --
  1 files changed, 0 insertions(+), 2 deletions(-)

http://git.horde.org/horde-git/-/commit/0def156e9c81dbf7cebdd64c3173b64af32ec310

I *think* this is acceptable.  At a minimum, Dovecot allows this:

a MYRIGHTS "Madeupmailboxname"
* MYRIGHTS "Madeupmailboxname" lrwstipekxacd
a OK Myrights completed.

This makes sense for several reasons:

1. Nothing in RFC 4314 requires a mailbox to actually exist for it to 
have an ACL.
2. A server could be able to tell you what the ACLs WOULD be if the 
container existed as a mailbox.  Which could be used, for example, to 
determine whether a sub-mailbox could be created under a container.

In other words, all servers may not support this but some do, and 
there is no way of knowing unless you issue the command.

For our purposes it is cheaper to do it this way since a mailbox may 
be a container solely because it is not subscribed to (in other words, 
we save a LIST command).

Two issues:
- if MYRIGHTS fails on a mailbox, the exception is not catched and the 
loading of any UI elements is unnecessarily halted.
- for some reason IMP is checking MYRIGHTS for a container. That 
container was probably created by some external client.

C: 5 LIST (SUBSCRIBED) "" ("INBOX.*" "user.*" "*") RETURN (SUBSCRIBED)
S: * LIST (\Subscribed \HasChildren) "." INBOX.AMMMa
[...]
S: * LIST (\Subscribed) "." "INBOX.PHP + Web.SOAP"
S: * LIST (\Subscribed) "." INBOX.Posteingang.Papierkorb
S: * LIST (\Subscribed \HasChildren) "." INBOX.Privat
[...]
C: 28 MYRIGHTS "INBOX.Posteingang"
S: 28 NO Mailbox does not exist