Fri, 10 Apr 2026 12:12:27 +0000 https://bugs.horde.org/ticket/1620 infinite loop in IMAP folder listing I have confirmed that Horde (though, I use Horde just for IMP, but from what I can tell the bug is in the underlying Horde IMAP classes) has a bug that: 1) Ignores the LATT_NOINFERIORS flag for folders. and/or 2) Ignores that the folder "delimiter" is empty() for subfolders that it should not query. I was able to confirm the bug by writing a very simple PHP script which lists IMAP folders. I was able to duplicate the bug that IMAP does by incorrectly formatting subfolder queries. What I mean by that is, if you have a folder called "Blah" in the parent list (and it does not have the LATT_NOINFERIORS flag and does have a delimiter) and you try to list folders under it, you would query "Blah/%" for example (assuming / is the delimiter). If that query yeilds another box called "Foo" (that also does not have the LATT_NOINFERIORS flag and does have a delimiter), you should be querying "Blah/Foo/%" next time. However, it appears as though Horde is ignoring the parent folder when looking for subfolders of subfolders. If it does this, when it sees "Foo", it then issues a query for "Foo/%". In my particular case, it was in fact that the subfolder "Foo" (as an example) did have the LATT_NOINFERIORS flag set as well as a delimiter set, so it should not have been queried (for two reasons). Because it was also improperly querying the subfolder, it was causing an infinite loop which probably nobody ever encounted due to the weird way my particular IMAP daemon works (SmartMax IMAPMax5). My problem is because the IMAP daemon reports that beneath every folder, there is another folder called "INBOX". This "INBOX" subfolder has the LATT_NOINFERIORS flag set and does not have a delimiter so it technically should not have been queried, but it was. That caused it to query "INBOX/%" (rather than "Trash/INBOX/%" for example). This then caused the IMAP daemon to report a folder called INBOX under the INBOX folder, which caused an infinite loop. If you take in to consideration the LATT_NOINFERIORS flag, the loop is stopped because the INBOX subfolders apparently all have that flag set. If you take in to consideration the presense of the folder delimiter (for the folder you're querying), the loop is also stopped because the subfolders do not have a delimiter. If you take in to consideration both cases, the loop is also stopped. I have attached my test script (minus IMAP credentials that query my IMAP server). The code may not be streamlined, but it demonstrates proper IMAP folder querying. Eli. Thu, 24 Mar 2005 21:52:18 +0000 https://bugs.horde.org/ticket/1620#t6621 I forgot to mention, I am using: Horde v3.0.3 IMP v4.0.2 INGO v1.0.1 Turba v2.0.2 Thu, 24 Mar 2005 21:57:16 +0000 https://bugs.horde.org/ticket/1620#t6622 Upon further review (after reviewing RFC 3501, Horde code, etc.) I still can't figure out if your IMAP server is breaking RFCs or not. I will say that my IMAP server, nor pretty much anyone else's, is doing this. However, it probably is a pretty smart idea to put in a NOINFERIORS check if not just for the simple reason that it doesn't break anything currently working and because it will most likely fix your problem. So, can you take a look at the following patch: http://cvs.horde.org/diff.php/framework/IMAP/IMAP/Tree.php?r1=1.64&r2=1.65&ty=u and see if this fixes your problem? Fri, 25 Mar 2005 01:20:13 +0000 https://bugs.horde.org/ticket/1620#t6628 Yes this fixes the problem :) It is in fact the exact same line I found to modify to hack up a fix, however at the time I did not think to use the noinferiors flag (my fix was just to not look deeper in to any box called INBOX - certainly not useable by everyone). I too do not know if the IMAP server is breaking RFC's, however I have submitted the operation of their IMAP server as a bug in hopes that they correct it. I see no reason why their folders should have a "fake" folder called INBOX in them. Their choice to do so also causes Horde/IMP to think that every folder has a child when viewing the folder tree, though thankfully it shows nothing when you try to expand it, and causes no errors. It appears this has squashed the bug (for now! :) ) Thanks! Eli. Fri, 25 Mar 2005 02:12:03 +0000 https://bugs.horde.org/ticket/1620#t6632 Allright, second attempt at this to make this re-work with UW-IMAP: http://cvs.horde.org/diff.php/framework/IMAP/IMAP/Tree.php?r1=1.67&r2=1.68&ty=u Please provide feedback as to whether this works. Thu, 31 Mar 2005 04:49:33 +0000 https://bugs.horde.org/ticket/1620#t6769 What I posted on imp@: Long story short - UW-IMAP will of course have it's INBOX flagged as \NoInferiors in a default mailbox setup since the INBOX normally lives in a totally different directory (i.e. /var/spool/mail vs. ~mail) from the user mailboxes. So we can't use NOINFERIORS as a check. Instead, just catch the case when we are trying to add 'INBOX' at a level other than the base level and skip this case if it occurs. Thu, 31 Mar 2005 04:53:49 +0000 https://bugs.horde.org/ticket/1620#t6770 Fixed for me (with uw-imap). Thanks! Thu, 31 Mar 2005 12:11:42 +0000 https://bugs.horde.org/ticket/1620#t6776 Fix doesn't work for my issue. The parent of the INBOX folders is always empty, thus it skips your alternate fix. Is there no way to access the current delimiter for the folder it's about to expand? If you can, can we not just agree that a folder with no delimiter should not be expanded? Not expanding folders called INBOX means nobody can have a custom folder called INBOX anywhere except the main parent one - probably will never be an issue, but if someone does it, they'd wonder what's up. Thu, 31 Mar 2005 16:00:02 +0000 https://bugs.horde.org/ticket/1620#t6782 Eli, in _getList(), can you try changing this line: if (!empty($box->name)) { to: if (!empty($box->name) && !empty($box->delimiter)) { As far as I can tell, folders that don't contain a delimiter must (obviously) be in the base level. And INBOX should be the only folder that doesn't have a delimiter. And we specifically add INBOX to the base level in IMP_Tree:: so ignoring it in _getList() will not prevent us from seeing INBOX in the base level. Thu, 31 Mar 2005 17:56:00 +0000 https://bugs.horde.org/ticket/1620#t6784 *Perfect* I commented out the "fixes" to _addLevel completely (so it's back to the way it was before I ever reported the bug), and just did this fix in _getList and it's a perfect fix. It also now causes other folders to not show any possibility of expanding, whereas with the other fix it showed [+] beside boxes even though they couldn't be expanded - so it seems this is the better fix. Hopefully this works for uw-imap users! Eli. Thu, 31 Mar 2005 21:54:40 +0000 https://bugs.horde.org/ticket/1620#t6787 Using uw-imap: I deleted the file (Tree.php), then retrieved a fresh copy from CVS. I think I got the right one (it looks like all of the previous modifications for this bug had been removed). I then made the change requested to the _getList function (to check the delimeter), and everything is working. Thanks! Fri, 01 Apr 2005 03:47:00 +0000 https://bugs.horde.org/ticket/1620#t6791 Committed fix to Horde 3.0.5 and HEAD. Sat, 02 Apr 2005 06:47:24 +0000 https://bugs.horde.org/ticket/1620#t6831