Дворцы и дома культуры
- 1 year ago
- 0
- 0
Maildir — распространённый формат хранения электронной почты , не требующий монопольного захвата файла для обеспечения целостности почтового ящика при чтении, добавлении или изменении сообщений. Каждое сообщение хранится в отдельном файле с уникальным именем, а каждая папка представляет собой каталог . Вопросами блокировки файлов при добавлении, перемещении и удалении файлов занимается локальная файловая система . Все изменения делаются при помощи атомарных файловых операций, таким образом, монопольный захват файла ни в каком случае не нужен.
Каталог
Maildir (имя которого часто тоже
Maildir
), обычно имеет три подкаталога:
tmp
,
new
и
cur
.
Оригинальная спецификация формата Maildir была написана qmail , djbdns , и других программ . Хотя исходная спецификация и писалась автором специально для своей программы qmail , она носит довольно общий характер, так что может быть реализована во многих программах.
( ), авторомСэм Варшавчик (Sam Varshavchik), автор Courier Mail Server и других программ, написал расширение формата 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
. В
Dovecot
используются буквы нижнего регистра (строчные) для обеспечения соответствия 26 ключевым словам IMAP
, куда могут входить как стандартные ключевые слова, такие как $
, так и флаги, определённые пользователем.
проектировал 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 .
В программах, работающих на таких системах, может использоваться альтернативный разделитель (такой как «;» или «-»), и часто для его использования достаточно исправить программу, наложив простую заплату , поскольку речь идёт о свободном и открытом программном обеспечении .
Так как в настоящее время нет соглашений о том, какой символ использовать для альтернативного разделителя, то на таких системах могут быть проблемы взаимодействия между различными программами, поддерживающими Maildir. Но не всем работающим с Maildir программам нужно знать, какой разделитель используется, так как не всем программам нужно иметь возможность читать или модифицировать флаги сообщений («read», «replied to» и т. д.). У программ, предназначенных только для доставки почты в Maildir, или программ архивации старых сообщений оттуда только на основе их даты не должно быть проблем с работой вне зависимости от используемого разделителя. В случае, если читать и изменять флаги сообщений нужно только почтовому клиенту , и если используется только один такой клиент, то никаких проблем взаимодействия при использовании нестандартного разделителя не будет.
Количество программ, которые могут использоваться вместе с Maildir, на самом деле гораздо больше, если учитывать взаимодействие этих программ друг с другом и роль протоколов сетевого доступа.
Например:
mail.local
. Вместо
mail.local
могут использоваться Procmail (и другие программы, поддерживающие Maildir), поэтому справедливо будет сказать, что Sendmail поддерживает Maildir в той же мере как и любой другой формат.