<?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>Inconsistent fetchmail behavior</title> 
  <pubDate>Fri, 10 Apr 2026 17:52:46 +0000</pubDate> 
  <link>https://bugs.horde.org/ticket/2211</link> 
  <atom:link rel="self" type="application/rss+xml" title="Inconsistent fetchmail behavior" href="https://bugs.horde.org/ticket/2211/rss" /> 
  <description>Inconsistent fetchmail behavior</description> 
 
   
   
  <item> 
   <title>The fetchmail/accounts code in IMP behaves inconsistently, d</title> 
   <description>The fetchmail/accounts code in IMP behaves inconsistently, depending on the results of a fetchmail operation.  In addition, the message index is not updated if new messages are received.



mailbox_start=1

sort_by=0

sort_dir=0



Examples:



On initial login, with unread or read messages in the INBOX, if you have fetchmail configured as a maintenance task and confirm that, and no new messages are on the remote server, you are dropped into your INBOX, at the first unread message.  This works as expected.



On initial login, with no unread message in the INBOX, if you have fetchmail configured as a maintenance task and confirm that, you&#039;re dropped into your INBOX and the notification is that Fetchmail: N messages in Account name.  However, the message index is not updated to reflect the fact that you have a new message and you are positioned at the beginning of the messages.  I would expect that the number of new messages would be reflected in the INBOX and that you would be taken to the first new unread message.  But I need to refresh to get that to happen.



On initial login, with one or more unread messages in your INBOX, if you have fetchmail configured as a maintenance task and confirm that, you&#039;re dropped into your INBOX and the notification is that Fetchmail: N messages in Account name.  However, the message index is not updated to reflect the fact that you have a new message and you are positioned at the first unread &quot;old&quot; message.  Again, you have to refresh your INBOX to see the new message count.



After initial login, if you go to the Accounts icon in the menu of IMP and force a check for new messages, you are presented with a confirmation screen.  After you confirm, your accounts are checked.  And you are returned to the confirmation screen, with Fetchmail: N messages in Account name.  My expectation is that you&#039;d be returned to your INBOX (or whatever folder you were in when you invoked fetchmail).



I think the algorithm for fetchmail should go something like this (everywhere its invoked from):



Check for confirmation and which accounts to check

Check for mail in remote accounts

Update folder index with new message index

Return to either the folder that fetchmail was called from, or initial_page (if initial login and there was no folder that fetchmail was called from) and honor the value of mailbox_start</description> 
   <pubDate>Fri, 01 Jul 2005 22:16:49 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/2211#t9491</link> 
  </item> 
   
  <item> 
   <title>&gt; On initial login, with no unread message in the INBOX, if </title> 
   <description>&gt; On initial login, with no unread message in the INBOX, if you have 

&gt; fetchmail configured as a maintenance task and confirm that, you&#039;re 

&gt; dropped into your INBOX and the notification is that Fetchmail: N 

&gt; messages in Account name.  However, the message index is not updated 

&gt; to reflect the fact that you have a new message and you are 

&gt; positioned at the beginning of the messages.  I would expect that the 

&gt; number of new messages would be reflected in the INBOX and that you 

&gt; would be taken to the first new unread message.  But I need to 

&gt; refresh to get that to happen.



This works for me (new messages are indicated via the &#039;INBOX (#)&#039; header and I am sent to the page with the first unread message.



&gt; On initial login, with one or more unread messages in your INBOX, if 

&gt; you have fetchmail configured as a maintenance task and confirm that, 

&gt; you&#039;re dropped into your INBOX and the notification is that 

&gt; Fetchmail: N messages in Account name.  However, the message index is 

&gt; not updated to reflect the fact that you have a new message and you 

&gt; are positioned at the first unread &quot;old&quot; message.  Again, you have to 

&gt; refresh your INBOX to see the new message count.



Once again, I can not duplicate this.  And this makes no sense.  the maintenance stuff is done before the mailbox page is even loaded, so when the mailbox is built all these messages are already in the mailbox.



&gt; After initial login, if you go to the Accounts icon in the menu of 

&gt; IMP and force a check for new messages, you are presented with a 

&gt; confirmation screen.  After you confirm, your accounts are checked.  

&gt; And you are returned to the confirmation screen, with Fetchmail: N 

&gt; messages in Account name.  My expectation is that you&#039;d be returned 

&gt; to your INBOX (or whatever folder you were in when you invoked 

&gt; fetchmail).



This can probably be changed.



&gt; I think the algorithm for fetchmail should go something like this 

&gt; (everywhere its invoked from):

&gt;

&gt; Check for confirmation and which accounts to check

&gt; Check for mail in remote accounts

&gt; Update folder index with new message index

&gt; Return to either the folder that fetchmail was called from, or 

&gt; initial_page (if initial login and there was no folder that fetchmail 

&gt; was called from) and honor the value of mailbox_start



this is exactly what the code does now (except for the last part).



My testing is with IMP HEAD btw.</description> 
   <pubDate>Fri, 04 Nov 2005 05:26:54 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/2211#t13420</link> 
  </item> 
   
  <item> 
   <title>Implemented returning to the local download mailbox after fe</title> 
   <description>Implemented returning to the local download mailbox after fetching.



As for the rest, as I mentioned I can&#039;t reproduce it any what you are asking for is already the way it is coded (i.e. no matter how we fetch mail, the fetching is *always* complete before the mailbox.php page is even loaded).</description> 
   <pubDate>Fri, 04 Nov 2005 05:45:53 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/2211#t13422</link> 
  </item> 
   
  <item> 
   <title>Can we close this ticket then?</title> 
   <description>Can we close this ticket then?</description> 
   <pubDate>Mon, 28 Nov 2005 14:47:01 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/2211#t14197</link> 
  </item> 
   
  <item> 
   <title>Maybe.  At the time I generated the ticket, the behavior was</title> 
   <description>Maybe.  At the time I generated the ticket, the behavior was as I had noted.  At some point since then and when Michael added his notes, the behavior changed and most of the items are gone.



However, I have one issue with the fix commited to imp/fetchmail.php for the mailbox that you are returned to.  I would expect to be returned to the same page display that I invoked Fetch Mail from.  But regardless of that, I&#039;m returned to &#039;lmailbox&#039;, which, as I read the code, is the folder value for the first fetch mail account.



Example of how I have my home setup configured:



Three fetchmail accounts, A, B, and C.



A downloads to Folder A

B downloads to INBOX

C downloads to Folder C



Fetchmail invoked as a maintenance task on initial login drops me into my INBOX (expected behavior).



Fetchmail invoked manually drops me into Folder A, no matter where I was before.  While that is a predictable behavior (no matter where you are, you always end up in Folder A), I&#039;d much favor the behavior of where you were before you invoked Fetch Mail, thats where you end up.  If you&#039;re in your INBOX,  you end up in the INBOX.</description> 
   <pubDate>Mon, 28 Nov 2005 15:11:51 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/2211#t14212</link> 
  </item> 
   
  <item> 
   <title>&gt; Fetchmail invoked manually drops me into Folder A, no matt</title> 
   <description>&gt; Fetchmail invoked manually drops me into Folder A, no matter where I 

&gt; was before.  While that is a predictable behavior (no matter where 

&gt; you are, you always end up in Folder A), I&#039;d much favor the behavior 

&gt; of where you were before you invoked Fetch Mail, thats where you end 

&gt; up.  If you&#039;re in your INBOX,  you end up in the INBOX.



This is the same issue as with the empty trash and empty spam folders - we would have to do in-depth parsing of the URL to enable us to return to the same page.  i.e. we can&#039;t just say return to &#039;message.php&#039; since message.php requires certain parameters.  same with &#039;mailbox.php&#039; since the mailbox may have changed in the session in the meantime.  or what if we are currently in a page that can only be reached through a previous POST/GET - there is no way to return this page.  Thus, we pick a sensible default that will always work as expected rather than a separate method that can never be guaranteed to work all of the time.</description> 
   <pubDate>Tue, 29 Nov 2005 06:47:03 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/2211#t14312</link> 
  </item> 
   
   
 
 </channel> 
</rss> 
