Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
mmdf(5)				 User Manuals			       mmdf(5)

       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	 post-
       mark.  The  file	 format	 is line-oriented. Lines are separated by line
       feed characters (ASCII 10). A postmark line consists of the four	 char-
       acters "^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 mes-
       sages have already been read.

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

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

       o      fcntl(2) locking is mostly used on recent, POSIX-compliant  sys-
	      tems. 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'

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

       o      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 re-
	      sides. 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  ob-
       tained.	When  one of the individual locking methods fails, an applica-
       tion 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 <>

Unix			      February 18th, 2002		       mmdf(5)


Want to link to this manual page? Use this URL:

home | help