Red Hat Bugzilla – Bug 70693
imapd preconfigured to use user's home directory as mailroot; crashes some mua's
Last modified: 2007-04-18 12:45:12 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.0) Gecko/20020529
Description of problem:
uw-imapd comes configured out of the RPMs shipped with both 7.2 and 7.3 to use
the user's home directory as the root of the user's mail folders. this causes OS
X mail.app and numerous webmail packages (most notably squirrelmail, which I
have noticed will be included in future redhat linux releases) to crash when
they attempt to access folders, as the ENTIRE contents of ~ attempts to go
across the IMAP connection. To fix this, I got the latest source for version
2002RC1, and modified src/osdep/unix/env_unix.c to point to ~/mail. I also took
the opportunity to set RestrictedBox = -1, which prevents access outside of the
mail directory and /var/spool/mail.
I am sure there is justification for having imap route to the home directory,
but I do not see it, as PINE stores things in ~/mail, and the rather popular OS
X mail.app goes absolutely insane when it tries to map the home directory.
Relevant excerpts from docs/CONFIG in the 2002RC1 source tree:
Example 2: suppose you want to change c-client's idea of the
user's mailbox directory to be the "mail" subdirectory of the user's
home directory instead of the user's home directory. You will want to
change variable mailsubdir, changing the line that reads:
static char *mailsubdir = NIL; /* mail subdirectory name */
static char *mailsubdir = "mail";/* mail subdirectory name */
Example 5: suppose you want to disable non-namespace access to the
filesystem root and other users' names, but do not want to go to the
extreme of chroot() and you want to allow access to a traditional UNIX
format INBOX in the mail spool directory. You need to change variable
restrictBox, changing the line which reads:
static short restrictBox = NIL; /* is a restricted box */
static short restrictBox = -1; /* is a restricted box */
Version-Release number of selected component (if applicable):
Steps to Reproduce:
installed redhat 7.3 RPM release of imap-2001a-13.
Actual Results: Squirrelmail webmail crashed when attempting to access Folders
tab, first with an out of memory error, then with a timeout after max memory
size was increased in php.ini.
OS X mail.app attempted to download entire contents of ~ onto local machine,
with CPU at 100% and eventually hung.
If MUA's are crashing, then those applications are buggy and need to be
fixed. This is not an imap server bug.
If there are MUA's in RHL that crash, please file bug reports against
each MUA that crashes, so that it can be fixed. For MUA's of other
distros/OS's, etc., please contact the vendor of the application, and
report their MUA has a bug which should be fixed.
I've read this 11052 and 73861 and my vote is +1 that you (Red Hat) should do
something about this! What is the point of reporting bugs (or whatever you would
like to call it) if you just say "go speak to the original authors"? Spare a
thought for the three bug reporters who have obviously gone to some trouble
to help you improve your product and save lots of customers lots of time.
Anyway, I disagree. This is a bug in the server or its configuration.
It does not crash Outlook Express but it does mean:
- I can view any regular file below my home directory as a mailbox (unrecognised
and therefore assumed by the server to contain a single message) and I can
delete it, perhaps without realising what is going on or that the file "mailbox"
will be physically deleted;
- if there are symbolic links like .openoffice/user/work which create an
infinitely deep directory tree then Outlook Express will go away for a very
long time and perhaps forever if I do not click cancel while it is looking for
This is clearly wrong. Even if the mailer is completely stupid the IMAP server
should not make it possible to delete anything that is not in a valid mailbox
or designated mail folder.
I don't have a UW address to hand, so why don't you package up these bug reports
and send them back up the supply chain.
We will not change the default behaviour of imapd from that which is
provided in upstream sources at this time.
Please file UW imap feature requests directly to the University
of Washington. In order to engage in discussion with developers working
on UW imap, you can join the IMAP mailing list at: