6. Known Issues

What follows are some issues I have encountered using Exim4 and Courier IMAP.

6.1. Issues with Exim4

6.1.1. lock file /var/spool/exim4/db/retry.lockfile: Permission denied

It's possible your Exim4 retry.lockfile may get adopted by root, as alluded to in this thread. This error is symptomatic of such an adoption:


2002-07-24 12:40:52 17XP8Z-0005i2-00 failed to open database
lock file /var/spool/exim4/db/retry.lockfile:
Permission denied (euid=8 egid=8)

Executing a


chown mail:mail /var/spool/exim4/db/*

should resolve the issue -- it did for me.

6.1.2. error in forward file (filtering not enabled)

Another error you may encounter is symptomatic of forgetting to enable user forward file filters in /etc/exim/exim4.conf, which is now enabled by default for the Exim4 Debian packages:


 2002-07-24 12:52:17 17XOsd-0005fo-00 == user@localhost
D=userforward defer (-11): error in forward file
(filtering not enabled): missing or malformed
local part (expected word or "<") in "... filter rule ..." 

Though the error mentions several problems, the actual issue is, as it states, filtering isn't enabled for user forward files.

6.1.3. Not a directory: stat() error for ...: Not a directory

It's also possible you might get this error, which results from a file by the same name already existing in your Maildir/:


 2002-07-28 07:36:13 17YmLM-0002bu-00 ==
/home/jasonb/Maildir/.mailinglists.EX/ <jasonb@localhost>
T=address_directory defer (20):
Not a directory: stat() error for
/home/jasonb/Maildir/.mailinglists.EX/: Not a directory 

It's often the result of forgetting to include the trailing front slash (/) in an Exim4 filter rule and then later adding it. In the meantime, Exim4 will happily save the mail you're directing there in MBox format instead of Maildir format. Later when you fix your filter, if you don't remember to move the MBox dot file out of the way, your mail will get frozen by Exim4.

6.2. Issues with Courier IMAP

6.2.1. Courier IMAP immediately disconnects client

If you're getting disconnected from Courier IMAP without any obvious error message, you might have fallen victim to your Maildir being violated. If you run tcpdump against your session, you might see something like the following output I obtained:


* OK [CAPABILITY IMAP4rev1 UIDPLUS ... ] Courier-IMAP ready. \
  Copyright 1998-2003 Double Precision, Inc. \
  See COPYING for distribution information..
0 CAPABILITY.
...
0 OK CAPABILITY completed.
1 LOGIN "jasonb" "[protected]".
1 OK LOGIN Ok..
...
14 LIST "" "INBOX.mailinglists.leap".
* LIST (\Unmarked \HasChildren) "." "INBOX.mailinglists.leap".
14 OK LIST completed..
15 STATUS "INBOX.mailinglists.leap" (UNSEEN).
* BYE [ALERT] Fatal error: No such file or directory.

At that point, the IMAP client is disconnected. However, that's not very helpful, so you may wish to run an `strace` on the process to investigate further.


nebula:~# ps auxw | grep courier
...
root 242  0.0  0.1  1476  516 ? S 00:54 0:00
/usr/sbin/couriertcpd -address=0 -stderrlogger=/usr/sbin/courierlogger
-maxprocs=40 -maxperip=4 -pid=/var/run/courier/imapd.pid -nodnslookup
-noidentlookup 143 /usr/lib/courier/courier/imaplogin
/usr/lib/courier/authlib/authdaemon /usr/bin/imapd Maildir
...
nebula:~# strace -F -f -eopen -p 242
... magic ...
[pid   807] open(".mailinglists.leap/tmp",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No such file or
directory)
...
Process 807 detached

Now, it becomes clear. Somehow, one of the necessary Maildir directories seems to have disappeared. Recreating this directory solves the problem, though not necessarily the mystery of how it disappeared.


jasonb@nebula:~/Maildir$ mkdir tmp
jasonb@nebula:~/Maildir$ chmod u=rwx,g=s,o= tmp/