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 RFC5322, followed	 by  a	postmark.  The
       file  format is line-oriented. Lines are	separated by line feed charac-
       ters (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) and RFC4155)	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), RFC4155,

       Urs Janssen <>

Unix			      November 5th, 2013		       mmdf(5)


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

home | help