Slightly modified (only do 3 login attempts, use sleep() instead of 
usleep() as usleep() doesn't work reliably on windows) and committed 
to HEAD and 4.1.0.

I'm right now monitoring a strange problem on a internal horde/imp 
setup serving about 70 user. Authentication is IMAP-only and imp is 
the login-app.



These users normally log on to their emails in the morning and keep 
that window up and running until they leave work in the evening. They 
all have set up a mailreminder to be instantly informed about new mail 
- so they never get a session-timeout.



Strangely sometimes one or more get logged of from horde while others 
stay logged on at that point of time. This logoff occures on any 
action that results in refreshing the webpage. And theres no timeout - 
klick and you're back at login-page. Users who are writing a new mail 
loose their work if the background-window with its refreshing INBOX 
gets logged of, because the compose-popup is closed, too. This is 
really nasty!

You can't define a certain time-spot, any coincident or a method to 
cause the users to get logged out.



I traced this thing down in a time consuming honeypot-method (as i 
named it) placing a mail-sender at a prominent place to provide me 
with information of imps state when someone gets logged off. By 
letting the honeypot move backwards from the place the horde-log 
message "LOGIN FAILURE" i slowly traced back to the origin of imps 
logout-reason. Everytime i made a change i had to wait from several 
minutes to several hours for someone getting logged off unreasonable.

I found the logout-reason in imp/lib/IMAP.php in the function 
'openIMAPStream' which returned 'false' on every case of 
logged-off-users. So i looked at imap_errors() and found constantly 
the same msg:

"Connection failed to 127.0.0.1,143: Die Wartezeit für die Verbindung 
ist abgelaufen"

The german part of this message means something like "connection 
timeout" - i don't know why this message is partly german.



Since horde/imp and the IMAP-server reside on the same machine i don't 
see a reason for timeout, but i thought imp might need to retry to 
'imap_open' the IMAP stream a little more often.

I changed a part of the code in IMAP.php as you can see in the 
attached file, where i documented the before- and after-state. Unless 
the last imap_error is not something like 'login failure' my routine 
gives imap_open 10 chances to return a stream-result with a timeout of 
0.3 sec between each try. That would result at worst case in a >3 sec. 
delay before a user finally gets thrown out of horde/imp.

My statistics on these rare cases show, that most imap_open that fail 
on first try do succeed within 1 retry. The worst case so far had to 
do 2 retries.



I do think this is not a problem of imp! The imap server seems to be 
the "bad boy" in this scenario, but this "feature" might be a nice 
improvement to imp.



How about?



Regards Andreas