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".
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 configuration.
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." :-)
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....
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.
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.
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.)
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 !
workaround : ftp://rpmfind.net/linux/Mandrake/Mandrake/7.2/i586/Mandrake/RPMS/imap-4.7c2- 4mdk.i586.rpm rpm -e imap rpm -ivh imap-4.7c2-4mdk.i586.rpm /etc/rc.d/xinetd reload thanks to Mandrake !
*** Bug 23680 has been marked as a duplicate of this bug. ***
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!
To nalin, Hi, 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. Thanks Oliver
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.
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. #!/bin/sh # 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." fi done /etc/rc.d/init.d/sendmail start /etc/rc.d/init.d/inet start echo echo "Update finished." echo echo "Don't use 'pine' or 'mail' anymore, otherwise stay with the old imapd" echo
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. Sorry.
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 Oliver