Maildir поширений формат зберігання електронної пошти що не вимагає монопольного захоплення файлу для забезпечення ціліс

Maildir - поширений формат зберігання електронної пошти, що не вимагає монопольного захоплення файлу для забезпечення цілісності поштової скриньки при читанні, додаванні або зміні повідомлень. Кожне повідомлення зберігається в окремому файл з унікальним ім'ям, а кожна папка являє собою каталог. Питаннями при додаванні, переміщенні і видаленні файлів займається локальна файлова система. Всі зміни робляться за допомогою атомарних файлових операцій, таким чином, монопольне захоплення файлу в жодному з випадків не є потрібним.

Maildir
Тип	архів електронних листів
Розробник	Daniel J. Bernstein

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

Каталог Maildir (ім'я якого часто також Maildir), зазвичай, має три підкаталоги: tmp, new і cur.

Maildir

Оригінальна специфікація формату Maildir була написана Даніелем Бернштайном, автором , , та інших програм. Хоча вихідна специфікація і писалася автором спеціально для своєї програми qmail, вона носить досить загальний характер, тому може бути реалізована в багатьох програмах.

Maildir++

Сем Варшавчик( Sam Varshavchik), автор та інших програм, написав розширення формату 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, куди можуть входити як стандартні ключові слова, такі як $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 і деякі конфігурації .

У програмах, що працюють на таких системах, може використовуватися альтернативний роздільник (такий як ";" або "-"), і часто для його використання досить виправити програму, наклавши просту латку, оскільки мова йде про вільне і відкрите програмне забезпечення.

Оскільки в даний час немає угод про те, який символ використовувати для альтернативного роздільника, то на таких системах можуть бути проблеми взаємодії між різними програмами, що підтримують Maildir. Але не всім працюючим з Maildir програмам потрібно знати, який роздільник використовується, оскільки не всім програмам потрібно мати можливість читати або модифікувати прапорці повідомлень («read", "replied to" і т. д.). У програм, призначених лише для доставки пошти в Maildir, або програм архівації старих повідомлень звідти, тільки на основі їх дати, не повинно бути проблем з роботою незалежно від використовуваного роздільника. У разі, якщо читати і змінювати прапорці повідомлень потрібно тільки поштовому клієнту, і якщо використовується тільки один такий клієнт, то ніяких проблем взаємодії при використанні нестандартного роздільника не буде.

Програмне забезпечення, що безпосередньо підтримує Maildir

Поштові сервери

IMAP-сервер bincimap
IMAP-сервер Dovecot
SMTP-і IMAP-сервер , для якого був винайдений формат Maildir++
SMTP-сервер Exim
SMTP-сервер Postfix
SMTP-сервер , для якого був винайдений формат Maildir
Відкритий крос-платформний (для *nix і Windows) SMTP-і POP3-сервер XMail
SMTP-сервер MeTA1
Поштовий сервер MagicMail
Поштовий сервер
Поштовий сервер Office Mail Server

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

Maildrop
Getmail - агент отримання та доставки пошти з підтримкою Maildir, що є альтернативою програмі
mbsync
OfflineIMAP
mswatch
mpop

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

Balsa - програма, яка раніше була офіційним користувацьким поштовим агентом GNOME (до Evolution)
Cone - поштова програма з Curses-інтерфейсом
mailx
GNUMail
KMail - програма читання пошти KDE
Evolution - офіційний поштовий клієнт GNOME

Утиліти індексування і пошуку в пошті

Beagle - може індексувати Maildir і багато інших форматів зберігання інформації
Mairix - програма для індексування та пошуку повідомлень електронної пошти, збережених у форматі Maildir, MH або mbox
Mboxgrep [ 13 липня 2012 у Wayback Machine.] - програма, яка може здійснювати пошук в папках Maildir. Це подібно до використання grep.
notmuch - програма для індексування та пошуку поштових повідомлень, збережених в Maildir
mu [ 24 жовтня 2012 у Wayback Machine.] - набір утиліт командного рядка для пошуку в каталогах Maildir

Програмне забезпечення, що опосередковано підтримує Maildir

Кількість програм, які можуть використовуватися разом з Maildir, насправді є набагато більшою, якщо враховувати взаємодію цих програм одна з одною і роль протоколів мережевого доступу.

Наприклад:

Sendmail MTA не підтримує жодного формату доставки пошти (хоча багато хто думає, що підтримує). Sendmail використовує окремий процес доставки під назвою mail.local. Замість mail.local можуть використовуватися Procmail (та інші програми, що підтримують Maildir), тому справедливо буде сказати, що Sendmail підтримує Maildir в тій же мірі як і будь-який інший формат.
Багато програм читання пошти не підтримують Maildir, але підтримують формати віддаленого доступу, такі як IMAP. Оскільки існують різні сховища пошти IMAP, що підтримують Maildir, то будь-яка поштова програма, що підтримує IMAP, така як Microsoft Outlook, або Mozilla Thunderbird, може використовуватися для доступу до папок Maildir.
Програма не підтримує Maildir (або будь-який формат локальної доставки), але оскільки вона розмовляє з SMTP-сервером або локальним агентом доставки, то будь-яка з вищезазначених програм може використовуватися для доставки пошти від Fetchmail в Maildir.

Див. також

Примітки

Daniel J. Bernstein. (1995) Using maildir format (the original specification) [ 2 вересня 2000 у Wayback Machine.]
Varshavchik, Sam (1998) Maildir++ и квоты Maildir [ 13 липня 2012 у Wayback Machine.], где скрыта спецификация Maildir++
. Архів оригіналу за 9 жовтня 2012. Процитовано 28 січня 2022.
. Архів оригіналу за 29 січня 2022. Процитовано 28 січня 2022.

[djbspec-1] Daniel J. Bernstein. (1995) Using maildir format (the original specification) [ 2 вересня 2000 у Wayback Machine.]

[plusplus-2] Varshavchik, Sam (1998) Maildir++ и квоты Maildir [ 13 липня 2012 у Wayback Machine.], где скрыта спецификация Maildir++

[dovecot-3] . Архів оригіналу за 9 жовтня 2012. Процитовано 28 січня 2022.

[4] . Архів оригіналу за 29 січня 2022. Процитовано 28 січня 2022.