Provided by: mutt_1.5.21-5ubuntu2_i386 bug


       MMDF - Multi-channel Memorandum Distribution Facility mailbox format


       This  document  describes the MMDF mailbox format used by some MTAs and
       MUAs (i.e.  scomail(1)) to store mail messages locally.

       An MMDF mailbox is a text file containing an arbitrary number of e-mail
       messages.   Each  message consists of a postmark, followed by an e-mail
       message  formatted  according  to  RFC822  /  RFC2822,  followed  by  a
       postmark. The file format is line-oriented. Lines are separated by line
       feed characters (ASCII 10).  A  postmark  line  consists  of  the  four
       characters "^A^A^A^A" (Control-A; ASCII 1).

       Example of a MMDF mailbox holding two mails:

              Subject: test

              >From what I learned about the MMDF-format:
              Subject: test 2


       In  contrast  to  most other single file mailbox formats like MBOXO and
       MBOXRD (see mbox(5)) there is no need to quote/dequote "From "-lines in
       MMDF mailboxes as such lines have no special meaning in this format.

       If the modification-time (usually determined via stat(2)) of a nonempty
       mailbox file is greater than the access-time the  file  has  new  mail.
       Many  MUAs  place  a  Status:  header in each message to indicate which
       messages have already been read.


       Since MMDF files  are  frequently  accessed  by  multiple  programs  in
       parallel, MMDF files should generally not be accessed without locking.

       Three  different  locking  mechanisms (and combinations thereof) are in
       general use:

       ·      fcntl(2) locking  is  mostly  used  on  recent,  POSIX-compliant
              systems. Use of this locking method is, in particular, advisable
              if MMDF files are  accessed  through  the  Network  File  System
              (NFS),  since  it  seems the only way to reliably invalidate NFS
              clients' caches.

       ·      flock(2) locking is mostly used on BSD-based systems.

       ·      Dotlocking is used on all kinds of systems. In order to lock  an
              MMDF file named folder, an application first creates a temporary
              file with a unique name in the directory  in  which  the  folder
              resides.  The  application  then tries to use the link(2) system
              call to create a hard link named folder.lock  to  the  temporary
              file.   The  success  of  the  link(2)  system  call  should  be
              additionally verified using  stat(2)  calls.  If  the  link  has
              succeeded,   the   mail  folder  is  considered  dotlocked.  The
              temporary file can then safely be unlinked.

              In order to release the lock, an application  just  unlinks  the
              folder.lock file.

       If  multiple methods are combined, implementors should make sure to use
       the non-blocking variants of the fcntl(2) and flock(2) system calls  in
       order to avoid deadlocks.

       If  multiple  methods are combined, an MMDF file must not be considered
       to have been successfully  locked  before  all  individual  locks  were
       obtained.  When  one  of  the  individual  locking  methods  fails,  an
       application should release all  locks  it  acquired  successfully,  and
       restart  the  entire  locking  procedure  from  the  beginning, after a
       suitable delay.

       The locking mechanism used on a particular system is a matter of  local
       policy,  and  should be consistently used by all applications installed
       on the system which access MMDF files. Failure to do so may  result  in
       loss of e-mail data, and in corrupted MMDF files.


       MMDF is not part of any currently supported standard.


       MMDF was developed at the University of Delaware by Dave Crocker.


       scomail(1),  fcntl(2),  flock(2),  link(2),  stat(2),  mbox(5), RFC822,


       Urs Janssen <>