mbox完全ガイド — 仕組み・種類・運用・移行の実務知識

2025年12月19日 最終更新日時 : 2025年12月19日 エバープレイ編集部

はじめに — mboxとは何か

mboxは、UNIX系の歴史的なメールボックス（ローカルメールストア）フォーマットの総称です。複数のメールメッセージを1つの平文ファイルに連結して格納する仕組みで、古くからメールソフトやサーバで広く使われてきました。単純さと互換性のために今でも多くの場面で見かけますが、実運用ではフォーマットの差異や同時アクセスに関する注意点が多数存在します。本稿では、内部構造、派生形式（mboxo, mboxrd, mboxcl系など）、ツール連携、運用上の問題点と対処法、他フォーマットへの移行手順までを詳しく解説します。

基本構造 — メッセージの区切り方

mboxの基本的なアイデアは極めて単純で、各メッセージをそのまま順に書き出し、メッセージの先頭を示す区切り行（厳密には“From_行”と呼ばれる）を挿入して区別します。区切り行の典型は行頭に「From 」があり、その後に送信者（エンベロープ送信者）や日付が続く書式です。例：

From sender@example.com Thu Jan 1 00:00:00 2020

この行が現れるたびに新しいメッセージの開始とみなされます。メッセージ本体はRFC 5322（インターネットメッセージ形式）に準拠したヘッダとボディで構成されますが、mbox自体はメール本文の内部に現れる「From 」で始まる行と区別する必要があります。そのため、本文側の「From 」行をどう扱うかが複数の派生仕様を生みました。

主要な派生形式とエスケープ/区切り戦略

  • mboxo（古い形式）: 最も原始的な方式で、メッセージ本文中の「From 」行を特別にエスケープしない実装も存在しました。実装差により曖昧性と破損の原因となるため、現在では推奨されません。
  • mboxrd: よく使われている派生で、メッセージ本文の行が「From 」で始まる場合、行頭に「>」を付けてエスケープします。読み込み時は先頭の「>」を除去して元に戻します。これにより本文中の区切り行誤検出を避けます。Pythonや多くのツールがこの方式をサポートしています。
  • mboxcl / mboxcl2（Content-Lengthベース）: 各メッセージにContent-Lengthヘッダを付与して長さを明示し、ファイル内のバイト数でメッセージ境界を決める方式です。これにより本文内の「From 」行のエスケープが不要になりますが、Content-Lengthの信頼性（改変や転送での不一致）が問題になることがあります。

実際のファイルでは、これらが混在するケースや微妙に仕様が違う実装（多重引用の扱いなど）があり、完全な互換性を期待するのは危険です。

実装と互換性 — どのクライアント/サーバが使うか

歴史的に多くのローカルメールクライアントやサーバがmboxをサポートしてきました。UNIXの古いメールユーティリティ、muttやalpineといった端末型クライアント、さらに一部のデスクトップメールソフト（例: 伝統的なThunderbirdのフォルダ形式はmboxに類する形）やIMAP/POPサーバのローカルストアとして対応してきました。メールサーバ側ではDovecotやCourierがmboxを扱えますが、デフォルトや推奨は環境によって異なります。

長所と短所

  • 長所
    • 単純なファイル構造で扱いやすい（テキストエディタで確認可能）。
    • バックアップやアーカイブが容易（1ファイルを扱えばよい）。
    • 歴史的互換性が高く、多くのツールが読み書きできる。
  • 短所
    • ファイルが大きくなると性能劣化（シーク／更新コストやI/O）が発生しやすい。
    • 複数プロセスからの同時アクセスで破損する危険がある（ロックの扱いが実装依存）。
    • メッセージ単位での操作（削除・追加・移動）が非効率。
    • フォーマット差異（エスケープやContent-Length方式）によりツール間で不整合が起きる可能性。

運用上の注意点

mboxを運用する際に特に重要なのは「同時アクセス」と「ロック」です。多くの実装はファイルロック（flock）やdot-lock（ロックファイル）で整合性を保ちますが、ロックの方式がクライアントやOS間で異なるとロックが効かず破損に至ることがあります。対策としては：

  • 単一のプロセスに更新を集中させる（例: MDA/LMTPでの受信は専用プロセスにする）。
  • 定期的にmboxを分割・アーカイブし、巨大化を防ぐ。
  • 重要なメールは別途バックアップ（増分スナップショットや外部ストレージ）を取る。
  • 可能ならMaildirなどメッセージ単位のストレージへ移行を検討する。

他フォーマットとの比較：mbox vs Maildir

Maildirは1メッセージ1ファイルの形式で、同時アクセスやメッセージ単位の操作に強いのが利点です。大規模ユーザや高スループットのサーバではMaildirが好まれます。一方、mboxは小規模環境や簡単なアーカイブ用途では無駄が少なく扱いやすいことがあります。移行時にはフラグ（既読/未読）、フォルダ構造、メッセージIDやUIDVALIDITY相当の保持方法を検討する必要があります。

ツールとユーティリティ

mboxを扱う代表的なツールには次のようなものがあります。

  • formail（procmailパッケージ）: mboxの分割や整形に使われる伝統的ツール。
  • mb2md / mbox-to-maildir系ユーティリティ: mboxからMaildirへ変換するツール群。
  • Pythonのmailboxモジュール: スクリプトでmboxを読み書きする際に便利。mbox, mboxrd, mboxo, mboxclなどのフォーマットをサポート。
  • mboxgrep/mbox-tools: 大量のmboxから検索・抽出を行うためのツール。
  • メールサーバ（Dovecot, Courier）やクライアント（muttなど）: 既存の読み書きサポート。

実践例：mboxファイルを分割・解析する

小さな例として、formailを使って大きなmboxをメッセージ単位に分割するコマンドがあります（Unix系）。

formail -s

また、Pythonスクリプトでmailbox.mboxを使い、メッセージごとに処理することも可能です。スクリプトであればmboxrdとmboxclの違いを意識しつつ読み込みモードを指定して解析できます。

移行ガイド：mboxからMaildirへ移す手順（概略）

  • 1) バックアップ：まずmboxファイルを丸ごとバックアップする。問題発生時に戻せるようにすること。
  • 2) 検査：mboxのフォーマット（mboxrdかContent-Lengthベースか）を確認する。Pythonのmailboxや専用ツールで自動判定できる場合がある。
  • 3) 変換テスト：1ユーザ分のデータで変換を試す。mb2mdなどのツールを使い、ヘッダの破壊やフラグの損失がないかを確認する。
  • 4) フラグとメタデータ：既読/未読やフラグ情報をどう扱うか設計する。Maildirではファイル名や副ディレクトリで状態を表現することが一般的。
  • 5) ロールアウト：小規模で段階的に移行。問題がなければ対象を拡大する。
  • 6) インデックス再構築：必要に応じて検索インデックス（notmuchなど）を再作成する。

よくあるトラブルと対処

  • ファイルロックの不一致での破損：クライアントのロック方式をそろえるか、更新を仲介するサービスを導入。
  • mboxファイルの巨大化：定期的なアーカイブ・スナップショットと古いメッセージの分割保管。
  • 文字コードや改行コードの問題：古いデータだとCRLF/ LF混在や非UTF-8のヘッダがあるため、変換ツールで正規化。
  • Content-Length不整合：mboxcl方式でContent-Lengthが不正ならそのメッセージを手動で修正するか、mboxrd読み込みにフォールバックする。

まとめ — いつmboxを選び、いつ移行すべきか

mboxは今なお有用なフォーマットで、単純なアーカイブや互換性維持の目的では適しています。しかし、並列アクセスが多いサーバや大量のメールを扱う環境ではMaildirのようなメッセージ単位ストアの方が安全で効率的です。運用中のmboxを扱う場合は、フォーマットの種類（mboxrd等）を把握し、定期的なバックアップとロック戦略の整備、必要なら段階的な移行を計画してください。

参考文献

カテゴリー
IT
前の記事
Matroska と WebM の深層解説 — コンテナの仕組みと実運用での最適化New!!
2025年12月19日
次の記事
MCMC入門と実践：マルコフ連鎖モンテカルロの理論・アルゴリズム・実装ガイドNew!!
2025年12月19日