The tools in the Internet Utilities store mail folders in a standard format. Each folder is a directory, with individual messages in the folder being stored in individual files.
There are several well-known advantages of this format over, for example, the "mboxrd" format used by Mozilla to store mail folders:
The operating system handles the nitty-gritty of dividing messages, and messages are stored exactly as-is, without any modification.
In the "mbox" system, the applications software has to scan for
From_ lines itself, has to handle removing trailing newlines,
and has to handle "From" quoting.
Data corruption of one message only corrupts that one file. The folder overall is unaffected.
In the "mbox" system, corruption of a message potentially corrupts the entire
mailbox beyond that file. (Consider, for example, a message that is
erroneously stored with a From_ line in its body.)
Non-sequential access to individual messages, if their IDs within the mailbox are known, is fast.
In the "mbox" system, non-sequentially accessing message #N in the mailbox requires reading the N-1 messages that precede it.
In the Internet Utilities, a standard format mail directory contains one message per file. The data semantics of a message are simple: The contents of the file are exactly the contents of the message, unadorned and unchanged. Messages are stored 8-bit clean. There's no need for any encoding of non-7-bit data.
Messages and mail directories also have metadata. Mostly these metadata map to the metadata of messages and mail folders as in IMAP.
The message UID of a message is derived from its filename.
Message filenames take the form number.TXT. The
number encodes the UID, as a 32-bit hexadecimal number. Picking
this number for a new message, in order to comply with the IMAP semantics
of UIDs, is done by a standard routine for inserting messages into a
mailbox.
The UID for a new message is the next UID value for a mail
directory. It is calculated by scanning the directory for
*.TXT files and picking the maximum of the last write
timestamp of the directory (as a 32-bit POSIX timestamp) and 1 greater
than the largest UID of an existing message.
This requires that the last write timestamp must be updated every time
that a message is added to the maildir directory. This happens
automatically on TAU, but not on IBM OS/2. Applications that deposit
files into mail directories must manually update the directory's timestamp
on IBM OS/2. Similarly, if one adds a message to a directory by hand, one
must use something like the TOUCH command in
the OS/2 Command Line Utilities version 2.2
to manually update the directory's timestamps.
The UID validity of a mail directory is the creation timestamp of the maildir directory. Creating a new mail directory afresh sets a new UID validity. Otherwise, the UID validity of the mail directory lasts for the lifetime of the directory, and UIDs never become invalid.
The internal date of a message is simply the last write timestamp of the file containing that message. (As is correct practice in general, all file timestamps are in TAI/UTC, not local time, note.) Similarly, the RFC2822 Size of a message is simply the size of its file.
Message flags are stored as extended attributes. In particular,
they are stored in the .KEYPHRASES extended attribute. This
is the extended attribute that the Workplace Shell displays as the
"keywords" property in a file object's properties.
The flags are always written as a MVMT (Multi-Valued Multiple Type)
extended attribute, where all values are EAT_ASCII (with the
code page ignored). But the Internet Utilities is capable of
reading flags stored as MVST (Multi-Valued Single Type) extended
attributes (as long as that type is EAT_ASCII) or that are
stored as a straight EAT_ASCII single value.
The mail directory format specification itself places no restrictions upon
flags. A message can have any flags expressible as an
EAT_ASCII string. What flags are conventionally recognized
and their ascribed meanings is defined outside of the scope of the mail
directory format specification. For information, therefore: The
following flags are defined …
… by IMAP itself:
\Recent,
\Seen,
\Answered,
\Flagged,
\Deleted, and
\Draft.
… by Mozilla:
Junk,
NotJunk,
$Label1,
$Label2,
$Label3,
$Label4, and
$Label5.
… by the
MBSPLIT command
as a Mozilla extension (to express all possible states of a
X-Mozilla-Status2 header):
$Label6, and
$Label7.
… by RFC 3503:
$MDNSent.
… by Alexey Melnikov's
common IMAP keywords for MUAs specification:
$Forwarded,
$Work,
$Personal,
$ToDo,
$ShouldReply,
$Important,
$AutoJunk,
$AutoMaybeJunk,
$AutoNotJunk,
$Junk,
$NotJunk.