Maildir

この用語をシェア

Maildirとは

Maildirは、1通のメールを1つのファイルとして保存するメールボックス格納形式です。1995年前後にqmailの作者であるDaniel J. Bernsteinが、従来のmbox形式が抱えていたロック競合・ファイル破損のリスクを解消する目的で設計しました。現在ではqmailに限らず、DovecotやPostfix、Courier-IMAP、Eximなど主要なメールサーバーソフトウェアで標準的にサポートされており、事実上の業界標準フォーマットの一つになっています。

Maildirのもっとも重要な設計思想は、「ファイルシステムの原子的操作（rename）だけでメールの受信・既読管理・削除を安全に行う」という点です。データベースやロックファイルのような追加の仕組みを使わず、複数のプロセス（メール配送エージェントとIMAPサーバーなど）が同じメールボックスに同時にアクセスしても矛盾が起きない構造になっています。この単純さと堅牢性が、Maildirが長期にわたり支持され続けている最大の理由です。

用語としての「Maildir」は、(1) このディレクトリ構造そのものを指す場合と、(2) 個々のユーザーのメールボックスディレクトリ（例: ~/Maildir/）を指す場合の両方で使われます。文脈によって意味を読み分ける必要がありますが、いずれも「1メール1ファイル」という基本原則は共通です。

Maildirの仕組み・詳細解説

ディレクトリ構成

~/Maildir/
├── cur/      # 読み込み済みメール
├── new/      # 未読メール
├── tmp/      # 一時ファイル
└── .Sent/    # サブフォルダ（ドット始まり）
    ├── cur/
    ├── new/
    └── tmp/

ファイル名形式

Maildirのファイル名は「一意性」を保証するために複数の要素を組み合わせて生成されます。同一秒に複数の配送が発生してもファイル名が衝突しないよう設計されている点が重要です。

# 典型的なMaildirファイル名
1673702400.M123456P789.mail.example.com,S=12345,W=12400:2,S

# 構成要素
1673702400        # Unix timestamp（配送開始時刻）
M123456           # マイクロ秒（同一秒内の衝突回避）
P789              # プロセスID（配送プロセスの識別）
mail.example.com  # ホスト名（複数サーバー環境での衝突回避）
S=12345           # サイズ（バイト数、Dovecotの拡張）
2,S               # フラグ情報（2=フォーマットバージョン、S=Seen/既読）

タイムスタンプ・マイクロ秒・プロセスID・ホスト名の4要素を組み合わせることで、同一マシン上の複数プロセスからの同時配送や、NFS共有された複数サーバーからの配送でもファイル名の衝突がほぼ発生しない設計になっています。Dovecotなどの実装ではS=（サイズ）やW=（改行コード変換後のサイズ）といった独自拡張情報を付与し、IMAPのFETCH応答を高速化するためのキャッシュとして活用しています。

ロックフリー設計の仕組み（tmp→newのアトミックrename）

Maildirがファイルロックを必要としない理由は、POSIXファイルシステムのrename(2)システムコールが同一ファイルシステム内でアトミック（不可分）であることを利用しているためです。メール配送エージェント（MDA）は次の手順でメールを書き込みます。

# Maildir配送の基本フロー
1. tmp/ に一意なファイル名で新規メールを書き込む（fsyncで確実にディスクへ反映）
2. 書き込みが完了したら rename() で new/ に移動する
3. rename は原子的操作のため、途中経過（書きかけの不完全なファイル）が
   new/ に見えることは絶対にない

この方式により、IMAPサーバーがnew/ディレクトリを読み取っているまさにそのタイミングで別プロセスがメールを配送しても、不完全なファイルを読んでしまう心配がありません。実務上の注意点として、rename()のアトミック性は同一ファイルシステム内でのみ保証される点が挙げられます。tmp/とnew/を別のマウントポイント（別ディスク・別NFSエクスポート）に分離するとこの前提が崩れるため、Maildirの3ディレクトリは必ず同一ファイルシステム上に置く必要があります。また、古い実装のNFSクライアントではrenameのセマンティクスが厳密でないケースが報告されており、NFS上でMaildirを運用する場合はNFSv4以降を推奨し、可能であればロック機構（mail_nfs_storage設定など、Dovecotのドキュメント参照）の併用を検討します。

メールの状態管理（フラグとcur/への遷移）

ユーザーがメールを閲覧すると、IMAP/POP3サーバーはそのファイルをnew/からcur/へrename()し、ファイル名の末尾に状態フラグを追記します。フラグはアルファベット順に並べるのが慣例です。

# cur/ に移動した後のファイル名（末尾がフラグ情報）
1673702400.M123456P789.mail.example.com:2,S

# 主なフラグの意味
D  # Draft（下書き）
F  # Flagged（フラグ付き・重要マーク）
P  # Passed（転送済み）
R  # Replied（返信済み）
S  # Seen（既読）
T  # Trashed（削除マーク、実削除ではない）

この仕組みにより、既読・未読・フラグといったメール状態はファイル名のみで完結して管理され、別途データベースを持つ必要がありません。ファイル名を変更するだけなので処理は極めて高速ですが、裏を返せば「ファイル名の変更＝メタデータの変更」であるため、Maildirを直接cpコマンドなどでコピーする際にファイル名を保持しないと既読状態が失われる点には注意が必要です。バックアップ・移行時はrsync -aやdoveadm backupのように属性とファイル名を保持するツールを使うのが定石です。

具体例・ユースケース

Maildirがどのような場面で真価を発揮するのか、実務でよく遭遇する具体的なユースケースを挙げます。

マルチデバイス・マルチクライアントでの同時アクセス

スマートフォンのメールアプリ、PCのメールクライアント、Webメール（Roundcube等）が同じメールボックスに同時接続する構成は珍しくありません。Maildirであれば、それぞれのクライアントが独立してメールファイルを読み書きしても、ファイルロックの奪い合いによる待機やタイムアウトが発生しません。mboxで同じ構成を組むと、複数クライアントが同時に書き込もうとした際にロック待ちが発生し、メールクライアント側でタイムアウトエラーが出ることがあります。

ファイル単位バックアップと差分同期

Maildirは1メール1ファイルであるため、rsyncによる差分バックアップや、Borgbackup・resticのような重複排除バックアップツールと非常に相性が良い形式です。

# 差分バックアップの例（変更・追加されたメールファイルのみ転送）
rsync -avz --delete /home/user/Maildir/ backup-server:/backup/user/Maildir/

# 特定ユーザーの総メール数を確認
find /home/user/Maildir/new /home/user/Maildir/cur -type f | wc -l

mboxのように1つの巨大ファイルを毎回まるごと転送する必要がないため、メールボックスが数GB規模になっても差分バックアップの転送量・時間を大幅に抑えられます。

メールボックスの移行（imapsync / doveadm backup）

オンプレミスのメールサーバー間の移行や、他社ホスティングからの引っ越しでは、doveadm backupやimapsyncといったツールがMaildir形式を中間フォーマットとして扱うことが一般的です。Gmailなど外部サービスからIMAP経由でメールを取り込み、Maildirとしてローカルに保存してから新サーバーへ投入する、といった手順が実務でよく使われます。

インシデント調査・監査でのファイル単位検索

特定期間に受信した不審メールを調査する際、Maildirであればfindやgrepでファイルシステムを直接検索できます。ファイル名にUnixタイムスタンプが含まれているため、特定時刻範囲のメールを機械的に絞り込むといった調査も比較的容易です。mboxでは同様の調査に1ファイル全体のパースが必要になり、ファイルが巨大な場合は処理時間がかさみます。

メリットとデメリット（注意点）

メリット

• 堅牢性: 1メールが破損しても他のメールに影響しない（mboxは1ファイル破損で全メール喪失のリスク）
• 並行アクセス耐性: ファイルロックが不要なため、複数プロセス・複数クライアントからの同時アクセスに強い
• 削除・移動の高速性: ファイル削除・rename操作のみで完結し、大きなファイルを書き換える必要がない
• NFS等のネットワークファイルシステムとの親和性: rename主体の設計のため、NFS上でも比較的安全に運用しやすい
• バックアップ・移行のしやすさ: ファイル単位のため、差分バックアップ・重複排除ツールとの相性が良い
• 直接的な検索・調査のしやすさ: findやgrepでファイルシステムレベルの調査が可能

デメリット・注意点

• ファイル数の増加によるinode枯渇: メール数が多いユーザー（数十万通規模）ではファイルシステムのinode数上限に注意が必要。mkfs時のinode比率設定や、定期的なdf -iによるinode使用率監視が実務上の定石
• 大量ファイル時の走査コスト: 1ディレクトリに数万〜数十万ファイルが集中すると、lsやバックアップツールでのディレクトリ列挙、ウイルススキャンが遅くなる場合がある（Maildir++のハッシュ化サブディレクトリやDovecotのmdbox移行で緩和可能）
• ディスク使用効率の低下: 小さなメールでもファイルシステムのブロックサイズ単位で確保されるため、mboxに比べてディスク使用効率がやや劣る場合がある
• NFS環境での前提条件: 前述の通り、tmp/new/cur間のrenameアトミック性が壊れる構成（別マウント分割など）を避ける必要がある
• ファイル名変更を伴うことへの認識不足: 既読/未読等の状態変更がファイル名変更として実装されているため、単純なcpやアプリケーションによってはこの挙動を考慮しないと状態が失われることがある

mboxとの比較

項目	Maildir	mbox
格納方式	1メール＝1ファイル	全メール＝1ファイル
並行アクセス	✅ 強い	弱い（ロック必要）
破損リスク	✅ 低い	高い（全体破損の恐れ）
削除効率	✅ 高速	遅い（再書き込み必要）
バックアップ	柔軟（差分・増分に強い）	✅ 簡単（1ファイル丸ごとコピー）
ディスク使用効率	小メール多数だとやや非効率	✅ 高い（連結保存）
個別メール検索	✅ find/grepで直接可能	ファイル全体のパースが必要
主な採用実装	Dovecot、qmail、Courier-IMAP	古いUNIX系MTA、一部のPOP3実装

なお、Dovecotは第三の選択肢としてmdbox（複数メールを適度な単位でまとめたファイルに保存し、Maildirの同時アクセス耐性も維持するハイブリッド形式）を提供しています。数万通規模のメールボックスを大量に扱う大規模ホスティング事業者では、ファイル数を抑えられるmdboxへの移行が進むケースもありますが、中小規模の自社メールサーバー運用ではMaildirのシンプルさと実績の豊富さが依然として優位です。

自社メールサーバー運用への応用

Postfix + Dovecot設定

Postfix + Dovecotの組み合わせで自社メールサーバーを構築する場合、双方でMaildir形式を明示的に指定する必要があります。設定を揃えないと配送形式と読み取り形式が食い違い、メールが見えなくなるトラブルの典型例になるため注意してください。

# Postfix main.cf
home_mailbox = Maildir/
mailbox_command =

# Dovecot 10-mail.conf（または conf.d/10-mail.conf）
mail_location = maildir:~/Maildir

# Dovecotでクォータを併用する場合（plugin設定）
mail_plugins = $mail_plugins quota
plugin {
  quota = maildir:User quota
  quota_rule = *:storage=1G
}

Postfix側のhome_mailbox = Maildir/は「ユーザーのホームディレクトリ配下にMaildirディレクトリを作る」という指定です。仮想ドメイン・仮想ユーザー構成（virtual-domain方式）でPostfixを運用する場合は、virtual_mailbox_baseやvirtual_mailbox_maildir_extended系のパラメータで保存先パスを個別に制御します。

Maildir++ (拡張版)

Dovecotが採用するMaildir++は、オリジナルのMaildir仕様に以下の機能を追加した拡張版です。

• クォータ管理: maildirsizeファイルによるメールボックスサイズ・通数の制限
• サブフォルダ: .フォルダ名形式のディレクトリでIMAPフォルダ階層を表現（例: .Sent、.Sent.2026で入れ子構造）
• 共有フォルダ: ACL（アクセス制御リスト）と組み合わせた複数ユーザー間のフォルダ共有

運用・セキュリティ上の注意点

• パーミッション設計: Maildirディレクトリは700（所有者のみ読み書き実行可）を基本とし、DovecotやPostfixの実行ユーザー（例: vmailユーザー）が正しく所有権を持つように統一する。所有者が食い違うと配送エラーやIMAPログイン後にメールが見えない不具合につながる
• inode枯渇対策: ファイルシステム作成時にmkfs.ext4 -Nや-iオプションでinode数を余裕を持って確保する。運用中はdf -iで定期的にinode使用率を監視する
• 大量ファイル対策としてのハッシュ化: Dovecotのmailbox_list_indexやMaildir++のクォータ機能を有効にし、可能であればメールボックスサイズが極端に大きいユーザーはmdbox形式への移行を検討する
• バックアップの整合性: tarやcpでMaildirをコピーする際は、稼働中のメールサーバーに対して行うと配送中のtmp/ファイルを不完全な状態で拾う可能性がある。doveadm backupや、配送を一時停止した状態でのバックアップが安全
• ウイルス・スパムスキャンとの連携: SpamAssassinやrspamdと連携する場合、Sieveフィルタ（Sieve）で判定結果に応じたサブフォルダ振り分けを行うのが一般的な構成

関連ブログ記事

• Docker Mailserver完全ガイド

まとめ

Maildirは、1メール1ファイルという単純な原則とrenameの原子性だけで、ロックフリーかつ堅牢なメール保存を実現する格納形式です。mboxと比較して、並行アクセス耐性、堅牢性、削除・移動の高速性、ファイル単位でのバックアップ・移行のしやすさに優れており、DovecotやPostfixを用いた自社メールサーバー構築における事実上のデフォルト選択肢です。

一方で、メール数が数十万通規模に達するとinode枯渇やディレクトリ走査コストといった弱点も無視できなくなります。個人〜中小企業規模のメールサーバーであれば、まずMaildirをシンプルに採用し、将来的にメールボックスが巨大化した段階でmdboxへの移行を検討する、という段階的なアプローチが実務では現実的です。

よくある質問（FAQ）

この用語についてもっと詳しく

Maildirに関するご質問や、メールサーバー構築のご相談など、お気軽にお問い合わせください。