mbox

この用語をシェア

mboxとは

mboxは、すべてのメールを1つのテキストファイルに連結して保存する伝統的なメール格納形式です。1970年代のUnixメールシステム（Version 7 UnixやBSD版sendmail、MHなど初期のメールツール群）に起源を持ち、現存するメールボックス形式の中でも最も古い部類に入ります。受信箱・送信済み・迷惑メールといったフォルダ単位で1個のファイルが対応し、新着メールはそのファイルの末尾に追記されていく仕組みです。

構造が単純であるため実装が容易で、grep・awk・sedのような標準的なUnixコマンドで中身を直接検索・加工できる点は今も評価されています。一方で、後述するファイルロックの必要性や破損時の被害範囲の大きさから、現在の新規メールサーバー構築ではMaildir形式が主流になっています。ただし、Linuxカーネル開発コミュニティのパッチ運用（git format-patch・git am）やメーリングリストアーカイブの配布形式としては、今もmboxが標準的に使われ続けています。

mboxの仕組み・詳細解説

ファイル形式とFrom Line

mboxファイルの内部は、以下のように複数のメールがヘッダー・空行・本文の単位で連続して並ぶプレーンテキストです。各メールの先頭には「エンベロープFrom行（Unix From行）」と呼ばれるFrom （Fromの後にスペース）で始まる行が置かれ、これが次のメールとの区切りとして使われます。

From sender@example.com Mon Jan 14 12:00:00 2026
From: sender@example.com
To: recipient@example.com
Subject: Test Mail 1

This is the first message.

From sender@example.com Mon Jan 14 12:05:00 2026
From: sender@example.com
To: recipient@example.com
Subject: Test Mail 2

This is the second message.

このエンベロープFrom行は、RFC 5322で定義される通常のFrom:ヘッダーとは別物です。差出人アドレスと配送日時（Unix標準のasctime形式）を持ち、MTA（メール転送エージェント）がローカル配送時に付与します。

エスケープ処理とデータ整合性の課題

メール本文中に偶然「From 」で始まる行が含まれていると、パーサーがそこをメールの区切りと誤認してしまいます。これを防ぐため、本文中の該当行は配送時に「>From 」のようにエスケープされます。しかし、このエスケープ規則はmboxの亜種ごとに微妙に異なっており（後述）、異なる実装間でファイルをやり取りすると本文が変化してしまう、あるいは逆に区切り判定を誤るという相互運用性の問題が古くから指摘されてきました。さらに、書き込み中にプロセスが異常終了したり、ディスク容量不足でファイルが途中で切れたりすると、1通のメールだけでなくファイル全体、つまりそのフォルダの全メールが読み出せなくなるリスクがある点が、mbox最大の弱点とされています。

ロック機構（dotlock・flock・fcntl）

1つのファイルに複数プロセス（MTAによる新着メールの追記と、MUA/IMAPサーバーによる既読メールの削除・移動）が同時にアクセスするため、mboxでは排他制御としてファイルロックが必須です。代表的な方式は次の3つで、実運用では複数を組み合わせて使うことも珍しくありません。

• dotlock: mbox.lockのような専用ロックファイルを作成することでロックを表現する方式。NFS環境でも比較的安全に動作するが、ロックファイルの権限設定を誤ると書き込み不能になる。
• flock(): BSD系のアドバイザリロック。カーネルレベルで動作し高速だが、NFS越しでは正しく機能しない場合がある。
• fcntl(): POSIX標準のロックAPI。プロセスが異常終了した際に自動解放される利点がある一方、スレッド間ロックの扱いに注意が必要。

Dovecotの設定ではmail_locationにLOCK=fcntlやLOCK=dotlockを明示的に指定でき、環境（ローカルディスクかNFSか）に応じたロック方式の選択が運用上の勘所になります。

mboxの主要バリエーション

「エスケープ処理」と「メール長の管理方法」の違いから、mboxには複数の亜種（フレーバー）が存在します。同じ「mbox形式」でも実装によって細部の解釈が異なるため、異なるツール間でファイルを移動する際は亜種の違いに注意が必要です。

• mboxo: 最も古い元祖形式。本文中の「From 」行を無条件に「>From 」へエスケープするため、元々「>From 」で始まる行との区別がつかなくなる問題がある。
• mboxrd: mboxoのエスケープ方式を改良し、エスケープの巻き戻し（アンエスケープ）を安全に行えるようにした形式。procmailなど一部のツールが採用している。
• mboxcl: 各メールのヘッダーにContent-Lengthを付与し、本文長をバイト数で明示することでエスケープに依存せずメールの終端を判定できるようにした形式。
• mboxcl2: mboxclをベースに、本文中の「From 」行のエスケープ自体を行わない形式。Content-Lengthヘッダーが正しければエスケープ処理は不要という考え方に基づく。

実務上は、どの亜種で保存されたファイルなのかを事前に確認せずに単純結合（cat）やバイナリコピーをすると、区切り判定を誤って文面が壊れることがあるため注意が必要です。

具体例・ユースケース

Unix系OSのローカルメールスプール

最も典型的な例が、システムアカウント宛てのローカル配送先である/var/mail/ユーザー名（ディストリビューションによっては/var/spool/mail/ユーザー名）です。Postfixやsendmailのローカル配送エージェントは、既定でこのパスにmbox形式でメールを追記します。cronジョブの実行結果通知や、サーバー監視ツールからのアラートメールが、この仕組みでrootやシステムユーザーの受信箱に溜まっていくのはよくある光景です。

procmail・sieveによる振り分け配送

procmailは古くからmbox形式のフォルダへの振り分け配送に使われてきました。例えば特定件名のメールを専用のmboxファイルへ格納するルールは次のように書けます。

:0:
* ^Subject:.*請求書
$HOME/mail/invoices

この設定では、件名に「請求書」を含むメールが$HOME/mail/invoicesというmboxファイルに追記されます。DovecotのSieveフィルタでも、mail_location設定がmbox形式の場合は同様に振り分け先フォルダがmboxファイルとして生成されます。

Gitパッチ運用とメーリングリストアーカイブ

開発コミュニティでは、パッチをメールでやり取りする文化が今も残っており、その保存形式としてmboxが使われています。git format-patchで生成したパッチをまとめて1ファイルにし、git amで取り込むフローはmbox形式そのものです。

git format-patch --stdout HEAD~3 > patches.mbox
git am patches.mbox

また、多くのオープンソースプロジェクトのメーリングリストアーカイブは、月別・年別のmboxファイルとして配布されており、過去の議論をローカルでまとめて検索したい場合にダウンロードしてgrepで検索する、といった使い方が可能です。

フォレンジック・法的保存でのエクスポート

電子メールの証拠保全や監査対応では、対象メールボックスをまとめて1ファイルにエクスポートできるmbox形式が扱いやすいという理由で採用されることがあります。Googleの「データエクスポート」機能でGmailのメールをエクスポートすると、mbox形式のファイルが生成されます。またThunderbirdはローカルフォルダの保存形式として長らくmboxを既定採用しており、ローカル環境に保存されたメール資産をそのまま監査対象として扱えるという実務上のメリットがあります。

メリット・デメリット

観点	メリット	デメリット・注意点
構造	単一ファイルでシンプル。grep等の標準コマンドで直接処理できる	亜種ごとにエスケープ規則が異なり相互運用性に難がある
バックアップ・転送	1ファイルをコピーするだけで完了する手軽さ	書き込み中にコピーすると内容が壊れる恐れがあり、整合性確保の手順が必要
並行アクセス	ロック機構（dotlock/flock/fcntl）で一応の排他制御が可能	同時アクセスが多い環境ではロック待ちが発生しやすく、NFS環境では特に不安定
パフォーマンス	小規模メールボックスでは十分高速	メール削除・移動のたびにファイル全体の書き直しが発生し、メール数が増えるほど遅くなる
障害耐性	構造が単純なため破損時の解析・復旧手順自体は比較的追いやすい	破損箇所以降、あるいはファイル全体のメールが読み出せなくなるリスクがある
互換性	gitのパッチ運用やメーリングリストアーカイブなど、今も標準的に使われる場面がある	新規のメールサーバー構築ではサポート・エコシステムの主流からは外れつつある

Maildirとの比較

項目	mbox	Maildir
シンプルさ	✅ 非常にシンプル	やや複雑
並行アクセス	❌ 弱い（ロック必要）	✅ 強い
破損リスク	❌ 高い（全体破損）	✅ 低い
削除効率	❌ 遅い（再書き込み）	✅ 高速
バックアップ	✅ 簡単（1ファイル）	複雑（ファイル数が多い）
NFS環境での安定性	❌ ロック競合が起きやすい	✅ ロック不要で相性が良い
主な対応ソフトウェア	sendmail、Thunderbird（ローカルフォルダ）、mutt	Postfix、Dovecot、Courier-IMAP
推奨される用途	アーカイブ・エクスポート・パッチ運用など読み取り中心の用途	現用の受信箱として日常的に読み書きする用途

両者を折衷した形式として、Dovecotが独自に開発したmdbox（複数メールを固定サイズの中間ファイルにまとめつつ、メールごとのメタデータをインデックス管理する形式）もあります。mboxの「バックアップの手軽さ」とMaildirの「並行アクセス耐性」の中間を狙った設計で、Dovecotを使う場合はmbox・Maildir・mdboxのいずれかをmail_locationで選択できます。

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

Postfix・Dovecotでの設定と扱い

Postfixはローカル配送エージェント（local(8)）が既定で/var/mail/ユーザー名にmbox形式で追記します。virtual_mailbox系の設定を使わない、伝統的なシステムアカウント宛て配送ではこの挙動になるため、意図せずmbox運用になっているケースもあります。Maildirで受信させたい場合は、main.cfで明示的に指定します。

# /etc/postfix/main.cf
# Maildir形式で配送する場合（末尾のスラッシュが必須）
home_mailbox = Maildir/

Dovecotではmail_locationディレクティブでmbox運用時の細かい挙動を制御できます。ロック方式やINBOXの実体パスも合わせて指定するのが一般的です。

# /etc/dovecot/conf.d/10-mail.conf
mail_location = mbox:~/mail:INBOX=/var/mail/%u:LOCK=fcntl

Dovecotのdoveadmコマンドは、mboxとMaildir間の相互変換・同期にも利用できます。

# mboxからMaildirへ変換しつつバックアップ
doveadm backup -u user@example.com maildir:/home/user/Maildir

非推奨の理由と現状の位置づけ

現代の新規メールサーバー構築では、mboxよりもMaildirが推奨されます。理由は次の通りです。

• 並行アクセス問題: 複数プロセスからの同時アクセスでロックが必要になり、実装ミスや環境差でデッドロック・ロック待ちが発生しうる
• 破損リスク: ファイル破損時に、そのフォルダの全メールを喪失する恐れがある
• パフォーマンス: メール削除・既読フラグ更新のたびにファイル全体の再書き込みが必要になり、メール数が多いほど遅くなる
• NFS非対応: ネットワークファイルシステム上でのロックが不安定になりやすい

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

• パーミッション管理: システムスプール/var/mailはsetgidのmailグループとsticky bitが設定されているのが一般的で、個々のmboxファイルは所有者以外に読み書きさせないよう0600程度に保つ
• バックアップのタイミング: 書き込み中のmboxファイルをそのままcpやrsyncでコピーすると内容が壊れる可能性があるため、ロックを取得してからコピーするか、専用ツール（doveadm backup等）を使う
• ディスク容量監視: 1ファイルに追記され続ける性質上、想定外の肥大化に気づきにくい。/var/mail配下のファイルサイズは定期的に監視する
• フォレンジック対応時の証跡保全: エクスポート後のmboxファイルはハッシュ値を記録するなど改ざん検知の仕組みを併用すると、証拠性を担保しやすい

レガシーシステムからの移行手順

古いシステムでmboxを使用している場合、Maildirへの移行がまず検討対象になります。代表的な手段は次の2つです。

# mb2md（mbox to Maildir変換ツール）を使う場合
mb2md -s /var/mail/user -d ~/Maildir

# Dovecotのdoveadmコマンドを使う場合
doveadm backup -u user@example.com maildir:~/Maildir

移行を安全に行うための実務上の定石は次の通りです。

• 移行前に元のmboxファイルを別名で退避し、必ずバックアップを取る
• 移行後、doveadm mailbox status messages INBOXなどでメール数の整合性を確認する
• IMAPクライアント側のキャッシュ・UIDVALIDITYが変わることがあるため、利用者には再同期が必要になる可能性を事前に案内する
• 移行作業はメンテナンス時間帯に行い、作業中は新規配送を一時的にキューイングする

関連ブログ記事

• Docker Mailserver完全ガイド

まとめ

mboxは、歴史的に重要なメール格納形式であり、単一ファイルという構造のシンプルさゆえに、grepによる直接検索やgitのパッチ運用、メーリングリストアーカイブの配布形式として今も現役です。一方で、現代の日常的な受信箱運用としては、並行アクセス耐性・破損リスク・削除効率の観点からMaildirへの移行が推奨されます。新規メールサーバー構築時はMaildir（またはDovecotのmdbox）を選び、mboxは読み取り中心のアーカイブ用途やレガシー資産の扱いとして位置づけるのが実務的な判断です。

よくある質問（FAQ）

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

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