Bug 18375 - IMAP no longer uses ~/mbox
Summary: IMAP no longer uses ~/mbox
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: imap   
(Show other bugs)
Version: 7.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
: 23680 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2000-10-05 03:16 UTC by Robert Peters
Modified: 2007-04-18 16:28 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-18 11:28:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Robert Peters 2000-10-05 03:16:18 UTC
Upgraded from RH6.2 to RH7.0 and the imap server no longer moves mail out 
of /var/spool/mail/user to /home/user/mbox, and will not 
access /home/user/mbox as the "inbox".

Comment 1 Nalin Dahyabhai 2000-10-06 01:36:40 UTC
This was a planned change.  Users who accidentally created mbox files in their
home directories often reported sudden disappearance of their mail as a bug.

If you specify the mailbox path as '{imapserver}mbox', you should still be able
to access the mailbox.  The file accessed as '{imapserver}INBOX' is usually
located in /var/mail or /var/spool/mail, depending on the server's

Comment 2 Robert Peters 2000-10-06 16:38:00 UTC
Does it not make sence to tell those people (or put in a FAQ) that create a 
~/mbox file accidently that they need to delete it, than to take away the 
ability to use a ~/mbox file from those that have used it in the past? Maybe 
two versions of the IMAP rpm are necessary, one with ~/mbox support (which 
could still use just /var/spool/mail as the last one did), and one without 
~/mbox support for those easily confused (installed by default.) Your solution 
just created the problem that all my users who use a ~/mbox file are 
reporting "the sudden disappearance of their mail as a bug." :-)

Comment 3 Nalin Dahyabhai 2000-10-06 18:02:40 UTC
Actually, yes, that should have gone into the release notes.  Is doing a
one-time move of mail from {server}mbox to {server}INBOX causing serious
problems?  The automagic message moving was handled by the "mbox" driver (er,
metadriver?) in the server, so it was disabled for compile-time, and re-enabling
it would require a second copy or other contortions....

Comment 4 Robert Peters 2000-10-06 18:37:16 UTC
The main problem I am having from those who used ~/mbox and I moved mail into
/var/spool/mail is their mail checking utilities (at login, gnome mailcheck,
etc.) always tell them they have mail even when their mailbox is empty (due to
the control message that is put at the begining by imap, pine, etc.). And those
who check their mail using imap, and then with pine who still had a ~/mbox file
get "Do not delete this message" messages when pine moves the entire contenets
of /var/spool/mail/user into ~/mbox. This has lead to a lot of confusion and
frustration, as well as some embarrasment on my part for "screwing up the entire
mailsystem" as my boss put it.

Comment 5 Nalin Dahyabhai 2000-10-06 19:16:28 UTC
That's odd.  The message is created by the c-client library, and both Pine and
imapd are built to use it for handling mail folders, so they shouldn't be
showing up in Pine if you read mail locally with a version built on the same (or
a similar) version of the library.  Other mail readers which access spool files
locally *will* notice these after Pine creates them, and that causes problems.
The version of the toolkit currently in development (in release candidate 7
phase ATM) no longer creates this message if it isn't already there, so a
solution is in sight, and there's a good chance that we'll be pushing out an
errata with it because it fixes a potential DoS in ways that aren't simple
enough to backport cleanly.
The Pine system-wide configuration file should have a setting which is causing
it to move messages to mbox when users quit (read-message-folder?) and emptying
that setting should prevent that behavior.

Comment 6 Robert Peters 2000-10-06 21:46:01 UTC
The "Do not delete" message was the control message for the spool file being
imported into the ~/mbox file. After facing fierce opposition to migrating to
use the spool files exclusively, I was forced to get the source RPM and edit out
your modifications to disable the ~/mbox and rebuild it. This works for now, at
least until the next update. Still the most annoying thing about just using the
spool file is mail notification which access the spool file directly, which
always reports mail even if none is present (due to the control file.)

Comment 7 Need Real Name 2000-11-19 23:52:47 UTC
Sorry but this change really sucks !
If it would been an real change like using another IMAP Server (cyrus) you just 
change a small behavior. Probably many companys will get trouble with it if the 
port their large mail server to rh7 with customer mails. often /var and /home 
are different mount point and especially configured for a common amount of data.
I hate mail like "Welcome to Outlook" but in this case a mail like "Important 
change to Mail Setup" as first mail to root would have saved myself a lot of 
trouble !

Comment 8 Need Real Name 2000-11-20 00:23:48 UTC
workaround :

rpm -e imap
rpm -ivh imap-4.7c2-4mdk.i586.rpm
/etc/rc.d/xinetd reload

thanks to Mandrake !

Comment 9 Need Real Name 2001-01-11 19:58:53 UTC
*** Bug 23680 has been marked as a duplicate of this bug. ***

Comment 10 Mirko Zeibig 2001-02-11 01:58:39 UTC
Well I discovered this behaviour as well and am happy I did not move my 
biggest mailserver with approx. 100 users to RH7.0. This is really a big 
change and should be marked in the description!

Comment 11 Oliver Schulze L. 2001-02-18 02:57:04 UTC
To nalin,
the problem doing a one time move from {mailserver}mbox to {mailserver}INBOX
is that if there is still messages in /var/spool/mail/ they will be deleted.
The othe problem is that you will have to stop xinetd in order to make this.
Causing an interuption on the imap service. This can'n be done in a 24x7 server.

I have read in the imap-2000-devel driver.txt that the mbox driver is enabled
by default. Why it have been disabled?

And the last cuestion:
How can I solver this problem? What is the niciest(read elegant) way to solve 
this problem.

I'm planning and upgrade to RH7.0 for a mailserver with 450+ acounts and this
issue is stopping me.


Comment 12 Robert Peters 2001-02-18 03:19:14 UTC
The ~/mbox IS enabled by default for IMAP-2000. Redhat had to go out of their
way to disable it. The ONLY solution I found to this problem (and had to do in
short order), was to undo what Redhat did. You can do this really easily if you
get the IMAP-2000 src.rpm file. Use rpm to install it in the normal way, and
then if you go into your /usr/src/redhat/SOURCES and edit the file
imap-2000-redhat.patch. The first two patches of this file disable the ~/mbox
feature. Simply delete lines 1-21 inclusive and then go to the
/usr/src/redhat/SPECS and issue the command:
rpm -bb imap.spec
and when it is finished, you'll have a functional rpm in the
/usr/src/redhat/RPMS/i386 directory. Install that and you're all set. As I
stated a long time ago, it would have been much nicer for Redhat to leave in
this feature, and refer people who "lost" their mail by switching between using
~/mbox and not to RTFM. It's very simple, if you have a ~/mbox file, it will use
it. If you don't, then it will keep all the mail for that user in
/var/spool/mail/<username>. Anyone who continues to be confused by this probably
shouldn't be a Unix system administrator. Ok, now I'll step off the soapbox, and
urge Redhat to stop disabling this feature in future releases so that I don't
have to patch their patchfile every time there is an update.

Comment 13 Oliver Schulze L. 2001-02-18 11:28:03 UTC
rpeters, thanks for the help.
Your solution seems a definitive one. And as you said, there should be not
necesary to edit and compile an src.rpm when and upgrade is available.
My point is that upgrades(within same mayor RH release) should not break
anything, unless a big warning is issued.(think about people that use up2date)
My apologies for my last message, it sounds like a flame. Was not my intention,
so forgive me.

Here is a little script that should move every mbox to the 
corresponding /var/spool/mail/ file.
It is not so elegant, but safe enough.

# execute this after upgrading to imap-2000 on RH6.2
# requirements
# - no sendmail process should be running
# - no imapd process should runnig
# - no user should be logged
# - every aplication that can mail an email should be stoped(crond, atd, etc)
# after running this script, don't use an aplication that use the ~/mbox
#   file, like pine, mail, etc
# reffer to http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=18375

/etc/rc.d/init.d/sendmail stop
/etc/rc.d/init.d/inet stop

echo "Waiting ..."
sleep 3

killall sendmail
killall imapd
echo "Waiting ..."
sleep 3

cd /home
for i in * ; do
        if [ -f $i/mbox ] ; then
                echo -n "Updating mbox for user $i: "
                cat $i/mbox >> /var/spool/mail/$i
                mv -i $i/mbox $i/mbox.old
                echo "done."

/etc/rc.d/init.d/sendmail start
/etc/rc.d/init.d/inet start

echo "Update finished."
echo "Don't use 'pine' or 'mail' anymore, otherwise stay with the old imapd"

Comment 14 Mike A. Harris 2001-07-30 23:03:42 UTC
I am closing this bug report as Nalin has said, the number of people
reporting bugs when the mbox driver was built in was quite significant,
and we felt that removing this driver used by a minority was the
best solution for the problems experienced by the many.

We provide the source code to all of our software packages, so please
feel free to rebuild imap/pine et al. with mbox enabled if you wish.

I no of no way to have this built to satisfy both groups of users, so
regardless of which decision is made, someone is going to be upset.


Comment 15 Oliver Schulze L. 2001-07-31 09:59:45 UTC
I think is ok to do that.
We are now in RH7.1, so it can be left behind.
One option is to document the change in an errata 
or something like that.

Good luck

Note You need to log in before you can comment on or make changes to this bug.