Format maildir jest coraz popularniejszym sposobem przechowywania poczty użytkowników. Dzięki niekwestionowanym zaletom, coraz więcej aplikacji MTA i MUA go obsługuje. Poniższy artykuł ma na celu przybliżenie czytelnikowi tego popularnego formatu, a także opis niektórych programów, które go obsługują.

Skrzynka pocztowa w formacie maildir zbudowana jest z katalogów new, cur oraz tmp we wspólnym katalogu $HOME/Maildir (lub podobnym). Każda wiadomość dostarczana do użytkownika, zapisywana jest w postaci osobnego pliku, którego nazwę stanowią: data i czas dostarczenia wiadomości, nazwa hosta oraz PID programu, który dostarczał wiadomość. Poszczególne pola odseparowane są kropkami. Zamiast wartości PID, dopuszczalne są także inne unikalne zmienne, a ich zastosowanie zależy od konkretnej implementacji i używanej odmiany systemu operacyjnego. Dodatkowo, w nazwie pliku mogą się znajdować flagi, obsługiwane przez MUA:

	R -- użytkownik odpisał na wiadomość
	S -- wiadomość została przeczytana
	T -- wiadomość przeznaczona do usunięcia
	F -- wiadomość zaznaczona

Jeżeli którakolwiek z flag zostanie użyta, wymagane jest podanie informacji na temat ich formatu. W chwili obecnej możliwe są tylko dwie wartości: "1" oznaczające format eksperymentalny oraz "2" oznaczające jednobajtowe flagi posortowane rosnąco.

Wiadomości przechowywane w podkatalogu new nie zostały jeszcze przeczytane. Zostają one przeniesione do podkatalogu cur, gdy tylko program kliencki je odczyta. Podkatalog tmp jest używany przy każdym dostarczeniu; tworzona jest tam każda wiadomość przeznaczona dla danego użytkownika, dopiero później jest przenoszona do podkatalogu new. Taki schemat doręczania poczty pozwala na uniknięcie powstawania duplikatów, czy uszkodzeń plików przy zaniku zasilania lub błędzie systemu operacyjnego.

Oto przykład nazwy pliku zgodnej z formatem maildir:

Maildir/cur/1012584558.14041_0.lagoon.freebsd.lublin.pl:2,RS

Oznacza ona, że wiadomość została dostarczona 1012584558 sekund od "epoki" (czyli 1 lutego 2002 o godzinie 18:29:18) przez proces o identyfikatorze 14041 na hoście lagoon.freebsd.lublin.pl. Wiadomość ma ustawione dwie flagi w formacie jednobajtowym, rosnącym alfabetycznie. Oznaczają one, że została przeczytana i użytkownik wysłał odpowiedź.

Najważniejszą zaletą formatu maildir jest prostota. W przeciwieństwie do standardowego pliku w tradycyjnym formacie mailbox, przetwarzanie jest bardzo proste -- sporo informacji można uzyskać bez otwierania pliku, jedynie poprzez interpretowanie nazwy. Również odczytywanie nagłówka jest bardzo ułatwione ze względu na brak konieczności oddzielania od siebie poszczególnych wiadomości, "zlepionych" w jeden duży plik. Ale to jeszcze nie wszystkie zalety. Najważniejszym powodem zaprojektowania maildirów jest niezawodność. Wyobraźmy sobie sytuację, w której podczas operacji dopisywania wiadomości lub scalania przy kasowaniu system operacyjny zatrzyma się. Spowoduje to najprawdopodobniej takie uszkodzenie skrzynki, że nie będzie ona możliwa do odczytania przez żaden program kliencki i będzie wymagała ręcznej naprawy, najczęściej przez usunięcie niedokończonej wiadomości. Taka sytuacja nie może mieć miejsca, gdy wiadomości są zapisywane najpierw w podkatalogu tmp, a dopiero później są przenoszone do właściwego podkatalogu. W najgorszym wypadku uszkodzeniu ulegnie jeden plik, jednak w przypadku używania oprogramowania qmail, wiadomość zostanie bezboleśnie dostarczona z kolejki ponownie, gdy system będzie już sprawny, bez żadnych duplikatów!

Format maildir rozwiązuje również odwieczny problem z dostępem dzielonym do skrzynki i obsługą poczty przez system plików NFS. Jak wiadomo, tradycyjny plik mailbox nie może być jednocześnie zapisywany przez więcej niż jedną aplikację. W tym celu stosowane są blokady jednoczesnego dostępu, np. podczas scalania skrzynki, MTA nie może dopisać żadnej nowej wiadomości, gdyż spowodowałoby to drastyczne uszkodzenie zawartości. Sprawa jeszcze bardziej się komplikuje przy zastosowaniu sieciowych systemów plików, gdzie blokady są realizowane przez oddzielną aplikację rpc.lockd, często niezgodną z innymi wariantami systemu, a czasami w ogóle nie uruchomioną. Skutki takiego zaniedbania ujawniają się bardzo szybko... W przypadku formatu maildir stosowanie jakichkolwiek blokad jest niepotrzebne. Nie może zaistnieć sytuacja, gdy dwie aplikacje zapisują do tego samego pliku, gdyż nazwa jest unikalna, a wiadomości przechowywane pojedynczo.

Dodatkową zaletą jest wydajność całego rozwiązania. Odpada konieczność scalania całej skrzynki przy usunięciu jednej wiadomości, a odczytywanie katalogu jest zwykle szybsze niż przetwarzanie wielkiego pliku. Najczęściej zużycie pamięci jest także wyraźnie mniejsze. Wiele MUA podczas przetwarzania tradycyjnej skrzynki, alokuje tyle pamięci, ile ma plik, co czasami powoduje nadmierne użycie pamięci wirtualnej. W przypadku formatu maildir, zużycie pamięci najczęściej nie jest większe niż suma wielkości niektórych pól nagłówków we wszystkich wiadomościach. Dodatkowo, niektóre systemy są zoptymalizowane pod kątem odczytywania katalogów zawierających dużą ilość plików. Przykładem może być FreeBSD z opcją UFS_DIRHASH oraz OpenBSD/NetBSD z kodem dirpref.

Po przytoczeniu wszystkich zalet, trzeba też wspomnieć o wadach. Należy do nich nadmierne użycie i-węzłów, a także spowolnienie pracy na niektórych systemach plików z księgowaniem (manual do ReiserFS ostrzega o tym). Starsze systemy plików (EXT2FS, UFS, FFS) dość kiepsko radzą sobie z dużymi katalogami; związane jest to z liniowym algorytmem wyszukiwania pliku w katalogu. Sytację zmienia dopiero kod dirhash/dirpref w nowych wersjach *BSD. Największą wadą pozostaje ciągle niekompatybilność z niektórymi rodzajami aplikacji, szczególnie tymi napisanymi dawniej. W takich sytuacjach pozostaje używanie wrapperów mbox2maildir i maildir2mbox, uruchamianymi przed niedostosowaną aplikacją, jednakże takie rozwiązanie jest bardzo mało wydajne i stanowczo go nie polecam, lepiej poszukać łaty na aplikację lub zmienić ją na inną.

W chwili obecnej prawie wszystkie ważniejsze MTA obsługują poprawnie format maildir. Należą do nich: qmail, postfix oraz exim, a w przypadku zmailera istnieją stosowne łaty. Również bardzo popularny LDA -- procmail od dość niedawna poprawnie wspiera maildiry, podobnie jak jego młodszy odpowiednik, maildrop. Wśród natywnie kompatybilnych serwerów POP3, można wymienić polskiego solidpop3 oraz qmail-pop3d, natomiast w przypadku demonów IMAP są to Cyrus IMAP (natywnie) oraz UW IMAP (łata). Autorowi jest znany tylko jeden pakiet poczty przez WWW, bezpośrednio obsługujący maildiry -- sqwebmail; pozostałe łączą się lokalnie przez POP3 lub IMAP. Kompatybilność MUA niestety pozostawia wiele do życzenia. Z najpopularniejszych aplikacji działa poprawnie jedynie mutt oraz gnus. Pozostałe, bardzo często używane w Polsce -- elm oraz pine wymagają odpowienich łat lub stosowania opisanych wcześniej wrapperów.

Na tym można zakończyć już ogólną charakterystykę formatu maildir. Szczegółowe informacje dotyczące konfiguracji konkretnego MTA czy LDA znaleźć można w innych artykułach z wydań LinuxPlus dotyczących poczty elektronicznej. Zachęcam również do odwiedzenia następujących stron WWW:

	http://www.task.gda.pl/qmail/top.html#maildir -- Współpraca qmaila z Maildirami
	http://cr.yp.to/qmail.html -- Oficjalna strona qmail'a
	http://www.exim.org -- Oficjalna strona Exim'a
	http://www.zmailer.org -- Oficjalna strona Zmailer'a
	http://www.postfix.org -- Oficjalna strona Postfix'a
	http://solidpop3d.pld.org.pl -- Oficjalna strona SolidPOP3
	http://inter7.com/sqwebmail -- Oficjalna strona sqwebmail

Wszystkie materiały na mojej stronie dostępne są na licencji Creative Commons Uznanie autorstwa-Użycie niekomercyjne-Na tych samych warunkach 2.5 Polska.