Re: Where should IMAP look for mail folders?
"Jaldhar H. Vyas" <jaldhar@debian.org> writes:
> However lately there have been two bug reports (#33780, #34056) which
> suggest that this may not have been a good move. I could hack the
> c-client library IMAP uses for mailbox access to solve the particular
> problems mentioned in the bug reports but other problems may crop up
> and other packages that require c-client (pine, libmail-cclient-perl)
> may need to be recompiled. Or I can make the decision to stick with
> $HOME or stick with $HOME/mail even if it causes issues for some
> people. What should I do?
More specifically:
Let $MBOXROOT be the mail box root the previous poster talked about;
this variable used to be $HOME and is now $HOME/mail
Imapd, upon login, creates a file $MBOXROOT/mbox and dumps all
mail in the user's standard mailbox (/var/spool/mail/$user) into this
file and manipulates this file as the special mail folder INBOX which
the imap client (probably) expects to be the place incoming mail ends
up.
Also, imapd considers other files in the $MBOXROOT/ directory to be
mail folders (in "mbox" format) and presents them to the client as
such. If imapd is asked to create a new folder, it puts it in the
$MBOXROOT/ directory.
So far, it seems like assigning $MBOXROOT to $HOME/mail is the proper
choice - among other things, that's where pine sticks its mail
folders (by default), so pine-created folders can now be viewed from
any imap client.
So much for the basics. NOW, here are the two bugs:
#33780 arises from the fact that pine understands this "slurp the
incoming mail into a file called mbox" behavior, and if a file called
$HOME/mbox exists, will dutifully copy any mail it finds in the system
inbox into this file and manipulate it just the same way imapd does.
So far, so good - except that pine expects to find this file as
$HOME/mbox, despite the fact that pine wants to store its mail folders
under the subdirectory $HOME/mail/. Don't you just love the U of W?
Therefore, if imapd's $MBOXROOT is set to $HOME/mail, imapd will be
using $HOME/mail/mbox, which pine doesn't recognize as special in the
same way.
#34056 arises from the fact that imapd has a few "special" mailbox
names - in this case, mailboxes whose names begin with the string
"#mh/" - these mailboxes refer to mh folders; for example, the mailbox
"#mh/debian-devel" refers to the mh folder "debian-devel". How does
imapd know where to find the directory which contains these mh
folders? Very cleverly, imapd looks at the file $HOME/.mh_profile and
looks for the "Path:" line. So far so good. Very uncleverly, though,
imapd appends the value of that line to $MBOXROOT/, not to $HOME/.
The end result is that if you have mh set up to store your mh folders
in $HOME/Mail, imapd will look for the mh folders under
$MBOXROOT/Mail, which currently means $HOME/mail/Mail.
I would conclude from this that the imapd (or is it c-client?) authors
don't know when they want to use $MBOXROOT and when they want to use
$HOME; in fact, I doubt if it is ever tested upstream with $MBOXROOT
set to anything other than $HOME.
As for the proper solution, I'm not sure. One could move $MBOXROOT
back to $HOME, on the grounds that one never knows where else the
upstream authors may have assumed that the two are the same, and then
silently prepend "mail/" to any mailbox name that isn't the special
INBOX name (which ends up refering to $HOME/mbox file) and doesn't
have a "#" as the first character (which makes the mailbox special in
different ways, depending on what follows the #). Pine seems happy to
somehow have the $MBOXROOT be $HOME yet have the default folder
collection be mail/[] - is there some way to simulate this behavior?
(Or could people just be told to set their default folder collection
to {machinename}mail/[], which may well be what the U of W intends to
have happen?)
I'm actually surprised that there seem to be so few dfsg-free imapd
implementations - it certainly seems like something that's easier to
do than an smtp daemon, and goodness knows people don't tire of
reinventing that particular wheel.
Reply to: