Maildir

Maildir

Тип	Архив электронных писем
Разработчик	Daniel J. Bernstein

Maildir — это распространённый формат хранения электронной почты, не требующий монопольного захвата файла для обеспечения целостности почтового ящика при чтении, добавлении или изменении сообщений. Каждое сообщение хранится в отдельном файле с уникальным именем, а каждая папка представляет собой каталог. Вопросами блокировки файлов при добавлении, перемещении и удалении файлов занимается локальная файловая система. Все изменения делаются при помощи атомарных файловых операций, таким образом, монопольный захват файла ни в каком случае не нужен.

Внутренняя структура формата Maildir

Спецификации

Каталог Maildir (имя которого часто тоже Maildir), обычно имеет три подкаталога: tmp, new и cur.

Maildir

Оригинальная спецификация формата Maildir была написана Дэниэлом Бернштайном (Daniel J. Bernstein), автором qmail, djbdns, и других программ^[1]. Хотя исходная спецификация и писалась автором специально для своей программы qmail, она носит довольно общий характер, так что может быть реализована во многих программах.

Maildir++

Сэм Варшавчик (Sam Varshavchik), автор Courier Mail Server и других программ, написал расширение ^[2] формата Maildir под названием Maildir++ для поддержки вложенных папок и квот на почту. В каталогах Maildir++ находятся подкаталоги с названиями, начинающимися с точки («.»), которые также являются папками Maildir++. Это расширение в этой связи является нарушением спецификации Maildir, в которой приводится исчерпывающий список возможного содержимого Maildir, но это совместимое отклонение и другое программное обеспечение, поддерживающее Maildir, поддерживает и Maildir++.

Технические операции

При доставке сообщения оно помещается в файл в подкаталоге tmp (например, SMTP-сервером postfix). Имя файла формируется из текущего времени, имени хоста, идентификатора процесса, создавшего этот файл, и некоторого случайного числа — таким образом гарантируется уникальность имен файлов.

После записи в файл всего сообщения обычно создается жесткая ссылка на этот файл в каталоге new, а текущая ссылка из tmp удаляется, но в некоторых реализациях просто используется системный вызов rename(), — всё это делается для того, чтобы никакой другой процесс не смог прочитать содержимое сообщения до тех пор, пока оно не будет записано полностью, так как MUA никогда не смотрят в tmp.

Когда почтовый клиент находит сообщения в каталоге new, он перемещает их в cur (с помощью rename(), так как использование жёстких ссылок в данном случае может привести к дублированию сообщений) и перед чтением файлов добавляет к их именам информационные суффиксы. Информационный суффикс состоит из двоеточия (для разделения уникальной части имени файла и текущей информации), числа '2', запятой и различных флагов. Число '2' указывает, грубо говоря, версию информации после запятой. '2' — это единственно официально определённая в настоящее время версия. '1' относится к экспериментальной версии. Можно лишь предположить, что этот номер версии использовался в процессе разработки формата Maildir. Спецификация определяет флаги, которые показывают, было ли сообщение прочитано, удалено и так далее, для них используются первые (заглавные) буквы следующих слов: Passed, Replied, Seen, Trashed, Draft и Flagged^[1]. В Dovecot используются буквы нижнего регистра (строчные) для обеспечения соответствия 26 ключевым словам IMAP^[3], куда могут входить как стандартные ключевые слова, такие как $MDNSent, так и флаги, определённые пользователем.

Технические проблемы

Некорректное состояние при работе без блокировок

Daniel J. Bernstein проектировал Maildir так, чтобы несколько процессов могли безопасно производить запись параллельно, без какой бы то ни было явной блокировки и даже при использовании NFS. На практике это работает довольно хорошо, но может приводить к странностям. В процессе чтения структуры каталога любые файлы, которые будут переименованы между первым и последним системными вызовами readdir(), могут не появиться в списке файлов. Это заставляет читающий процесс поверить, что сообщение было удалено, в то время как на самом деле изменились только его флаги. Когда процесс считывает список сообщений снова, вдруг вновь появляется «удалённое» сообщение. Для устранения подобного рода проблем некоторые программы доступа к почте вводят свои собственные блокировки поверх Maildir. В Dovecot, например, вместе с Maildir используется собственная нестандартная система блокировок.

Блокировки и масштабирование

Существуют неявные блокировки, используемые файловой системой при обновлении каталогов. Некластерные файловые системы обычно позволяют только одному потоку выполнения ядра в любой момент времени обновлять данные о том, что находится в каталоге, поэтому системный вызов rename() обеспечит необходимую блокировку. Maildir не является системой без блокировок (lock-free), только без явных блокировок (explicit-lock-free). Для многих почтовых систем размером от маленьких до средних это адекватно масштабируется даже на NFS, на когда система становится большой и обрабатывает множество параллельных доставок, постоянное изменение содержимого многих каталогов одновременно будет постоянно приводить к недействительности данных кеша (cache invalidation) разных NFS-клиентов, поэтому нужно будет повторно производить удалённые вызовы процедур (RPC) READDIR, что плохо масштабируется. Кроме того, многие файловые системы имеют ограничения по числу файлов на каталог.

Maildir страдает, таким образом, от унаследованных ограничений масштабирования всех систем хранения писем, построенных по принципу «одно письмо - один файл».

Совместимость с файловыми системами

Стандарт Maildir нельзя реализовать без модификации на системах, не поддерживающих двоеточия в именах файлов. Сюда входят Microsoft Windows и некоторые конфигурации Novell Storage Services.

В программах, работающих на таких системах, может использоваться альтернативный разделитель (такой как «;» или «-»), и часто для его использования достаточно исправить программу, наложив простую заплату^[4], поскольку речь идёт о свободном и открытом программном обеспечении.

Так как в настоящее время нет соглашений о том, какой символ использовать для альтернативного разделителя, то на таких системах могут быть проблемы взаимодействия между различными программами, поддерживающими Maildir. Но не всем работающим с Maildir программам нужно знать, какой разделитель используется, так как не всем программам нужно иметь возможность читать или модифицировать флаги сообщений ("read", "replied to" и т. д.). У программ, предназначенных только для доставки почты в Maildir, или программ архивации старых сообщений оттуда только на основе их даты не должно быть проблем с работой вне зависимости от используемого разделителя. В случае, если читать и изменять флаги сообщений нужно только почтовому клиенту, и если используется только один такой клиент, то никаких проблем взаимодействия при использовании нестандартного разделителя не будет.

Программное обеспечение, непосредственно поддерживающее Maildir

Почтовые серверы

• IMAP-сервер bincimap
• IMAP-сервер Dovecot
• SMTP- и IMAP-сервер Courier Mail Server, для которого был изобретён формат Maildir++
• SMTP-сервер Exim
• SMTP-сервер Postfix
• SMTP-сервер Qmail, для которого был изобретён формат Maildir
• Открытый кросс-платформенный (для *nix и Windows) SMTP- и POP3-сервер XMail
• SMTP-сервер MeTA1
• Почтовый сервер MagicMail

Агенты доставки

• Procmail
• Maildrop
• Getmail, агент получения и доставки почты с поддержкой Maildir, являющийся альтернативой программе Fetchmail
• mbsync
• OfflineIMAP
• mswatch
• mpop

Программы чтения почты

• Balsa, программа, прежде бывшая официальным пользовательским почтовым агентом GNOME (до Evolution)
• Cone, почтовая программа с curses-интерфейсом
• Gnus
• mailx
• GNUMail
• KMail, программа чтения почты KDE
• Mutt
• Evolution, официальный почтовый клиент GNOME
• Wanderlust

Утилиты индексирования и поиска в почте

• Beagle, может индексировать Maildir и многие другие форматы хранения информации
• Mairix, программа для индексирования и поиска сообщений электронной почты, сохранённых в формате Maildir, MH или mbox
• Mboxgrep, программа, которая может производить поиск в папках Maildir. Это подобно использованию grep.
• notmuch, программа для индексирования и поиска почтовых сообщений, сохранённых в Maildir
• mu, набор командострочных утилит для поисха в каталогах Maildir

Программное обеспечение, косвенно поддерживающее Maildir

Количество программ, которые могут использоваться вместе с Maildir, на самом деле гораздо больше, если учитывать взаимодействие этих программ друг с другом и роль протоколов сетевого доступа.

Например:

• Sendmail MTA не поддерживает никакого формата доставки почты (хотя многие думают, что поддерживает). Sendmail использует отдельный процесс доставки под названием mail.local. Вместо mail.local могут использоваться Procmail (и другие программы, поддерживающие Maildir), поэтому справедливо будет сказать, что Sendmail поддерживает Maildir в той же мере как и любой другой формат.
• Многие программы чтения почты не поддерживают Maildir, но поддерживают форматы удалённого доступа, такие как IMAP. Так как существуют разные хранилища почты IMAP, поддерживающие Maildir, то любая почтовая программа, поддерживающая IMAP, такая как Microsoft Outlook, Pine или Mozilla Thunderbird, может использоваться для доступа к папкам Maildir.
• Программа Fetchmail не поддерживает Maildir (или любой формат локальной доставки), но так как она разговаривает с SMTP-сервером или локальным агентом доставки, то любая из вышеупомянутых программ может использоваться для доставки почты от Fetchmail в Maildir.

Примечания

1. ↑ ^{1 2} Daniel J. Bernstein. (1995) Using maildir format (the original specification)
2. ↑ Varshavchik, Sam (1998) Maildir++ и квоты Maildir, где скрыта спецификация Maildir++
3. ↑ Dovecot Wiki: maildir format
4. ↑ mutt maildir support: workaround for filesystems that don't accept colons