IMAPとPOP3

IMAPは、クライアントがサーバー上のメールボックス、メールの状態、およびコンテンツを操作することを可能にし、複数の端末で共通のビューを維持するのに適しています。POP3は主に、メールドロップ内のメッセージの列挙、ダウンロード、および削除を提供します。両方ともメールをローカルにキャッシュすることができ、「ダウンロードしたらすぐに削除しなければならない」というわけではありません。真の違いは、サーバーがクライアントに提供できる同期可能な状態と操作の量にあります。

本稿では、IMAP4rev2（RFC 9051）を主要な意味論の根拠とし、IMAP4rev1サービスに遭遇した場合はCAPABILITYに基づいて拡張機能を判断し、新旧のレスポンス例を安易に混用しないようにします。RFC 9051

IMAPセッション：ログインしてもメールボックスが選択されたわけではない

接続は、未認証、認証済み、メールボックス選択済み、退出などの状態を経験します。LISTは認証後にメールボックスを列挙し、SELECTは読み書き可能なメールボックスを選択し、EXAMINEは読み取り専用ビューを取得します。FETCH、STOREなどは選択されたメールボックスに対して機能します。認証が成功しても、すべての後続コマンドが自動的にINBOXを対象とするわけではありません。

コマンドにはクライアントタグ（例：a003）が付与されます。同じタグを持つ最終的なOK/NO/BADは、そのコマンドが完了したことを示します。* で始まる未タグ付けレスポンスは、データや状態の変化を報告するものであり、別のコマンドの最終応答ではありません。+ は入力の継続を促すプロンプトです。クライアントパーサーは、レスポンスが交差するケースを処理すべきであり、「1行読み取った」ことを呼び出しの終了と見なしてはいけません。

旧IMAP4rev1のRECENT / \Recentはrev2で廃止されました。また、それは元々、全デバイスで一貫した未読数として直接扱うことはできませんでした。未読数は通常、\Seen フラグが存在するかどうかに基づいて判断されます。

シーケンス番号、UID、UIDVALIDITY：キャッシュキーが3つの要素を必要とする理由

メッセージシーケンス番号は、現在のメールボックス内の位置であり、1から始まります。前のメールがクリアされると、後ろのメールのシーケンス番号は前に移動します。UIDは、同じメールボックス内で同じUIDVALIDITYの下では安定して増分しますが、ギャップ（欠番）が生じる可能性があります。それはアカウント全体のグローバルメッセージIDではありません。

クライアントがシーケンス番号2がUID 104に対応しているのを見て、別のクライアントがシーケンス番号1を削除したと仮定します。記憶した位置に基づいて STORE 2 を実行し続けると、現在指し示しているのはすでにUID 108になっている可能性があります。同期ツールはUID操作と完全なスコープを使用し、受信した削除やシーケンス番号の変化情報をタイムリーに更新する必要があります。

uids = [101, 104, 108]
remembered_sequence = 2
remembered_uid = uids[remembered_sequence - 1]
assert remembered_uid == 104
uids.pop(0)  # 元のシーケンス番号1がクリアされた
assert uids[remembered_sequence - 1] == 108
assert uids.index(remembered_uid) + 1 == 1
old_key = ('INBOX', 700, 104)
new_epoch_key = ('INBOX', 701, 104)
assert old_key != new_epoch_key
print('シーケンス番号の移動とUIDVALIDITYによるキャッシュ隔離モデルは正常に動作')

実際のキャッシュキーには、アカウント/サーバー識別子も含まれるべきです。UIDVALIDITY が変更された場合、古いUIDマッピングはサーバー上のメールを特定するために引き続き使用することはできません。古いオフライン削除コマンドを新しいUID 104に直接適用するのではなく、再列挙して関連付けを構築する必要があります。コピーまたは別のメールボックスへの移動後、ターゲットのUIDも変更される可能性があります。サポートされているUIDマッピングレスポンスは、キャッシュの更新に役立ちます。UIDPLUS RFC 4315

UIDNEXT とアスタリスク範囲の詳細

UIDNEXT の値は将来のUID割り当てを予測するために使用されますが、UIDは飛び番になる可能性があります。もう一つの誤解されやすい点は、範囲の端点が逆順になることを許可している点です。メールボックスの最大UIDが108の場合、UID FETCH 109:* におけるアスタリスクは最大のUIDを表し、常に空集合を返すと単純に理解してはいけません。クライアントは適切な検索/同期メソッドを使用し、返されたUIDが実際にローカルの水位（直近の処理済み位置）よりも高いかどうかを検証する必要があります。

存在しない指定UIDは通常無視され、コマンドのOKは対象メールが見つかったことを保証するものではありません。したがって、「操作が完了した」「対象が存在する」「対象の状態が期待通りである」は、3つの異なる観察事項です。

1通目を削除した後、シーケンス番号2は同じメールですか？

1通目をクリアすると、シーケンス番号2はUID108を指すようになり、UID104はシーケンス番号1に移動します。メールボックスを再構築しても、104が再び現れたとしても、古いキャッシュキーを再利用することはできません。変化するのはリストの並べ替えだけでなく、アイデンティティのスコープそのものです。

コンテンツの取得、フラグの変更、バイト単位の読み取り

UID FETCH 104 (UID FLAGS RFC822.SIZE BODY.PEEK[HEADER.FIELDS (FROM SUBJECT DATE)]) により、表示リストに必要なフィールドのみを取得でき、大きな添付ファイル全体をダウンロードする必要がありません。BODY.PEEK[...] はコンテンツの読み取りによって暗黙的に \Seen を設定しません。通常の BODY[...] の対応する取得動作は、これを設定する可能性があります。

サーバーはコンテンツを返す際に {N} リテラルを使用できます。Nは、それに続く生バイト数を示します。本文には改行、括弧、またはレスポンスのように見えるテキストが含まれている可能性があるため、パーサーは正確にNバイトを読み取り、その後でプロトコル解析を再開する必要があります。右括弧を探すために単純に行単位で処理してはいけません。

payload = '件名：ステータス\r\n'.encode('utf-8')
assert len(payload) == 17  # 5文字の日本語15バイト、CRLF 2バイト
wire = b'{17}\r\n' + payload + b')\r\na004 OK done\r\n'
header, rest = wire.split(b'\r\n', 1)
size = int(header[1:-1])
literal, tail = rest[:size], rest[size:]
assert literal.decode('utf-8') == '件名：ステータス\r\n'
assert tail.startswith(b')\r\na004 OK')
assert len(literal) != len(literal.decode('utf-8'))
print('UTF-8リテラルのバイト単位の区切りは正常に動作')

既読マークは UID STORE 104 +FLAGS.SILENT (\Seen) で設定できます。+FLAGS は指定されたフラグを追加します。FLAGS を使用すると完全な集合が置き換えられ、他のクライアントの更新を上書きする可能性があります。.SILENT は、この操作による対応するフラグデータのエコーを抑制しますが、すべてのサーバー状態通知を閉じるわけではありません。

削除と移動：操作は同じ「削除」ボタンの意味ではない

\Deleted を設定するのはマーキングに過ぎません。EXPUNGE によって、選択されたメールボックス内で削除マーク付きのメールが実際にクリアされます。通常の EXPUNGE は、別のクライアントがマークしたメールも一緒にクリアする可能性があるため、自分自身が行ったUIDのみを処理すると仮定してはいけません。サポートされている場合は、限定されたUID集合を持つ UID EXPUNGE を使用することで範囲を狭めることができます。

MOVE はメールをあるメールボックスから別のメールボックスに移動します。古いクライアントは、COPY、削除マーク、EXPUNGE を組み合わせてシミュレートしますが、これには中間状態と失敗のウィンドウが存在します。専用の MOVE は部分的な組み合わせ操作の問題を回避できますが、複数メッセージの操作では部分的な失敗を処理する必要があり、一連の移動をアプリケーションデータベースのような「すべてまたはなし」のトランザクションとして記述してはいけません。MOVE RFC 6851

CLOSE は書き込み可能な選択状態において、削除マーク付きのメッセージをクリアする可能性があります。UNSELECT は、このクリアを実行せずに選択状態を終了します。読み取り専用チェックを行う際は、EXAMINE の意味合いを優先して理解し、「メールボックスから退出する」ために削除の影響を及ぼす操作を安易に呼び出してはいけません。

IDLE は変更通知であり、永続的なイベントログではない

クライアントはタグ付きの IDLE を送信し、サーバーが + で応答すると、そのコマンドを待機状態に保ちます。その間、EXISTS や flags への変更などを報告できます。クライアントが次の通常コマンドを実行する際は、タグなしの DONE を送信し、IDLE のタグ付き完了応答を待ってから、継続します。

仕様では、サーバーのアイドルタイムアウトに適応するため、約29分以内の間隔で IDLE を終了して再送信することを推奨しています。中間のNATやモバイル端末のスリープにより、それよりも早く切断される可能性があります。IDLE はタイムリーな通知を提供しますが、固定されたレイテンシ、常時オンライン、または切断中のメッセージ通知のリプレイを保証するものではありません。IMAP IDLE

増分同期と並行衝突

UIDNEXT のみを比較しても、一部の新規変更は検出できますが、古いメールのフラグ変更や削除されたUIDを知ることはできません。CONDSTORE をサポートするサーバーは、MODSEQ によって状態変化を識別します。QRESYNC は、高速な再同期と VANISHED 削除情報をさらにサポートします。使用前には、プロトコルバージョンと能力に基づいて有効化を完了する必要があり、すべてのサービスが実装しているとは仮定してはいけません。CONDSTORE/QRESYNC RFC 7162

クライアントがメールの MODSEQ 20 を読み取り、オフライン中に別のクライアントがそれを 21 に変更したと仮定します。UNCHANGEDSINCE 20 を条件とする STORE コマンドは、新しい状態の上書きを拒否し、適用されなかった対象に対して MODIFIED を返すことができます。クライアントは衝突を無視してローカルの水位を進めるのではなく、再読み込みしてマージを決定する必要があります。

したがって、復旧フローは次のようになります。メールボックスと UIDVALIDITY を検証し、新規追加、変更、削除を補完し、ローカルデータが永続化されたことを確認してから、同期水位を保存します。IDLE による通知と同期水位は同じものではありません。水位の更新が実際のコンテンツの保存より先に行われると、クラッシュ後に同期が完了したと誤認する可能性があります。

POP3：ダウンロード、マーク、更新は3つのアクションに分かれる

POP3 では、認証後に TRANSACTION 状態に入り、LIST/STAT でメッセージとサイズを確認し、RETR でダウンロードし、DELE で削除マークを付けます。トランザクション状態から正常に QUIT して初めて UPDATE 状態に入り、マークに基づいて削除が実行されます。RSET により削除マークをクリアでき、異常な切断は、以前の DELE のみによって削除更新フェーズに入るべきではありません。POP3 RFC 1939

したがって、「POP3 はダウンロード＝削除」というわけではありません。クライアントはサーバーのコピーを保持することも、ローカルコピーの保存が成功してから削除を要求することもできます。複数のデバイスがすべてコピーを保持する場合、それぞれがダウンロードできますが、IMAP のような共有既読やフォルダ同期のセマンティクスはありません。

POP3 メッセージ番号は、現在のメールドロップセッション内でのみ位置指定に使用され、セッションを跨ぐと変化する可能性があります。オプションの UIDL はセッションを跨ぐ識別子を提供し、クライアントはこれに基づいて重複ダウンロードを回避します。これは RFC 5322 Message-ID ではありません。仕様では、完全に同一のコピーが同じ unique-id を持つ特殊なケースすら許可されており、UIDL を無視できるグローバル一意のUUIDとして扱うことはできません。

ローカル保存とサーバー UPDATE には共通のトランザクションがありません。まず「ダウンロード済み」を記録してからコンテンツを永続化すると、クライアントのクラッシュにより保存漏れが発生する可能性があります。コンテンツは保存済みだがローカル記録がまだコミットされていない場合、再接続時に重複ダウンロードが発生する可能性があります。QUIT が実行されたが応答が失われた場合、削除結果にも曖昧さが残ります。アーカイバプログラムは、ローカルコンテンツとインデックスを確実にコミットし、再接続時にサーバーの状態を再列挙する必要があります。

DELE の後に切断すると、メールは削除されますか？

まず RETR を実行してから DELE を実行すると、サーバーのコピーはまだ残っています。異常な切断後に再接続すると、マークは消え、メールは保持されます。リセット後に正常な QUIT を実行して初めて、サーバーは削除します。ダウンロードせずに削除して QUIT を実行した場合、このモデルではローカルにコピーがないことが露呈します。

TLS、認証、および選択基準

IMAP では TCP 993、POP3 では TCP 995 が一般的に暗黙的 TLS を使用します。143/110 は、それぞれ STARTTLS/STLS によってアップグレード可能ですが、具体的な能力はネゴシエーションによって決定されます。パスワードを送信する前に、サーバーの身元検証を完了させる必要があります。OAuth やその他の SASL メカニズムのサポートはサーバー側の能力によって決まり、接続が TLS を使用しているからといって証明書検証をスキップしてはいけません。メールアクセス TLS RFC 8314

複数デバイスの協調、サーバー検索、フォルダ同期は IMAP の状態モデルに適合しています。一方、独立したアーカイブライブラリへの単方向ダウンロードには POP3 を使用できますが、「シンプル」だからといって、バックアップ、重複排除、削除のタイミングの問題が自動的に解消されるわけではありません。IMAP 同期はバックアップではありません。サーバー上での誤削除はすべてのクライアントに同期されるため、独立したバージョンの保持と復元ポイントは、別の機能です。