Subject: mbx folder creation, and bodiless messages

From: ben h kram <[email-masked]>
Date: Thu, 5 Oct 2000 02:01:36 -0400

What is the preferred method of creating a fresh mbx folder?

I once chirped up about this before, and Jauder Ho <[email-masked]> gave a nifty perl script to make one.

I can write mail bits just fine to these files, but reading from them will give me envelope data but always an empty body.

I've attached a small sample box to demonstrate.  You can use mtest to see this behaviour.

(The box has 3 messages, sub: test [123], each body is test [123] + my .sig)

I can get this behaviour under 2000.4 and 2000.7.

any light that can be shone...

thanks,
ben

-- 
"...human heads are opaque and there's no way to see inside except 
through those tiny little windows, the eyes."
                                                -Yevgeny Zamyatin
                                                      "We"
-- 
------------------------------------------------------------------
 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: Thu, 5 Oct 2000 10:09:23 -0700 (PDT)

> What is the preferred method of creating a fresh mbx folder?

The official way is to call the c-client mail_create() with a mailbox name
that is prefixed with "#driver.mbx/".

The mbxcreat program, part of the imap-utils
	ftp://ftp.cac.washington.edu/mail/imap-utils.tar.Z
can be used to do this from the shell, e.g.:
	mbxcreat #driver.mbx/foo
creates an mbx-format mailbox called "foo" in the user's home directory.  The
command
	mbxcreat #driver.mbx/INBOX
creates an mbx-format INBOX.

> I can write mail bits just fine to these files, but reading from them will
> give me envelope data but always an empty body.

Are you using the c-client mail_append() function?  If not, then you're on
your own.

Be sure that there is a proper header/body delimiter: CR LF CR LF

Also, remember that in mbx format, newlines are CR LF, not UNIX-style raw LF.

> I've attached a small sample box to demonstrate.

I don't see any attachments in your message.

---

From: "C. R. Oldham" <[email-masked]>
Date: Thu, 05 Oct 2000 10:45:08 -0700

> that is prefixed with "#driver.mbx/".

And for the server side, is the preferred way to set the default mailbox type to
mbx just to change the Makefile?

I ask because most packaged versions of the UW-Imap suite don't set this.  I
can't use the packages because I don't want my users to accidentally create
mailboxes of types other than mbx.

Is there some reason why the default type is not already mbx?

--
  / C. R. (Charles) Oldham | NCA Commission on Schools    \
 / Director of Technology  | Arizona State University      \
/ [email-masked]          | V:480-965-8703  F:480-965-9423 \

---

From: Mark Crispin <[email-masked]>
Date: Thu, 5 Oct 2000 10:53:51 -0700 (PDT)

> mbx just to change the Makefile?

Yes.  Just change DEFAULTPROTO=unixproto to DEFAULTPROTO=mbxproto

> Is there some reason why the default type is not already mbx?

Yes, there is.

mbx is non-standard.  c-client based applications are the only thing that deal
with it, and we strongly encourage application writes who want to create mbx
savvy programs to use c-client, to ensure interoperability.  The downside of
this is that it shuts out applications that aren't based on c-client.  That's
why the default in c-client is the crufty old format that UNIX has used for
the past 30 years.

mbx is not NFS-safe.  mbx depends upon the UNIX filesystem semantics; in
particular, that locking works and the mailbox data is updated immediately and
consistantly.

In more detail, mbx uses random access I/O with multiple processes having
read/write access.  mbx has four levels of lock:
 1) open (shared lock)
 2) open+parsing new mail (shared lock)
 3) delivering new mail (exclusive lock - locks against lock 2)
 4) open+expunging (exclusive lock - interlocks against locks 1,2,3)
These locks much be communicated properly with all processes which access the
mbx mailbox at all times.  In addition, mbx will alter message flags in place
with a random access write() operation without any locking; this requires that
the buffer cache be updated immediately for all processes which have the
mailbox open.  Delivery of new mail must immediately update the buffer cache
and the inode cache for all processes which have the mailbox open.

NFS makes none of these guarantees.  There is a form of locking with NFS which
works if the phase of the moon is right and applications aren't exercising it
too much.  mbx, to put it mildly, pummels locking.  UNIX kernel locking for
local files can handle it, but NFS locking (if it exists) quickly collapses in
a catatonic heap (and with it, hangs the entire NFS cluster).

---

From: ben h kram <[email-masked]>
Date: Thu, 5 Oct 2000 16:30:07 -0400

> I don't see any attachments in your message.

Goodness, okay, I was very tired sending that out.  Forgot to attach the mailbox.

fyi, I am using mail_append().

thanks,
ben

---

From: ben h kram <[email-masked]>
Date: Thu, 5 Oct 2000 16:49:02 -0400

Gads I'm losing it today.

Okay, please ignore the last message and its spool.  It is a random spool I had sitting in my directory.

I apologize to the list if you got it.

_This_ is a small, sample spool, demonstrating what I was seeing.

thank you,
ben

---

From: Mark Crispin <[email-masked]>
Date: Thu, 5 Oct 2000 15:10:09 -0700 (PDT)

The reason why it isn't working is that you called mail_append() with bogus
data.  Specifically, you gave it data with UNIX-style LF-only newlines,
whereas mail_append() specifically requires CRLF newlines.

The mbx format also requires CRLF newlines.