[: GaB :]

My friends Horde and Imp are back again! Now I tried Horde3 with IMP4 from the Debian Etch repository.

After my last appointment with Horde, I decided to install it on another server, as a replacement for the unmaintained IlohaMail. Everything worked fine, until I didn't wish to log in the first time into IMP, to check how it works.

Logging in into Horde does work fine, but logging in into IMP doesn't. If I try, I  get a download window pointed in my face with the file named redirect.php.

First I guess this is a problem with the session handling. I had such an issue upon installing a Moodle onto this server, because Apache is chrooted. Then I start debugging...

/usr/share/horde3/imp/redirect.php runs fine, until line 149, where a call for IMP_Session::createSession return false, and it returns false also.

Then I checked lib/Session.php where a call at line 308 $GLOBALS['imp_search']->sessionSetup(); not just fails, it crashes. That's why I'm getting a download window instead of a blank page or any kind of error messages: the login script doesn't fail, it crashes.

Back to debugging: the last call I mentioned crashes because in Search.php at line 109 the line $this->createVINBOXFolder(); crashes. If I comment it out, it works! But no reason to stop here...

This function (defined at line 398) is present to create virtual INBOX folders. And it does hang at line 402 $imptree = &IMP_Tree::singleton();

This is utterly bad. Why the hell does such a call hang? Single instances of IMP_Tree might be system wide used.

In lib/IMAP/Tree.php I found that in fact I have to debug IMAP_Tree::singleton() in lib/Horde/IMAP/Tree.php, because Imp's IMP_Tree extends Horde's IMAP_Tree, and here at line 272 the call $instance[$app] = &new IMP_Tree(true, imaptree); fails.

The constructor of IMP_Tree breaks when it calls it's parent's constructor, that again fails when it calls $this->init($init); at line 288.

Init fails at line 474 with $this->_addLevel($boxes);, _addLevel fails at line 1037 with  $elt = $this->_makeMailboxTreeElt($val);, and here at line 389 $this->_initSubscribed(); crashes.

And finally here throws $tmp = @imap_lsub($this->_getStream(), $this->_server, $val['name'] . '*'); at line 1498 a SEGFAULT.

Function imap_lsub (a standardized PHP system call) would list all the subscribed mailboxes, but WTF - I ask my self - that means this is a SEGAFAULT in the PHP environment itself.

A fast syslog check reveals that exactly this is happening:
Mar 19 01:07:13 * *: imap-login: Login: user=<*>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured
Mar 19 01:07:13 * apache2[24918]: IMAP toolkit crash: Unable to look up user name
Mar 19 01:07:13 *: IMAP(*): Disconnected

Apache's IMAP PHP module is crashing, with a very uninformative but googleable message.

So I find more people facing this problem:
http://bugs.horde.org/ticket/?id=711
groups.google.com/group/mailing.www.horde-imp/browse_thread/thread/...

It comes out, that the whole misbehavior is caused by the attempt of Apache's IMAP engine to read /etc/passwd, and because Apache is running in a chroot such a file does not exists. It does only need the line with the UID Apache is running with, so this need is easy to satisfy, without any security concern: I just copied the line of www-data from /etc/passwd into /etc/passwd inside the chroot.

Sometime you have to set up a Webmail for a small ISP in your neighborhood. I don't like nasty surprises, so I look at some examples weeks before it has to go online.

The featurelist isn't that long, so I didn't expected any problems:

• the capability to read, sort (into folders) and compose e-mails
• to be able to set up a simple mail forward
• to be able to  change the password

I used SquirrelMail long time ago. It was small and fast, but ugly and lacked of perspective. So I tried IlohaMail. I preferred the latter one, but now it has a big disadvantage: it is unmaintained, with a couple of remaining bugs. But since there it is no way to change the password or setup mail forwards via IMAP, I had to look for something new.

Horde3+IMP4 looked great. It took not so long to install it, but it was a dead end.

Horde is a php framework and IMP is a POP3/IMAP client depending on Horde. Horde is able to deal with lots of authentication datasource (for example: SASL, custom SQL, Exim database backend), moreover it is possible to grant or deny access depending on the success or failure of authentication into one of it's modules (say IMP). So I can login Horde via IMP, and IMP logs in via IMAP. Great! When I don't want the users to login every time twice (once to Horde depending on the Exim database backend, and once to IMP via IMAP), then the only backend I can use for authing them is IMAP. So I lost the chance again to change the password. Even when there is an extra plugin for Horde, which runs a daemon on some port (not to mention security), that can change the system password for you, but I do not use the /etc/shadow for mail accounts. This way is doomed. I will try something else soon...