IMAP

仕組み・詳細解説

接続状態とコマンドの流れ

IMAPセッションは、クライアントとサーバーの間でテキストベースのコマンド・レスポンスをやり取りしながら進行します。接続開始から終了まで、大きく4つの状態を遷移します。

1. Not Authenticated（未認証）: 接続直後の状態
2. Authenticated（認証済み）: LOGIN/AUTHENTICATEコマンドで認証成功後
3. Selected（メールボックス選択済み）: SELECT/EXAMINEでフォルダを選択後
4. Logout（切断）: LOGOUTコマンドまたは接続断で終了

# 典型的なコマンドの流れ（telnetでの疑似例）
a1 LOGIN user@example.com password
a1 OK LOGIN completed
a2 SELECT INBOX
a2 OK [READ-WRITE] SELECT completed
a3 FETCH 1:5 (FLAGS BODY[HEADER])
a3 OK FETCH completed
a4 STORE 3 +FLAGS (\Seen)
a4 OK STORE completed
a5 LOGOUT

主なコマンドとメールボックスのフラグ

IMAPは単なるメール取得だけでなく、フォルダ管理やメールの状態管理まで幅広くカバーするコマンド体系を持っています。

各メールにはサーバー側で一意のUID（Unique Identifier）が割り振られ、クライアントはこのUIDを使ってメールを再取得します。UIDは同じメールボックス内で変わらないことが保証されるため（UIDVALIDITYが変化しない限り）、複数端末が同じメールを正しく同期できる仕組みの核になっています。

使用ポートと暗号化

現在の実務では、143番でSTARTTLSを使う構成よりも、最初から暗号化された993番（IMAPS）を使う構成が推奨されます。STARTTLSはネゴシエーション前の平文通信区間が理論上存在し、中間者による「STARTTLSストリッピング」攻撃のリスクがゼロではないためです。Dovecotのdisable_plaintext_auth = yes設定と組み合わせ、暗号化前の認証情報送信を確実に禁止することが定石です。

具体例・ユースケース

複数デバイスでのメール同期

最も代表的な利用シーンです。会社のPCでメールを既読にすると、外出先のスマートフォンでも同じメールが既読として表示され、フォルダ分けや削除も全端末で反映されます。これはIMAPがサーバー側の状態（フラグ・フォルダ構成）を正として管理し、各クライアントがそれを参照する仕組みだからこそ実現できる挙動です。POP3で複数端末運用しようとすると、端末ごとに独立したダウンロード履歴を持つため、この同期は原理的に困難です。

Webメールクライアントのバックエンド

Roundcube、SOGoといったWebメールクライアントの多くは、内部的にIMAPでメールサーバーへ接続してメールボックスを表示しています。ユーザーはブラウザ経由でメールを操作しているだけですが、裏側ではWebアプリケーションサーバーがIMAPクライアントとして動作し、DovecotなどのIMAPサーバーとやり取りしています。自社でWebメールを提供する場合、IMAPサーバー側の同時接続数上限（mail_max_userip_connectionsなど）に注意が必要です。

共有メールボックス（問い合わせ窓口・サポート窓口）

「info@」「support@」のような共有アドレス宛のメールを複数の担当者が確認する運用でも、IMAPのサーバー同期性が活きます。ある担当者がメールに返信済みフラグを立てると他の担当者にもそれが見え、対応漏れや二重対応を防げます。Dovecotの共有メールボックス機能（Shared Mailboxes / ACLプラグイン）を使うと、特定ユーザーのメールボックスに他ユーザーがアクセス権限付きで乗り入れる構成も可能です。

モバイル端末でのプッシュ通知的な新着確認

スマートフォンのメールアプリが新着メールを即座に表示できるのは、多くの場合IMAPのIDLEコマンドを利用しているためです。クライアントはIDLEコマンドを発行したまま接続を維持し、サーバーは新着メールが届いた瞬間に通知を送り返します。ポーリング（定期的な問い合わせ）よりも通信量が少なく、バッテリー消費の面でも有利です。

自社システムからの受信メール監視

受注メールや帳票の自動取り込みシステムなど、業務システムがIMAP経由で特定のメールボックスを定期的にポーリングし、添付ファイルを自動処理する構成もよく見られます。この場合、処理済みメールにはIMAPのカスタムフラグやフォルダ移動（MOVEコマンド）で「処理済み」を明示し、二重処理を防ぐ設計が定石です。

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

メリット

• マルチデバイス同期: PC・スマホ・Webメールなど、どの端末からアクセスしても同じフォルダ構成・既読状態が見える
• サーバー側の一元バックアップ: メール本体がサーバーに集約されるため、端末紛失・故障時のデータ消失リスクが低い
• サーバー側検索が可能: SEARCHコマンドによりサーバー側で条件検索でき、大量メールでもクライアント側の負荷が小さい
• 共有メールボックスとの親和性: 複数担当者での問い合わせ窓口運用など、チームでのメール共有がしやすい
• 部分取得ができる: FETCH BODY[HEADER]のようにヘッダーのみ先に取得し、本文は開封時に取得するといった帯域節約が可能

デメリット・注意点

• サーバーディスク容量を圧迫する: 全メールがサーバーに残り続けるため、POP3と比べてストレージ計画とクォータ設定が必須
• オフラインアクセスがクライアント実装依存: クライアント側のキャッシュ機能に依存するため、オフライン閲覧の挙動がPOP3ほど単純ではない
• プロトコルがやや複雑: コマンド体系が豊富な分、サーバー実装・クライアント実装の互換性問題（拡張機能の対応差）が発生しやすい
• 同時接続数の制御が必要: 1ユーザーが複数端末・複数アプリで同時接続すると、サーバー側の接続数上限やメモリ消費に影響する
• 大量メールでのパフォーマンス低下: 数万通規模のメールボックスでは、インデックス（dovecot.index等）の肥大化により検索・SELECT処理が遅くなることがある
• 誤操作の影響がサーバー全体に及ぶ: フォルダ削除やEXPUNGEはサーバー上の実体に対して行われるため、ローカル操作のつもりで全端末のデータを消してしまう事故が起きやすい

混同されやすい用語・類似技術との違い

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

IMAPサーバーの選択

自社メールサーバーでIMAPを実装する際は、Dovecotが事実上の標準的な選択肢です。高性能なインデックス機構、豊富な認証バックエンド対応、PostfixとのLMTP連携のしやすさから、Linux環境のメールサーバー構築では広く採用されています。かつて使われたCourier IMAPやUW-IMAPは、開発の停滞やセキュリティ対応の遅れから現在の新規構築ではあまり推奨されません。

Dovecotの基本設定

# /etc/dovecot/dovecot.conf
protocols = imap
mail_location = maildir:~/Maildir

# SSL/TLS必須化
ssl = required
ssl_cert = </etc/letsencrypt/live/mail.example.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.example.com/privkey.pem
ssl_min_protocol = TLSv1.2

# 平文認証を暗号化前に禁止（STARTTLS/TLS必須）
disable_plaintext_auth = yes

# 10-mail.conf 等の別ファイルに分離するのが一般的

メールボックス形式にはMaildirとmboxの2方式がありますが、新規構築ではMaildir形式が第一候補です。1メール1ファイルで管理するため、複数プロセスからの同時アクセスでもロック競合が起きにくく、破損時の影響も1通単位に限定できます。mbox形式は1ファイルに全メールを追記する古い方式で、大容量メールボックスでは性能面・破損耐性の面から不利です。

クォータ設定（容量管理）

IMAPはメールをサーバーに残し続ける前提のため、ユーザーごとの容量上限（クォータ）を設定しておかないと、特定ユーザーのメールボックス肥大化がディスク逼迫を招きます。Dovecotではquotaプラグインで制御します。

# dovecot.conf 内、mail_plugins に quota を追加
mail_plugins = $mail_plugins quota

plugin {
  quota_rule = *:storage=2G
  quota_warning = storage=90%% quota-warning 90 %u
  quota_warning2 = storage=80%% quota-warning 80 %u
}

service quota-warning {
  executable = script /usr/local/bin/quota-warning.sh
  user = dovecot
}

容量超過時にメール受信そのものを止めるか、警告メールのみ送るかは運用ポリシー次第ですが、一般的にはPostfix側でLMTP応答時にクォータ超過を検知し、送信元に「メールボックスが満杯」のバウンスを返す設定と組み合わせます。

Postfixとの連携（LMTP配送）

受信メールをPostfixからDovecotのメールボックスへ引き渡す際は、LMTP（Local Mail Transfer Protocol）を使うのが現在の定石です。

# Postfix側 main.cf
virtual_transport = lmtp:unix:private/dovecot-lmtp

# Dovecot側 10-master.conf
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
}

従来型のprocmailやmaildrop経由の配送よりもLMTPの方が高速かつクォータ超過の応答をPostfix側にきちんと伝えられるため、新規構築であればLMTP連携を優先して検討することをおすすめします。

認証設定と証明書

認証バックエンドはPAM、passwd-file、SQL（MySQL/PostgreSQL）など複数選べますが、複数ドメイン・大量ユーザーを扱うなら仮想ユーザー方式（SQLまたはLDAP）が管理しやすくなります。TLS証明書はLet's Encryptで自動更新し、ssl_cert/ssl_keyのパスを証明書更新後も維持できるよう、シンボリックリンク（/etc/letsencrypt/live/...）を経由させておくと運用が安定します。

実務ポイント

• doveadmコマンドで運用確認: doveadm mailbox list -u user@example.comでフォルダ一覧、doveadm quota get -u user@example.comでクォータ使用状況を確認できる
• ログの継続監視: /var/log/dovecot.log・/var/log/mail.logで認証失敗（Login failed）の急増を監視し、ブルートフォース攻撃の兆候を早期発見する
• 同時接続数の制御: mail_max_userip_connectionsで同一IPからの同時接続数に上限を設け、モバイルアプリの多重ログインによるリソース枯渇を防ぐ
• インデックスの定期メンテナンス: 大規模メールボックスではdoveadm force-resyncでインデックス不整合を解消し、SELECT・検索の遅延を予防する
• fail2banとの連携: Dovecotの認証失敗ログをfail2banで監視し、一定回数失敗したIPを自動的にファイアウォールでブロックする構成を組み込む
• OAuth 2.0/XOAUTH2対応の検討: Gmail・Microsoft 365と連携するクライアントアプリでは、パスワード認証ではなくXOAUTH2による認証への対応が求められる場面が増えている
• バックアップとリストア手順の整備: Maildir形式はファイル単位のバックアップと相性が良いが、dsync（Dovecotのレプリケーション・バックアップツール）を使うと整合性の取れたバックアップ・移行が行いやすい

関連ブログ記事

• Docker Mailserver完全ガイド

Q. IMAPとは？

IMAP（Internet Message Access Protocol）は、メールサーバー上のメールボックスにリモートから接続し、フォルダ構成や既読状態を維持したまま閲覧・検索・管理するプロトコルです。メールはサーバーに保存されたまま、複数デバイスから同期して利用できます。

Q. IMAPとPOP3の違いは？

POP3はメールをダウンロードしてサーバーから削除する「ダウンロード型」、IMAPはサーバーにメールを残して複数端末から参照する「同期型」です。複数デバイスでメールを共有する場合はIMAPが実質必須です。

Q. IMAPのポート番号は？

標準ポートは143（STARTTLSで暗号化に切り替え可能）、暗号化接続は993（IMAPS/TLS）です。中間者攻撃のリスクを避けるため、実務では最初から暗号化される993の利用が推奨されます。

Q. JMAPとは何ですか？IMAPは廃れますか？

JMAPはJSON/HTTPベースの後継候補プロトコルで、Fastmail等の一部サービスで採用されています。ただし主要OSSサーバーやクライアントの対応は限定的で、当面はIMAPが主流であり続けると考えられます。

Q. IMAPとExchange ActiveSync（EAS）はどう違いますか？

EASはMicrosoft独自の同期プロトコルで、メールに加えて予定表・連絡先も同期対象に含みます。IMAPはメールの閲覧・管理に特化したオープンな標準プロトコルで、対応範囲と設計思想が異なります。

Q. IMAPのIDLEとは何ですか？

IDLEはクライアントが接続を維持したまま新着メールの通知をサーバーからプッシュ的に受け取る仕組みです（RFC 2177）。定期的なポーリングより通信量が少なく、モバイル端末での即時通知やバッテリー効率の面で有利です。

Q. 自社でIMAPサーバーを構築する場合、何を使えばよいですか？

Linux環境であればDovecotが事実上の標準です。Maildir形式でのメール保存、PostfixとのLMTP連携、TLS必須化、クォータ設定を組み合わせて構築するのが一般的な構成です。

Q. IMAPだとメールがサーバーの容量を圧迫しませんか？

はい、メールがサーバーに残り続けるためディスク使用量は増加します。Dovecotのquotaプラグインでユーザーごとの容量上限を設定し、警告メールや受信停止のしきい値を運用ポリシーとして決めておくことが重要です。