User Manuals mmdf(5)
NAME
MDF - Multi-channel Memorandum Distribution Facility mail-
box format
DESCRIPTION
This document describes the MDF mailbox format used by some
MTAs and MUAs (i.e. scomail(1)) to store mail messages
locally.
An MDF mailbox is a text file containing an arbitrary
number of e-mail messages. Each message consists of a post-
mark, 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
(ASCI 10). A postmark line consists of the four characters
"^A^A^A^A" (Control-A; ASCI 1).
Example of a MDF mailbox holding two mails:
^A^A^A^A
From: example@example.com
To: example@example.org
Subject: test
>From what I learned about the MDF-format:
^A^A^A^A
^A^A^A^A
From: example@example.com
To: example@example.org
Subject: test 2
bar
^A^A^A^A
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 MDF 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.
LOCKING
Since MDF files are frequently accessed by multiple pro-
grams in parallel, MDF files should generally not be
accessed without locking.
Three different locking mechanisms (and combinations
thereof) are in general use:
Unix Last change: February 18th, 2002 1
User Manuals mmdf(5)
]o fcntl(2) locking is mostly used on recent, POSIX-
compliant systems. Use of this locking method is, in
particular, advisable if MDF files are accessed
through the Network File System (NFS), since it seems
the only way to reliably invalidate NFS clients'
caches.
]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 MDF 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 addition-
ally verified using stat(2) calls. If the link has suc-
ceeded, 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 MDF file must not be
considered to have been successfully locked before all indi-
vidual locks were obtained. When one of the individual lock-
ing 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 MDF
files. Failure to do so may result in loss of e-mail data,
and in corrupted MDF files.
CONFORMING TO
MDF is not part of any currently supported standard.
HISTORY
MDF was developed at the University of Delaware by Dave
Crocker.
SEE ALSO
scomail(1), fcntl(2), flock(2), link(2), stat(2), mbox(5),
RFC822, RFC2822
Unix Last change: February 18th, 2002 2
User Manuals mmdf(5)
AUTHOR
Urs Janssen
ATRIBUTES
See attributes(5) for descriptions of the following attri-
butes:
ATRIBUTE TYPE ATRIBUTE VALUE
Availability SUNWmutt
Interface Stability Committed
NOTES
Source for mutt is available on http:/opensolaris.org.
Unix Last change: February 18th, 2002 3
|
