Hubbry Logo
MaildirMaildirMain
Open search
Maildir
Community hub
Maildir
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Maildir
Maildir
Maildir
View on Wikipedia
from Wikipedia

The Maildir e-mail format is a common way of storing email messages on a file system, rather than in a database. Each message is assigned a file with a unique name, and each mail folder is a file system directory containing these files. Maildir was designed by Daniel J. Bernstein circa 1995, with a major goal of eliminating the need for program code to handle file locking and unlocking through use of the local filesystem.[1] Maildir design reflects the fact that the only operations valid for an email message is that it be created, deleted or have its status changed in some way.

Internal structure

Specifications

[edit]

A Maildir directory (often named Maildir) usually has three subdirectories named tmp, new, and cur.[2]

  • The tmp subdirectory temporarily stores e-mail messages that are in the process of being delivered. This subdirectory may also store other kinds of temporary files.
  • The new subdirectory stores messages that have been delivered, but have not yet been seen by any mail application.
  • The cur subdirectory stores messages that have already been seen by mail applications.[3]

Maildir++

[edit]

Sam Varshavchik, the author of the Courier Mail Server and other software, defined the Maildir++ extension[3][4] to the Maildir format to support subfolders and mail quotas. Maildir++ directories contain subdirectories with names that start with a '.' (dot) which are also Maildir++ folders. The extension complies with the original Maildir specification, which allows for subdirectories in addition to tmp, new and cur.

Technical operation

[edit]

A mail delivery agent is a program that delivers an email message into a Maildir. The mail delivery agent creates a new file with a unique filename in the tmp directory.[5][6][3] At the time of its invention guaranteeing unique filenames efficiently was difficult. The original qmail[1] algorithm for unique names was:

  1. read the current Unix time
  2. read the current process identifier (PID)
  3. read the current hostname
  4. concatenate the above three values into a string separated by the period character; this is the new filename
  5. if stat() reports that the filename exists, then wait two seconds
  6. go to previous step until the filename does not exist
  7. create a file with the unique filename and write the message contents to the new file

By 2000, the qmail author recommended in an updated specification[5] to append the value of a per-process counter to the PID, whose value should be incremented after each delivery. The rate-limiting recommendation to "wait two seconds" was dropped.

By 2003, the recommendations had been further amended to require that instead of the PID and counter, the middle part of the filename should be created by "concatenating enough of the following strings to guarantee uniqueness" even in the face of multiple simultaneous deliveries to the same maildir from one or more processes:[7]

  • #n, where n is (in hexadecimal) the output of the operating system's unix_sequencenumber() system call, which returns a number that increases by 1 every time it is called, starting from 0 after reboot.
  • Xn, where n is (in hexadecimal) the output of the operating system's unix_bootnumber() system call, which reports the number of times that the system has been booted. Together with #, this guarantees uniqueness; unfortunately, most operating systems don't support unix_sequencenumber() and unix_bootnumber().
  • Rn, where n is (in hexadecimal) the output of the operating system's unix_cryptorandomnumber() system call or an equivalent source, such as /dev/urandom. Unfortunately, some operating systems don't include cryptographic random number generators.
  • In, where n is (in hexadecimal) the UNIX inode number of this file. Unfortunately, inode numbers aren't always available through NFS.
  • Vn, where n is (in hexadecimal) the UNIX device number of this file. Unfortunately, device numbers aren't always available through NFS. (Device numbers are also not helpful with the standard UNIX filesystem: a maildir has to be within a single UNIX device for link() and rename() to work.)
  • Mn, where n is (in decimal) the microsecond counter from the same gettimeofday() used for the left part of the unique name.
  • Pn, where n is (in decimal) the process ID.
  • Qn, where n is (in decimal) the number of deliveries made by this process.

This 2003 algorithm was criticised[8] in 2006 as being unnecessarily complex by Timo Sirainen, the creator of Dovecot.

As of November 2023, qmail author Daniel Bernstein had made no further changes to the 2003 filename generation recommendations.[9] On modern POSIX systems, temporary files can be safely created with the mkstemp C library function.

The delivery process stores the message in the maildir by creating and writing to tmp/uniquefilename, and then moving this file to new/uniquefilename. The moving can be done using rename, which is atomic in many systems.[10] Alternatively, it can be done by hard-linking the file to new and then unlinking the file from tmp. Any leftover file will eventually be deleted. This sequence guarantees that a maildir-reading program will not see a partially written message. There can be multiple programs reading a maildir at the same time. They range from mail user agents (MUAs), which access the server's file system directly, through Internet Message Access Protocol or Post Office Protocol servers acting on behalf of remote MUAs, to utilities such as biff and rsync, which may or may not be aware of the maildir structure. Readers should never look in tmp.

When a cognizant maildir-reading process (either a POP or IMAP server, or a mail user agent acting locally) finds messages in the new directory, it must move them to cur. It is just a means to notify the user "you have X new messages".[11] This moving needs to be done using the atomic filesystem rename(), as the alternative link-then-unlink technique is non-atomic and may result in duplicated messages. An informational suffix is appended to filenames at this stage. It consists of a colon (to separate the unique part of the filename from the actual information), a "2", a comma and various flags. The "2" specifies the version of the information that follows the comma. "2" is the only currently officially specified version, "1" being an experimental version. The specification defines flags that show whether the message has been read, deleted and so on: the initial (capital) letter of "Passed", "Replied", "Seen", "Trashed", "Draft", and "Flagged".[7] Applications often choose to supplement this very limited set of flags, for example notmuch[12] offers flag synchronization in addition to arbitrary user-defined flags,[13] while Dovecot uses lowercase letters to match 26 IMAP keywords,[6] which may include keywords such as $MDNSent or user-defined flags.

Although Maildir was intended to allow lockless usage, in practice some software that uses Maildirs also uses locks, such as Dovecot.[14]

File-system compatibility issues

[edit]

The Maildir standard can only be implemented on systems that accept colons in filenames. [15]

Systems that don't allow colons in filenames (this includes Microsoft Windows and some configurations of Novell Storage Services) can use a non-standard alternative separator, such as ";" or "-". It is often trivial to patch free and open-source software to use a different separator.[16]

As there is currently no agreement on what character this alternative separator should be, there can be interoperability difficulties between different Maildir-supporting programs on these systems. However, not all Maildir-related software needs to know what the separator character is, because not all Maildir-related software needs to be able to read or modify the flags of a message ("read", "replied to" etc.); software that merely delivers to a Maildir or archives old messages from it based only on date, should work no matter what separator is in use. If only the MUA needs to read or modify message flags, and only one MUA is used, then non-standard alternative separators may be used without interoperability problems.

Software that supports Maildir directly

[edit]

Mail servers

[edit]

Delivery agents

[edit]

Mail readers

[edit]

Notes and references

[edit]

See also

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Maildir

View on Grokipedia
from Grokipedia
Maildir is a directory-based storage format in which each message is stored as a separate file within a mailbox directory, eliminating the need for file locking and enabling safe concurrent access by multiple processes. This format structures the mailbox with three essential subdirectories: tmp/ for temporary message delivery, new/ for newly arrived unread messages, and cur/ for messages that have been read or processed. Designed to address limitations of earlier formats like , Maildir ensures message integrity by writing files atomically and supports reliable operation over network file systems such as NFS. Developed by in the mid-1990s as part of the mail transfer agent, Maildir debuted to provide a more secure and efficient alternative to traditional single-file mailbox systems. Each file follows a unique incorporating a , , delivery identifier, and optional flags (e.g., 1491941793.M41850P8566.example.com:2,S), where the info portion after the colon denotes status flags like read, flagged, or replied. This structure prevents partial deliveries and corruption risks inherent in appending to a shared file, making it particularly advantageous for multi-user environments and high-volume servers. Widely adopted in modern email systems, Maildir is supported by servers like Postfix, Dovecot, and , as well as clients such as Mutt and Thunderbird (with recent experimental support). Extensions like Maildir++ enhance it for hierarchical folders and quotas, while implementations often include index files (e.g., dovecot-uidlist) for faster IMAP access and keyword handling. Its simplicity and robustness have made it a standard for systems, prioritizing data safety without compromising performance.

Introduction

Definition and Purpose

Maildir is an on-disk email storage format that organizes individual email messages as separate files within a directory-based structure, distinct from concatenated formats like that store all messages in a single shared file. This approach inherently avoids the file locking issues prevalent in mbox, where multiple processes accessing the same file risk race conditions, partial writes, or . The primary purpose of Maildir is to facilitate safe, concurrent access to email storage by multiple processes—such as mail delivery agents and user agents—without requiring locks or synchronization mechanisms, thereby minimizing the potential for errors in multi-user or networked environments. Designed specifically for systems, it ensures that operations like delivery and retrieval can occur simultaneously across processes or even over network file systems like NFS, with guaranteed message integrity. At its core, Maildir separates email storage into per-user directories, each containing three subdirectories: tmp for temporary message creation, new for incoming unread messages, and cur for messages that have been processed or read. Delivery follows an atomic process where a message is fully written to the tmp subdirectory before being renamed and moved to new, ensuring the operation is indivisible and complete even if interrupted. Maildir was introduced by as part of the mail transfer agent's delivery model, emphasizing reliability and robustness in shared hosting scenarios over absolute performance optimizations.

History and Development

The Maildir format was developed by as part of the mail transfer agent, with initial work beginning in December 1995 to address the limitations of traditional formats, such as risks of corruption from concurrent access and the need for file locking mechanisms. 's beta versions incorporated Maildir as an optional mailbox structure to enable reliable delivery without locking, even over network file systems like NFS, ensuring messages could be safely appended during crashes or simultaneous operations. The format was first specified in 0.90, released on August 1, 1996, and became part of the stable 1.00 release on February 20, 1997. Adoption of Maildir expanded beyond qmail in the early 2000s, driven by its reliability advantages for multi-user environments. Postfix, a widely used mail transfer agent, integrated native Maildir support from its inaugural version 1.0, released in February 2001, allowing seamless delivery to Maildir directories via configuration parameters like home_mailbox = Maildir/. The Courier mail server, released in 1999, also adopted Maildir and extended it for IMAP folder hierarchies. Dovecot, an IMAP and POP3 server launched in July 2002, further popularized the format by incorporating it as a default storage option in the early 2000s. A key evolutionary milestone was the introduction of Maildir++ by the project in the early 2000s to support hierarchical mailboxes for IMAP, using dotted subdirectories (e.g., .Sent) and adding message flags and keywords via filename extensions, which Dovecot later adopted for enhanced IMAP compatibility. Although Maildir has not been formally ratified as an IETF standard, RFC 6778 (2012) specifies requirements for IETF list archiving systems to support Maildir as a one-message-per-file format for import and export, reflecting ongoing efforts to document its use in IETF contexts like list archives. Its popularity surged in the 2010s alongside the rise of IMAP servers, as implementations like Dovecot and Postfix emphasized its scalability for large-scale deployments. Modern adaptations of Maildir, particularly post-2015, have incorporated support for filenames to handle internationalized , leveraging underlying capabilities and protocols like SMTPUTF8 in Postfix 3.0 (released February 2015), which enables in message headers and addresses without corrupting directory structures. Dovecot implementations from this period also updated folder naming to better accommodate via modified encoding for IMAP compatibility, ensuring robustness in global environments while preserving the format's core atomic delivery principles.

Format Specifications

Core Directory Structure

The Maildir format organizes email storage in a per-user , typically named Maildir, which serves as the foundation for all message handling without requiring database locks or shared files. This contains exactly three subdirectories: tmp for temporary message delivery, new for incoming undelivered messages, and for messages that have been delivered and potentially read. The tmp subdirectory is used exclusively for atomic writes during message delivery, where a mail delivery agent (MDA) writes the message file to a unique temporary name to avoid corruption from concurrent operations; once complete, the file is atomically renamed or linked into new to ensure safe integration into the mailbox. The new subdirectory holds messages ready for retrieval by the mail user agent (MUA), representing undelivered or unseen mail that has not yet been processed. In contrast, the cur subdirectory stores messages that have been accessed or manipulated, with filenames optionally appended by an Info string (e.g., status flags like 'S' for seen or 'R' for replied) to track user interactions without altering the message content itself. These rules enable race-free operations across multiple processes, as the format relies on filesystem semantics rather than explicit locking. To support hierarchical organization beyond a single inbox, Maildir incorporates extensions for subfolders using the convention of prefixed dot-directories, such as .Sent/ or .Archive/, each replicating the standard tmp, new, and structure within the parent root (e.g., Maildir/.Sent/{tmp,new,cur}). This allows for categorized storage like sent mail or drafts while maintaining the core format's integrity. A distinctive feature of Maildir is the absence of any central index file or metadata database; instead, message lists are generated by scanning the new and cur subdirectories at runtime, which promotes scalability in distributed environments but can increase I/O overhead for large mailboxes due to repeated filesystem traversals.

File Naming and Content Rules

In the Maildir format, filenames for message files in the tmp and new subdirectories are designed to ensure uniqueness without relying on atomic operations beyond standard filesystem rename capabilities. The original specification recommends a structured format consisting of the current Unix timestamp in seconds since January 1, 1970 (e.g., 1234567890), followed by a dot, a delivery identifier (typically including the process ID, queue ID, and microsecond fraction for granularity, such as M12345P001), another dot, and the fully qualified hostname (with invalid characters escaped, e.g., server.example.com). This results in examples like 1234567890.M12345P001.server.example.com, preventing collisions even for simultaneous deliveries on the same system. Each Maildir file stores a complete, unmodified conforming to the Internet Message Format specified in RFC 5322, encompassing all original headers followed immediately by the body, which may include and need not end with a . No additional metadata, such as UUCP-style "From_" lines or quoting of special characters, is inserted during storage to preserve the 's integrity. Upon processing, when a message is relocated from new to the cur subdirectory, an optional info string may be appended to the filename in the form :2,flags, where flags are a comma-separated sequence of status indicators in ASCII order, such as RS for replied and seen (:2,RS). The base specification defines flags including R (replied), S (seen), D (draft), F (flagged), P (passed), A (answered, implementation-specific), and T (trashed), though their usage is optional and varies by implementation. Delivered files in new and cur are treated as immutable, with no further modifications permitted to ensure safe concurrent access by multiple processes. File size limits are governed by the filesystem; for example, modern supports individual files up to 16 terabytes.

Maildir++ Extensions

Maildir++ is a Dovecot-specific extension to the base Maildir format, introduced in 2003 to enhance support for advanced IMAP4rev1 features such as message flags and custom keywords. This extension modifies the Info portion of message filenames—appended after the second colon in the format <time>.<host>.<pid>.<random>:2,<info>—to include a comma-separated list of flags without altering the core file content or naming conventions. For instance, a filename might end in :2,SFRAK, where S denotes seen, F flagged, R replied, A answered, and K a custom keyword, enabling IMAP clients to track message states efficiently. A key addition in Maildir++ is the support for up to 26 custom IMAP keywords, mapped to lowercase letters a through z via a dovecot-keywords file in the mailbox root, with each keyword limited to 32 characters. These keywords allow for user-defined labels like $Junk or $Important, expanding beyond the standard Maildir flags (D for draft, F for flagged, P for passed, R for replied, S for seen, T for trashed). The doveadm utility facilitates management of these extensions, including commands to search, copy, or expunge messages based on flags and keywords. Maildir++ maintains backward compatibility with standard Maildir implementations by preserving unrecognized fields, though strict qmail-based systems may ignore or overwrite the extended info during delivery. Unlike the original Maildir specification by , which lacks native IMAP keyword support, Maildir++ originated as a -IMAP innovation and was adopted by Dovecot for its IMAP server, with variants appearing in some implementations. This extension is not part of the core spec and can lead to issues in environments enforcing strict adherence to the original format, as non-standard fields like size metadata (e.g., ,S=<bytes>) may be discarded by other mail user agents.

Operational Mechanics

Message Delivery Process

The message delivery process in Maildir relies on a structured workflow designed to ensure atomicity and concurrency without the need for file locking. A delivery agent, such as a local mail transfer agent, begins by generating a unique filename for the incoming message, typically in the format time.&lt;delivery_identifier&gt;.&lt;hostname&gt;, where time is the current Unix timestamp in seconds, delivery_identifier is a unique string (e.g., starting with M followed by process ID or counter) to ensure uniqueness across deliveries on the same host within the same second, and hostname has / replaced by \057 and : by \072 to handle invalid characters. The agent then creates a temporary file in the tmp subdirectory using this name and writes the complete message content to it, verifying that all bytes are successfully written to prevent partial deliveries. Once the message is fully written to the , the agent performs an atomic rename operation to move it to the new subdirectory, preserving the unique filename; this rename is guaranteed to be atomic on filesystems, ensuring that either the entire message appears in new or it remains in tmp if the operation fails, thus avoiding race conditions with concurrent readers or other deliverers. To handle potential duplicates, the agent checks for the existence of a file with the same base and identifier in the new or cur subdirectories before proceeding; if found, it retries with a modified identifier after a short delay, such as 2 seconds. Additionally, to prevent mail loops in aliasing or forwarding scenarios, delivery agents like those in add a Delivered-To header containing the recipient and check for its presence matching the target before delivering, refusing delivery if a loop is detected. Maildir files and directories enforce strict permissions for and : the Maildir root and its subdirectories (tmp, new, [cur](/page/Cur)) are owned by the recipient user with mode 0700, preventing access by other users or groups, while individual message files are owned by the user with mode 0600, readable and writable only by the owner. This setup assumes delivery runs as the recipient user or with appropriate privileges to set ownership. The absence of locking is a core feature, enabled by the atomic rename and unique filenames, allowing multiple deliveries and retrievals to occur simultaneously without interference on the same Maildir. For error handling, delivery agents return standardized exit codes from <sysexits.h>: for instance, code 71 (EX_OSERR) or 75 (EX_TEMPFAIL) indicates a temporary failure, such as inability to access the tmp directory or write the file, prompting the mail transfer agent to retry later, while permanent errors like quota exceeded result in code 0 or other values leading to bounces. If the rename fails after successful writing, the file remains in tmp for potential cleanup or retry.

Message Retrieval and Management

In the Maildir format, message retrieval begins with mail user agents (MUAs) or servers scanning the new/ subdirectory for unseen messages, which are stored as individual files with unique filenames typically formatted as time.delivery_identifier.hostname, where the delivery_identifier often includes details like process ID and, in some implementations, microseconds, reflecting the delivery time. Upon accessing a message, the MUA moves the file from new/ to the cur/ subdirectory and appends an info string to the filename, such as :2,S to indicate the "seen" , allowing status tracking without modifying the message content. Messages in cur/ retain their original delivery timestamp in the filename for ordering, while the file's modification time (mtime) is preserved and used by many implementations for sorting purposes, aligning with IMAP's INTERNALDATE attribute as defined in RFC 3501. Management operations in Maildir emphasize simple filesystem actions for efficiency and reliability. Deletion is performed by unlinking the file directly from new/ or cur/, removing it atomically without affecting other messages. Archiving involves moving the file to a subfolder, represented as a dotted subdirectory like .Archive/cur/, which maintains the Maildir structure recursively while preserving the filename and flags. Basic searching relies on filesystem tools to scan directories or grep contents, though for larger stores, external indexing tools are commonly employed since Maildir lacks native support for threading or full-text search. Maildir's design ensures concurrency safety during retrieval and management, as all messages are independent files, allowing multiple MUAs to read from new/ and cur/ without locks or coordination, even over network filesystems like NFS. Writes, such as deliveries or moves, are restricted to authorized processes that use the tmp/ subdirectory for temporary staging, ensuring atomicity and preventing conflicts through unique filename generation. Post-2010 developments like the notmuch indexer, which builds a Xapian-based database over Maildir stores for tag-based searching and threading, and mu, a similar tool for fast querying by metadata and content, address the format's limitations in scalable retrieval for large archives.

Compatibility and Limitations

File System Compatibility

Maildir relies on POSIX-compliant filesystems that support atomic rename operations to ensure safe message delivery without the need for locking mechanisms. This atomicity, provided by the rename() , allows messages to be moved from the temporary (tmp) subdirectory to the new (new) subdirectory in a single, uninterruptible operation, preventing partial deliveries or duplicates. Examples of suitable filesystems include , , , and , which meet these requirements as defined in the . In addition to atomic renames, Maildir requires support for long pathnames exceeding 255 characters and large individual file sizes to accommodate deeply nested directory structures in extensions like Maildir++ and sizable attachments. standards define a minimum _POSIX_PATH_MAX of 256 bytes for total path lengths (though many implementations support larger values, such as 4096 on ) and NAME_MAX of at least 14 characters per component (though modern implementations typically support 255), enabling the format's scalability. Large file support, as per Large File Specification extensions, is also essential for handling messages beyond 2 GB without truncation. Maildir operates fully on Unix-like systems such as , BSD variants, and macOS, where native filesystems like , UFS, and APFS provide the necessary features. On Windows, compatibility is partial and typically achieved through environments like , which emulates semantics atop ; however, limitations arise due to Windows' restriction on colons (:) in filenames, a character integral to Maildir's unique message (e.g., 1234567890.M123P456Q789R,c:2,S). Samba can facilitate access to Maildir stores on shared Unix filesystems, but Windows clients face similar rename atomicity and character constraints when writing. Certain filesystems pose specific challenges for Maildir. FAT32 and VFAT, common in cross-platform , prohibit colons in filenames and lack robust atomic rename guarantees in non-POSIX contexts, rendering them unsuitable for reliable Maildir use despite support for long filenames. NFSv3 environments can encounter performance issues related to directory listing operations (e.g., readdirplus), though Maildir's lock-free design mitigates traditional locking problems; mounting with the nordirplus option is recommended to address these. Case-sensitive filesystems are advised to avoid potential conflicts in folder naming, as case-insensitive variants like the default configuration of APFS on macOS (as of macOS 10.13 and later) may lead to ambiguities in subfolder hierarchies. Modern filesystems enhance Maildir's efficiency through features like TRIM support on SSDs, which enables automatic space reclamation upon message deletion by issuing discard commands during unlink operations, reducing wear and improving performance. Since around 2008, with the widespread adoption of as the standard encoding for filenames in systems, Maildir has benefited from native support in path components, allowing internationalized folder names without additional encoding layers.

Common Issues and Workarounds

One common issue with the Maildir format is disk space inefficiency arising from storing each email as a separate file, which leads to overhead from filesystem metadata, inodes, and minimum block allocation sizes, particularly for small messages. For instance, on filesystems such as or , even tiny files typically consume at least 4 KB, resulting in significant bloat for inboxes with thousands of short emails. Another frequent problem occurs with large inboxes containing millions of messages, where scanning the directory for new or unread becomes slow due to the filesystem's need to enumerate and inspect numerous files, exacerbating performance on shared or network filesystems like NFS. To address this, external indexers such as mu, which builds a Xapian database for , enable rapid querying without full directory scans. Quota enforcement poses challenges in the original Maildir specification, which lacks built-in limits, allowing mailboxes to grow unbounded and complicating on servers hosting multiple users. The Maildir++ extension mitigates this by introducing a maildirsize file that tracks total bytes and message count, enforcing soft quotas through delivery agents like those in Courier MTA, though updates occur periodically (every 15 minutes) and can be bypassed by non-compliant clients. Early Maildir implementations were susceptible to symlink attacks in the tmp/ subdirectory during message delivery, where a local attacker could create a pointing to a sensitive file, causing the delivery process to overwrite arbitrary locations if it followed the link before writing. This vulnerability, exemplified in tools like and getmail, was largely mitigated in secure delivery agents after 2005 through techniques like exclusive file opens (O_EXCL) or creation APIs that prevent race conditions. Interrupted deliveries in Maildir leave incomplete files in the tmp/ directory, as the atomic rename to new/ fails; these stale files accumulate if not addressed, potentially filling disk space. Periodic cleanup scripts, often run via , resolve this by deleting tmp/ files older than 36 hours, a threshold recommended in specification to balance safety and storage. The format's reliance on frequent small writes—for deliveries, updates, and moves—can accelerate wear on solid-state drives (SSDs) due to and limited program/erase cycles, though modern SSDs with overprovisioning mitigate this for typical workloads. In Dovecot 2.3 and later (released ), lazy scanning optimizes this by checking the cur/ directory's modification time instead of rescanning all files on every access, reducing unnecessary I/O.

Software Integration

Mail Transfer and Delivery Agents

Mail Transfer Agents (MTAs) and Mail Delivery Agents (MDAs) play crucial roles in handling and local delivery to Maildir-format mailboxes, ensuring reliable storage without the locking issues common in older formats like . Several prominent open-source MTAs natively or configurably support Maildir delivery, originating from the format's introduction with in 1996. These agents leverage Maildir's file-per-message structure to enable concurrent access and atomic delivery operations. qmail, developed by , was the first MTA to implement Maildir as its default storage format upon its initial release in 1996, emphasizing strict adherence to the specification for reliability and security in high-volume environments. Postfix, introduced in 2001, provides built-in Maildir support through its delivery mechanism, allowing messages to be appended to individual files in the specified directory when the mailbox path ends with a slash. A key feature in Postfix is the virtual_mailbox_domains parameter, which defines domains for virtual mailboxes stored in Maildir format, enabling efficient handling of multiple domains without system user accounts. offers configurable Maildir support via its appendfile transport, where delivery to a directory with maildir_format enabled creates files using the standard Maildir (timestamp, , delivery identifier), supporting both and virtual users through runtime options. For local delivery, several MDAs integrate seamlessly with Maildir. , a filtering-capable MDA, supports Maildir delivery through configuration, such as appending a slash to the folder path in recipes, allowing recipe-based sorting into subfolders while respecting the format's structure. maildrop, part of the Courier mail server suite, natively supports Maildir delivery with built-in filtering, extending qmail's format to include features like quotas and hierarchical folders. Dovecot's LMTP (Local Mail Transfer Protocol) implementation serves as an MDA for final delivery to Maildir, handling authentication and indexing in a single process to minimize overhead during local drops. Integration between MTAs and MDAs often involves simple configuration directives; for example, Postfix can invoke for Maildir delivery by setting mailbox_command = /usr/bin/[procmail](/page/Procmail) -a "$EXTENSION" in its main.cf file, passing recipient extensions for virtual aliasing. This setup ensures filtered delivery while maintaining Maildir's atomicity, as referenced in the broader message delivery process.

Mail User Agents and Clients

Several prominent mail user agents (MUAs) and clients provide native or configurable support for directly reading and managing Maildir stores, enabling efficient local email handling without relying on server-side protocols for basic operations. Mutt, a longstanding text-based originating in the mid-1990s, includes built-in support for the Maildir format among its multiple mailbox options, allowing users to configure it as the default storage type for seamless message access and manipulation. NeoMutt, a 2016 of Mutt, inherits and enhances this capability with advanced features like improved header caching and sidebar navigation, making it suitable for power users managing large Maildir directories. Graphical clients such as , as of 2025, use Maildir as their default storage format, providing native support for reading and managing Maildir directories for offline access, importing, and organization. GNOME Evolution offers robust Maildir integration via dedicated account types, supporting the layout for local or downloaded messages and allowing direct configuration of Maildir paths for personal folders. IMAP-focused clients and servers extend Maildir accessibility over the network; Dovecot, a widely used IMAP server, employs Maildir as its default backend, enabling any standards-compliant IMAP client to retrieve and manage messages while maintaining the underlying file-based structure for flags and metadata. Courier-IMAP provides legacy IMAP access to Maildir stores, particularly for systems using Courier's ecosystem, where it handles folder hierarchies and message delivery without altering the local format. Among modern terminal-based options, aerc, released in 2020, features a dedicated Maildir backend for asynchronous reading and composing, supporting offline workflows with vim-like keybindings and built-in filtering. Key features in these clients include flag synchronization via the Maildir++ extension, which appends status indicators (e.g., 'S' for seen, 'R' for replied) to filenames in the 'cur' subdirectory, allowing MUAs like Mutt and to propagate changes across sessions without database overhead. Search integration is facilitated by tools like mairix, which indexes Maildir folders for rapid queries on subjects, senders, and bodies, and can output results to a dedicated Maildir subdirectory viewable directly in compatible MUAs such as NeoMutt.

Advantages and Comparisons

Key Benefits

The Maildir format ensures reliability through atomic operations, where each email message is stored as an individual file that is never modified after creation, preventing corruption during delivery or access even in multi-process environments. This design eliminates the need for file locking mechanisms common in traditional formats, avoiding single points of failure that could halt access during concurrent operations by multiple mail delivery agents or clients. As a result, the delivery process remains robust, with messages moved atomically between temporary, new, and cur subdirectories to maintain integrity without interrupting ongoing activities. Maildir facilitates straightforward backups using tools like , as the directory-based structure allows incremental synchronization of individual files without risking partial overwrites or requiring the entire mailbox to be locked during the process. This approach supports efficient, consistent copies of large mailboxes, preserving message states and enabling quick restores in case of failure. In terms of , Maildir handles high-volume inboxes effectively in concurrent setups, provided the underlying filesystem is optimized for many small files. It performs well in multi-user scenarios, distributing load across directories and leveraging filesystem capabilities for parallel access. Security is enhanced by per-file permissions, where each message inherits independent access controls, limiting exposure if one file is compromised and allowing fine-grained management in shared environments. The format's isolation of messages also provides resistance to viruses or , as an infection in a single file does not propagate to the entire mailbox, unlike formats with monolithic storage. Modern deployments benefit from Maildir's compatibility with , as seen in Docker-based mail servers like those using Dovecot, which enable portable, isolated storage since its introduction in 2013. Additionally, it integrates seamlessly with cloud syncing solutions such as , allowing directory-level synchronization of Maildir folders for distributed access and redundancy across devices.

Comparisons with Other Formats

Maildir differs from the format primarily in its storage approach, using a with individual files for each message rather than a single append-only file, which eliminates the need for global locking during delivery and reduces the risk of corruption from system crashes or concurrent writes. In contrast, mbox requires file-level locking for all operations, making it simpler to implement for small-scale, single-user setups but prone to issues in high-volume or multi-user environments where frequent appends can lead to performance bottlenecks and on interruption. Compared to the MH (Message Handler) format, Maildir shares a directory-based design with one file per message but introduces standardized filename conventions incorporating delivery timestamps, process IDs, and host information for uniqueness and atomicity in file operations, ensuring reliable delivery without race conditions. MH provides greater flexibility for custom scripting and folder management due to its simpler, non-standardized structure but lacks native support for IMAP flags like \Seen or \Answered, requiring extensions or external tools for such features. Both formats avoid mbox's single-file limitations, yet Maildir's design, originating from in the mid-1990s, has become the preferred choice in open-source ecosystems for its robustness over NFS and compatibility with modern mail systems like Postfix and Dovecot. Key trade-offs include Maildir's increased disk usage from per-file metadata and filesystem overhead, which can be higher than for folders with many small messages, though this gap narrows with larger attachments. Initial folder loads in Maildir may be slower without indexing, as clients must scan directories to build message lists, unlike optimized ; however, integrating Maildir with indexing tools like notmuch mitigates this by enabling rapid searches and tag-based organization. In the , migrations to Maildir gained traction in enterprise setups, such as Zimbra's enhanced support for importing and using Maildir structures to transition from legacy formats, highlighting its role in modernizing scalable storage.

References

  1. https://cr.yp.to/proto/maildir.html
  2. https://access.redhat.com/articles/6167512
  3. https://doc.dovecot.org/2.3/admin_manual/mailbox_formats/maildir/
  4. http://qmail.org/man/man5/maildir.html
  5. https://cr.yp.to/qmail.html
  6. https://cr.yp.to/qmail/qmailsec-20071101.pdf
  7. https://www.postfix.org/OVERVIEW.html
  8. https://www.courier-mta.org/maildir.html
  9. https://doc.dovecot.org/admin_manual/mailbox_formats/maildir/
  10. https://datatracker.ietf.org/doc/html/rfc6778
  11. https://www.postfix.org/SMTPUTF8_README.html
  12. https://www.courier-mta.org/imap/README.maildirquota.html
  13. https://datatracker.ietf.org/doc/html/rfc5322
  14. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_file_systems/getting-started-with-an-ext4-file-system_managing-file-systems
  15. https://manpages.ubuntu.com/manpages/focal/en/man5/maildir.courier.5.html
  16. https://www.postfix.org/local.8.html
  17. https://notmuchmail.org/
  18. https://www.djcbsoftware.nl/code/mu/
  19. https://cygwin.com/cygwin-ug-net/using.html
  20. https://dovecot.org/list/dovecot/2012-July/066939.html
  21. https://serverfault.com/questions/564456/what-are-the-practical-differences-between-maildir-and-mbox
  22. https://utcc.utoronto.ca/~cks/space/blog/sysadmin/MaildirNotGoodWithNFS
  23. https://github.com/djcb/mu
  24. http://www.courier-mta.org/imap/README.maildirquota.html
  25. https://doc.dovecot.org/main/core/plugins/quota.html
  26. http://www.courier-mta.org/maildir.html
  27. https://doc.dovecot.org/main/core/config/mailbox/formats/maildir.html
  28. https://www.postfix.org/postconf.5.html
  29. https://www.postfix.org/VIRTUAL_README.html
  30. https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_appendfile_transport.html
  31. https://wiki.debian.org/MaildirConfiguration
  32. https://www.courier-mta.org/maildrop/
  33. http://www.mutt.org/
  34. https://neomutt.org/about.html
  35. https://support.mozilla.org/en-US/kb/maildir-thunderbird
  36. https://help.gnome.org/users/evolution/stable/mail-account-manage-maildir-format-directories.html.en
  37. https://doc.dovecot.org/2.3/configuration_manual/mail_location/Maildir/
  38. https://www.courier-mta.org/imap/maildirs.html
  39. https://aerc-mail.org/
  40. https://github.com/rc0/mairix
  41. https://doc.dovecot.org/2.3/admin_manual/filesystem_permission/
  42. https://doc.dovecot.org/main/installation/docker.html
  43. https://help.nextcloud.com/t/is-it-possible-to-use-nextclouds-main-storage-on-the-host/40292
  44. https://docs.python.org/3/library/mailbox.html
  45. https://mailutils.org/manual//html_chapter/Mailbox.html
  46. http://www.courier-mta.org/mbox-vs-maildir/
  47. https://unix.stackexchange.com/questions/439903/mh-format-is-special-different-from-both-mbox-and-maildir
  48. https://wiki.zimbra.com/wiki/Mail_Migration
Add your contribution
Related Hubs
User Avatar
No comments yet.