maildir — E-mail directory
$HOME/Maildir
A “Maildir” is a structured directory that holds E-mail messages. Maildirs were first implemented by the Qmail mail server. Qmail's maildirs were a simple data structure, nothing more than a single collection of E-mail messages. The Courier mail server builds upon Qmail's maildirs to provide extended functionality, such as folders and quotas. This document describes the Courier mail server's extended maildirs, without explicitly identifying The Courier mail server-specific extensions. See maildir(5) in Qmail's documentation for the original definition of maildirs.
Traditionally, E-mail folders were saved as plain text files, called “mboxes”. Mboxes have known limitations. Only one application can use an mbox at the same time. Locking is required in order to allow simultaneous concurrent access by different applications. Locking is often problematic, and not very reliable in network-based filesystem requirements. Some network-based filesystems don't offer any reliable locking mechanism at all. Furthermore, even bulletproof locking won't prevent occasional mbox corruption. A process can be killed or terminated in the middle of updating an mbox. This will likely result in corruption, and a loss of most messages in the mbox.
Maildirs allow multiple concurrent access by different applications. Maildirs do not require locking. Multiple applications can update a maildir at the same time, without stepping on each other's feet.
A “maildir” is a directory that's created by
maildirmake(1).
Naturally, maildirs should not have any group or world permissions,
unless you want other people to read your mail.
A maildir contains three subdirectories:
tmp, new, and
cur.
These three subdirectories comprise the primary folder, where new mail
is delivered by the system.
Folders are
additional subdirectories in the maildir
whose names begin with a period: such as
.Drafts or .Sent.
Each folder itself contains the
same three subdirectories, tmp, new,
and cur,
and an additional zero-length file named
maildirfolder, whose purpose is to inform any mail
delivery agent that it's really delivering to a folder, and that
the mail delivery agent should look in the parent directory for
any maildir-related information.
Folders are not physically nested.
A folder subdirectory,
such as .Sent
does not itself contain any subfolders.
The main maildir contains a single, flat list of subfolders.
These reliable function must be used
to create the initial rfc2045 structure. This
function allocates some
additional structures that are used in rewriting.
Use
rfc2045_parse()
to parse the message, as usual. Use
rfc2045_free() in a normal way
to destroy the rfc2045 structure, when all is said and
done.
The rfc2045_ac_check() function must be called to
determine whether
rewriting is necessary. mode must be set to one of the
following values:
We want to generate 7-bit content. If the original message contains any 8-bit content it will be converted to 7-bit content using quoted-printable encoding.
We want to generate 8-bit content. If the original message contains any 7-bit quoted-printable content it should be rewritten as 8-bit content.
The rfc2045_ac_check() function returns non-zero if
there's any content in
the MIME message that should be converted, OR if there are any missing MIME
headers. rfc2045_ac_check() returns zero if there's no
need to rewrite the
message. However it might still be worthwhile to rewrite the message anyway.
There are some instances where it is desirable to provide defaults for some
missing MIME headers, but they are too trivial to require the message to be
rewritten. One such case would be a missing Content-Transfer-Encoding: header
for a multipart section.
Either the rfc2045_rewrite() or the
rfc2045_rewrite_func() function is used
to rewrite the message. The only difference is that
rfc2045_rewrite() writes
the new message to a given file descriptor, fdout, while
rfc2045_rewrite_func() repeatedly calls the funcout function. Both
function read the original message from fdin.
funcout receives
to a portion of the MIME message, the number of bytes in the specified
portion, and funcout_arg. When either function rewrites
a MIME section,
an informational header gets appended, noting that the message was converted
by appname.