[imp] Re: Extremely weird IMAP behaviour - IMP or c-client problem?

[Paul Annesley]

Are you sure you're using the correct folder path for your imap server
in servers.php?

 * folders: The folder path for the IMAP server.
 *          Common values:
 *            UW-IMAP               'mail/'  (note the trailing slash)
 *            Cyrus, Courier-IMAP   'INBOX.' (note the trailing dot)
 *            dovecot               ''
 *
 *          IMPORTANT: Use this only if you want to restrict users to this
 *          subfolder. If you set this to 'INBOX.' with Cyrus or
 *          Courier-IMAP, then users will not be able to use any shared
 *          folders - nothing outside of 'INBOX.' will be visible (except
 *          INBOX, which is always visible). If you simply want to mask out
 *          the 'INBOX.' (or another) prefix for display purposes, use the
 *          'namespace' attribute (see below).

Regards,
Paul

On Sun, 20 Mar 2005 21:46:27 -0500, Eli <eli-list at experthost.com> wrote:
> I've spent about 8 hours trying to troubleshoot what is the most peculiar
> problem I've ever seen.  I have an IMP install all done up (using the latest
> release versions of Horde, IMP, Ingo & Turba as of yesterday) and have been
> trying to figure out an IMAP problem (which sparked me to get the latest
> versions and try with those) that seems to only occurr with a SmartMax
> (http://www.smartmax.com) IMAP daemon.
> 
> First things first, you can check the "test.php" page for my test install
> here:  http://66.165.106.121/test/horde/test.php
> 
> The install is somewhat customized - I have a few hooks, the most important
> being one that operates on preauthentication to figure out if the user can
> use the webmail system (it also does some neat DNS stuff to figure out their
> IMAP & SMTP server).  This hook appears to be working (though for some
> reason SMTP Auth isn't working right, but that's a different problem) and
> have done extensive testing to pretty much rule out most (if not all) of my
> customizations as the source of my problem.
> 
> Now, the problem seems to only happen when IMP tries to communicate with a
> SmartMax IMAP daemon - I've tried also with an IMail and Courier-IMAP daemon
> and they do not have any problems (logins work fine, all folders appear
> fine, etc...).  When trying to log in/communicate with the SmartMax IMAP
> daemon, it takes several login attempts before one works.  If it works, it
> may arbitrarily require you to log in again after doing almost anything.
> The furthest I've got is being able to click on the Mail link from the side
> menu to display my Inbox and then when I click on the Folders top menu (to
> admin folders) it prompts me to log in again.
> 
> I did some IMAP logging on the SmartMax server and saw IMP doing this:
> 
> 19:56:06 [143] 00000000 CAPABILITY
> 19:56:06 [143] 00000001 LOGIN <email at example.com> "<password>"
> 19:56:06 [143] User email logged in.
> 19:56:06 [143] 00000002 CAPABILITY
> 19:56:06 [143] 00000003 LIST "" %
> 19:56:06 [143] 00000004 LSUB "" *
> 19:56:06 [143] 00000005 LIST "" INBOX/%
> 19:56:06 [143] 00000006 LIST "" INBOX/%
> 19:56:06 [143] 00000007 LIST "" INBOX/%
> ...
> 
> It seemed to go on for about a total of 1000 attempts at issuing the LIST
> command before it died off and of course in the IMP interface I had to log
> in again.  Subsequent attempts would not always yeild it doing the same
> thing - I assume it was caching something so it didn't always do this again,
> but I'm not sure.  Now, I'm no IMAP expert so I tried the command IMP was
> doing to see what the output was:
> 
> 0 LIST "" INBOX/%
> * LIST (\NoInferiors) NIL INBOX
> 0 OK LIST completed.
> 
> I did the same command on the other 2 IMAP servers (IMail & Courier-IMAP)
> and they did not return the same thing (in fact I believe they returned
> nothing).  I don't know if this means something or not... The "NIL" part is
> interesting, as is the fact that if I issue the same command but for a
> different folder:
> 
> 0 LIST "" Trash/%
> 
> I get the same reply "* LIST (\NoInferiors) NIL INBOX" back.  I would not be
> surprised if anyone believes the SmartMax IMAP daemon being buggy - but it
> won't help me since the SmartMax programmers are horribly reluctant to fix
> *ANY* bug I submit to them (I honestly don't think they know how - I've
> submitted about 5+ bugs to them which require fixing but nothing ever
> happens).
> 
> After this, I thought maybe that PHP/c-client might be the problem.  So I
> grabbed the latest c-client/imap tarball from
> ftp://ftp.cac.washington.edu/imap/ and compiled that and recompiled PHP.
> First thing I noticed was that from the c-client version I had used before
> to what I had now, the IMAP c-client version went from "2001" to "2000" even
> though I had the 2004 source code.  I tried several different ways of
> compiling to see if the version # would change but no luck.  I ended up
> grabbing the latest development snapshot and using that - still "2000".
> During each compile I still tested to see if the IMAP problems were
> happening and they were, so I was no better off now than I was before
> really.
> 
> This whole problem came about after I announced to many clients that they
> could use a new webmail interface (we used to have IMP 2.2 or something on a
> server, and I got a new server and installed newer horde + apps).  Much
> testing had gone through before announcing - but I do not know how much
> testing (if any) was done communicating with a SmartMax server.  When users
> started using it and reporting login problems, I first thought either too
> much load for SmartMax, or something else.  I was able to rule out
> everything except IMAP communication itself which is where I am at right
> now.
> 
> I have not tried any development snapshots of Horde or IMP yet, but I will
> if someone knows that this is a reported bug (I searched, couldn't find
> anything) and has been fixed in a newer version.  If nobody has reported
> anything like this before but is willing to help me troubleshoot, please let
> me know - I can provide you with account logins for testing purposes so you
> may see just how messed up this is!
> 
> Thanks in advance,
> 
> Eli.
>