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 */ to be: 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 */ to be: static short restrictBox = -1; /* is a restricted box */ Version-Release number of selected component (if applicable): How reproducible: Always 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. Additional info:
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 hidden folders; 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. Cheers.
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: http://www.washington.edu/imap/imap-list.html