<?xml version="1.0" encoding="UTF-8"?> 
<?xml-stylesheet href="https://dev.horde.org/themes/horde//default/feed-rss.xsl" type="text/xsl"?> 
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> 
 <channel> 
  <title>Rare random Logouts due loss of IMAP connection</title> 
  <pubDate>Fri, 10 Apr 2026 09:50:17 +0000</pubDate> 
  <link>https://bugs.horde.org/ticket/3404</link> 
  <atom:link rel="self" type="application/rss+xml" title="Rare random Logouts due loss of IMAP connection" href="https://bugs.horde.org/ticket/3404/rss" /> 
  <description>Rare random Logouts due loss of IMAP connection</description> 
 
   
   
  <item> 
   <title>I&#039;m right now monitoring a strange problem on a internal hor</title> 
   <description>I&#039;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&#039;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&#039;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 &quot;LOGIN FAILURE&quot; 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 &#039;openIMAPStream&#039; which returned &#039;false&#039; on every case of logged-off-users. So i looked at imap_errors() and found constantly the same msg:

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

The german part of this message means something like &quot;connection timeout&quot; - i don&#039;t know why this message is partly german.



Since horde/imp and the IMAP-server reside on the same machine i don&#039;t see a reason for timeout, but i thought imp might need to retry to &#039;imap_open&#039; 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 &#039;login failure&#039; 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 &gt;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 &quot;bad boy&quot; in this scenario, but this &quot;feature&quot; might be a nice improvement to imp.



How about?



Regards Andreas</description> 
   <pubDate>Fri, 03 Feb 2006 18:06:35 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/3404#t16270</link> 
  </item> 
   
  <item> 
   <title>Slightly modified (only do 3 login attempts, use sleep() ins</title> 
   <description>Slightly modified (only do 3 login attempts, use sleep() instead of usleep() as usleep() doesn&#039;t work reliably on windows) and committed to HEAD and 4.1.0.</description> 
   <pubDate>Sat, 04 Feb 2006 18:00:09 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/3404#t16293</link> 
  </item> 
   
   
 
 </channel> 
</rss> 
