- # 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.
- X n, 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.
- R n, 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.
- I n, where n is (in hexadecimal) the UNIX inode number of this file. Unfortunately, inode numbers aren't always available through NFS.
- V n, 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.)
- M n, where n is (in decimal) the microsecond counter from the same gettimeofday() used for the left part of the unique name.
- P n, where n is (in decimal) the process ID.
- Q n, where n is (in decimal) the number of deliveries made by this process.
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. 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". This moving needs to be done using rename(), as the non-atomic link then unlink technique 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 which show whether the message has been read, deleted and so on: the initial (capital) letter of Passed, Replied, Seen, Trashed, Draft, and Flagged. Dovecot uses lowercase letters to match 26 IMAP keywords, which may include standardised keywords, such as $MDNSent, and user defined flags.
Systems that don't allow colons in filenames (This includes Microsoft Windows and some configurations of Novell Storage Services.) can use an alternative separator, such as ";", or "-". It is often trivial to patch free and open source software to use a different separator.
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 email client needs to read or modify message flags, and only one is used, then non-standard alternative separators may be used without interoperability problems.