Subject: changing location of mbx mailbox

From: "Harondel J. Sibble" <[email-masked]>
Date: Sun, 26 Jan 2003 14:49:28 -0800

Howdy folks, I am converting a Caldera Openlinux 2.3 System to mbx format 
from mbox format using the following info:

http://linux-sxs.org/mbx.html

Okay after working through most of the necessary modifications to use the 
above with the current version, I have one problem that I haven't been able 
to solve.

On the server in question, I want to have the mbx folders stored in the 
/var/spool/mail directory just like the current mbox mail files.

Ideally, I'd just like to run mbxcvt on the current mail spool files and have 
sendmail deliver it to the (new)current mailspool files using tmail.  Having 
the mbx's in the home directories is not an option on this server due to the 
current backup strategy.  Full system backups are done on tape daily while 
home dirs are all backed up to a single cd daily.

How do I pull this off, I've browsed through some of the makefiles, and a  
fair bit of documentation, and am currently reading through the c-client list 
archives, however I haven't found quite what I need, can someone please point 
me in the right direction?
-- 
Harondel J. Sibble 
Sibble Computer Consulting
Creating solutions for the small business and home computer user.
[email-masked] (use pgp keyid 0x3AD5C11D) http://www.pdscc.com
(604) 739-3709 (voice/fax)      (604) 686-2253 (pager)

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Sun, 26 Jan 2003 15:10:45 -0800 (PST)

> /var/spool/mail directory just like the current mbox mail files.

Although this is possible by means of modification to the source code, there
are a number of non-obvious technical and administrative issues that you will
have to address in doing it.  I strongly recommend *against* putting mbx
format files in /var/spool/mail, or for that matter any other directory which
is not opened by the individual user.

I don't quite understand why you don't want INBOX backed up along with home
directories onto a single CD.

Do you specifically want non-retention of email data over the long term?  If
so, a better alternative to /var/spool/mail is to have a separate series of
"email" home directories, each owned by the individual users.  In other works,
if user jones has a UNIX home directory of /home/jones, he would also have a
mail home directory of /mail/jones (so his INBOX would be /home/jones/INBOX).

The modification to accomplish this is a very simple change to mymailboxdir()
in env_unix.c.  For example, one way to do it is:

static char *mymailboxdir ()
{
  myusername ();		/* get user name iff logged in */
  if (!myMailboxDir && myUserName) {
    char tmp[MAILTMPLEN];
    sprintf (tmp,"/mail/%s",myUserName);
    myMailboxDir = cpystr (tmp);
  }
  return myMailboxDir ? myMailboxdir : "";
}

If you insist upon a shared directory like /var/spool/mail, the task is quite
a bit more complex.

---

From: "Harondel J. Sibble" <[email-masked]>
Date: Sun, 26 Jan 2003 15:57:44 -0800

> have to address in doing it.  I strongly recommend *against* putting mbx
I was afraid you were going to say that :-(

> directories onto a single CD.
Won't even remotely fit, we used to use a single cd/day, now mon/wed/fri 
backs up half the home days, while tues/thurs backs up the rest due to the 
amount of data.

> Do you specifically want non-retention of email data over the long term?  If
No, the only reason I am going to mbx format in the first place is the 
nightmare I have with mbox and Microsoft OE and Outlook as Imap clients. See 
below:

*************************************
Howdy folks, I have one client getting these messages on bootup of her
machine at the office each day, and also when remote accessing the server
via an ssh tunnelled imap session. Now the lost mailbox lock makes sense,
but what to do about it?  None of the other users are experiencing this,
and I can't see anything obvious in the log files....

Looking at the email referenced in the second error message, all seems
okay, there is nothing odd about the message in question.

------- Forwarded message follows -------

Header download for the 'Inbox' folder did not complete. Your IMAP server
has closed the connection. This may occur if you have left the connection
idle for too long. Account: 'server1', Server: 'server1', Protocol: IMAP,
Server Response: 'Lost mailbox lock', Port: 143, Secure(SSL): No, Error
Number: 0x800CCCDD  

OR

Outlook Express could not download the requested message. It is likely
that the message was removed or expired from the server. Your IMAP server
has closed the connection. This may occur if you have left the connection
idle for too long. Subject 'RE: Tourism Vancouver - Vancouver Book
Publication', Account: 'server1', Server: 'server1', Protocol: IMAP,
Server Response: 'Lost mailbox lock', Port: 143, Secure(SSL): No, Error
Number: 0x800CCCDD

------- End of forwarded message -------

Server is Caldera Openlinux 2.3, running a 2.2.19 (with appropriate
patches) and the UW imap server, client machine is Win98SE. 

*************************************

Amongst other errors, basically the problem is that fetchmail is adding mail 
to the mbox file while the user is reading mail via imap. A couple users in 
particular have multiple accounts going into the same mbox file which makes 
things much worse re: errors about and constant disconnects.  I want to go to 
mbx format to have concurrent access to the mail store file. MBX seems the 
way to go.

> mail home directory of /mail/jones (so his INBOX would be /home/jones/INBOX).
Well if I could have the mail in user dirs under 
/var/spool/mail/username/INBOX, that would solve most of my problems I 
suspect and deal with the issues you mentioned above.  Basically as above, I 
don't want to have the mail anywhere near the users' home dirs. If I could 
put them in another directory that allows ownership by the respective users, 
that would be ideal.  I guess the other option would be to change the cd 
backup script to omit the mail files and subdirs, but I'd rather not go that 
route. (To paraphrase Albert Einstein) Backup should be simple, but not too 
simple.

> in env_unix.c.  For example, one way to do it is:
That's greek to me, but I'll take you word for it :-)

> If you insist upon a shared directory like /var/spool/mail, the task is quite
Okay, so as above, if I create a separate maildir with user owned subdirs 
beneath it, will that do the trick?

ie 

/mail/user1
/mail/user2
/mail/user3
.
.
.
/mail/userN