Mail Servers

[John Chambers]

Rich Braun writes:
| dsr <dsr at tao.merseine.nu> wrote:
| >> ...some arguments from folks who have made the switch from mbox to
| >> maildirs.
|
| Aside from the performance and reliability issues you raised, are there
| software capabilities available in maildirs format that cannot be implemented
| in plain-text mbox format?

Well, one "capability" that I like is that I can easily  augment  any
email  package  with  my own perl scripts to do useful things.  Doing
this with any of the various "mbox" formats is difficult.  First,  it
takes extra time to write the routines to demux the messages and then
recombine them. And then, all too often you discover that you've done
something  subtly  wrong  with  the  format  that confuses some other
software that you're using.  With each message in its own  file,  you
can  just  use the usual filesystem operations, and it's difficult to
get that wrong.

The trickiest part with mboxes is getting the  locking  right.   It's
never  documented,  and  if  you  don't  do it right, you risk losing
incoming messages when you try to do something with your inbox.

One question I'd have, though:  Are there any general guidelines  (or
even - gasp - standards) for how to do things portably with maildirs?
I've seen different packages differ in things like how to indicate  a
deleted  message  (without  actually deleting it), how reply messages
are named, and how to indicate the current message.  I  suspect  that
there  aren't  any  actual standards for these things, so my own code
can't be completely portable.  If there are standards or even  common
conventions,  I'd  like  to  know about them.  If there are important
warnings and gotchas, I'd like to know about those, too.

OTOH, I have so many email-munging perl scripts now that I  may  soon
be independent of any actual mail reader package. I'm pretty close to
duplicating everything that I use in my own code. Maybe I should just
finish the job.  .-)



--
   O
 <:#/> John Chambers
   +   <jc at trillian.mit.edu>
  / \  <jmchambers at rcn.com>