Subject: WU-IMAP and mbx

From: Friedrich Lobenstock <[email-masked]>
Date: Tue, 8 May 2001 03:40:45 +0200 (CEST)

How do I change the wu-imap to use mbx mailboxes instead of the normal
unix style mailbox as a default. I'm asking this because I would like
to change this after the imap server is compiled. So is this possible
via writing something in a "magic" config file?

I tried mbx and my conclusion is that if more than one client wants to
access one account at the same time this mailbox format is better
suited. Ok, the filesystem is not NFS, but what else should I take
care of? Can I repair those mailboxes by hand if the need arises?

-- 
MfG / Regards
Friedrich Lobenstock

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

---

From: Rich Graves <[email-masked]>
Date: Mon, 7 May 2001 23:26:14 -0400 (EDT)

> via writing something in a "magic" config file?

It hasn't been updated for imap-2000, but http://www.carumba.com/imap/ has
all the information you should need.

You can optimize INBOX, which is probably over 95% of your imap access,
without changing anything. Just copy an empty mbx-format file (mbxcreat
#driver.mbx/INBOX) into everyone's home directory and the berkeley-format
spool file will be slurped into it automatically the next time they read
mail. Add an empty mbx INBOX to /etc/skel or your adduser script and you're
done.

If you need to optimize folders other than INBOX, there is a magic config
file, but you need to read and perhaps conmpile the source code in order to
use it (config files without the possibly version-dependent secret word
aren't read). You're simply better off recompiling.

I'm assuming based on your message-id that you're a RedHat user. If you're
nervous about keeping RedHatisms then rpm --rebuild
SRPMS/imap-$VERSION.src.rpm and when it's done take a peek into
/usr/src/redhat/BUILD. Hack at the prepatched source, make clean, make lnp.

> care of? Can I repair those mailboxes by hand if the need arises?

Yes, mbx can be repaired. A helpful message from the list archives is
appended. I used Mark's tips below to repair about 100 mbx files when a
RAID controller decided to neglect the "nonvolatile" part of "128MB
nonvolatile cache RAM."

I actually prefer the way that corrupted mbx files deny access completely.
Broken berkeley mboxes or maildirs might never give the user an indication
that there's a problem.

If you've suffered a major disk crash and you want to test a large number
of mailboxes for corruption, one way to test them is:
for f in */*/INBOX; do; ifrom $f | tail -1|grep \?; done

Or you can test the exit status of "pine -Iq -c0 -f $f" if you're in a
pinch and don't have ifrom (which is in imap-utils; I don't know if it's in
any of RedHat's packages).

After that fun experience I decided to keep an "archive log" of all
incoming email to make doubly sure I'd never lose anything. It's easy to
do, just duplicate the relevant bits of your mail.local equivalent to
append queue files to _two_ spool files per user on two separate disks.

 http://samantha.unet.brandeis.edu/bboard/q-and-a-fetch-msg?msg_id=00001e

patch for postfix, see postfix list archives for discussion:

 http://brandeis.edu/~rcgraves/duplicate-spool.diff

Mark Crispin's message on repairing mbx files:

---------- Forwarded message ----------
Date: Wed, 18 Oct 2000 08:49:37 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Cc: [email-masked]
Subject: re: repairing "mbx" formatted files

On Wed, 18 Oct 2000 09:46:16 -0600 (CST), Mike Trank wrote:
> Anyone know a way that I can repair an "mbx" type mailbox file, manually
> or otherwise?

Some people have developed automated scripts, but if you're comfortable using
emacs it's pretty easy to fix it manually.  DON'T USE vi OR ANY OTHER EDITOR
UNLESS YOU ARE CERTAIN THAT EDITOR CAN HANDLE BINARY!!!

A c-client program would have issued an error message saying which byte number
it got to when it got unhappy with it the file, usually after the word "at",
e.g. something like:
        Unable to parse internal header at 43921: ne bombastic blurdybloop
This byte number ("43921") is the location of the error in the file.  That's
the point you need to fix.

c-client is expecting an internal header at that byte number, looking
something like:
 6-Jan-1998 17:42:24 -0800,1045;000000100001-00000001
The format of this internal line is:
dd-mmm-yyyy hh:mm:ss +zzzz,ssss;ffffffffFFFF-UUUUUUUU

The only thing that is variable is the "ssss" field, it can be as many digits
as needed.  All other fields (inluding the "dd") are fixed width.

So, the easiest thing to do is to look forward in the file for the next
internal header, and delete everything from the error point to that internal
header.

Here's what to do if you want to be smarter and do a little bit more work.
Generally, you're in the middle of a message, and there's nothing wrong with
that message.  The problem happened in the *previous* message.

So, search back to the previous internal header.  Now, remember that "ssss"
field?  That's the size of that message.  Mark where you are in the file, move
the cursor to the line after the internal header, and skip that many bytes
("ssss") forward.  If you're at the point of the error in the file, then that
message is corrupt.  If you're at a different point, then perhaps the previous
message is corrupt and has a too long size count that "ate" into this message.

Basically, what you need to do is make sure that all those size counts are
right, and that moving "ssss" bytes from the line after the internal header
will land you at another internal header.

Usually, once you know what you're looking at, it's pretty easy to work out
the corruption, and the best remedial action.  I generally don't use repair
scripts because I prefer the flexibility of manual repair.  Repair scripts
will make the problem go away but may not always do the smartest/best salvage
of the user's data.

---

From: Friedrich Lobenstock <[email-masked]>
Date: Tue, 8 May 2001 14:13:53 +0200 (CEST)

> mail. Add an empty mbx INBOX to /etc/skel or your adduser script and you're

I make use of the vimap package from http://vimap.sourceforge.net/ .
So I can't make use of /etc/skel because the home directories at
/vhome/EMAIL-DOMAIN/home/USER never get initializied, just created, by
linuxconf.

> file, but you need to read and perhaps conmpile the source code in order
> to use it (config files without the possibly version-dependent secret word

So the magic config would be the best solution because I could step
back to normal unix style mailboxes (only for new ones of course) any time.

Is this config file documented somewhere, or do I have to dig into the
source of wu-imapd?

> /usr/src/redhat/BUILD. Hack at the prepatched source, make clean, make lnp.

Sorry, wrong guess, I'm a SuSE user since SuSE Linux 1.2.13 (that
was the version of the kernel, after that they changed to their own
numbering schema) :)

> appended.

Thank's for that.

-- 
MfG / Regards
Friedrich Lobenstock

---

From: Mark Crispin <[email-masked]>
Date: Tue, 8 May 2001 06:19:29 -0700 (PDT)

> back to normal unix style mailboxes (only for new ones of course) any time.

There should be no reason to use the config file.  imapd automatically detects
the format of the mailbox.

The only thing that you would configure in this way is the default format of
newly-created mailboxes, and it is much safer to rebuild the c-client library
than to use that config file.

> Is this config file documented somewhere, or do I have to dig into the

Do not use that config file.  Here be dragons.

---

From: Friedrich Lobenstock <[email-masked]>
Date: Tue, 08 May 2001 15:59:52 +0200

> the format of the mailbox.

Yes I know, but my intentions are what you are talking about next!
 
> than to use that config file.

Sorry to question that, but hardcoded stuff is always something that's not
good. Think of updating stuff. The next time I update the imap daemon I would
have to hack the RPM package again if I'd go with changing the sources. 
The config file persists.

> Do not use that config file.  Here be dragons.

The BIG question, why on earth can't I use the config file to specify default
format of newly-created mailboxes? "Here be dragons." is not a definition
I understand as a technician. 

-- 
MfG / Regards
Friedrich Lobenstock