メインコンテンツまでスキップ

2. プロトコル概要 (Protocol Overview)

IMAP4rev2 プロトコルは、TCP が提供するような信頼性の高いデータストリームを前提としています。TCP を使用する場合、IMAP4rev2 サーバーはポート 143 (平文ポート) またはポート 993 (暗黙的 TLS ポート) でリッスンします。

2.2 コマンドとレスポンス (Commands and Responses)​

IMAP4rev2 接続 (Connection) は、クライアント/サーバーネットワーク接続の確立、サーバーからの初期挨拶、およびクライアント/サーバー間の相互作用で構成されます。これらのクライアント/サーバー間の相互作用は、クライアントコマンド (Client Command)、サーバーデータ (Server Data)、およびサーバー完了結果レスポンス (Server Completion Result Response) で構成されます。

クライアントとサーバーによって送信されるすべての相互作用は、行の形式、つまり CRLF で終わる文字列です。IMAP4rev2 クライアントまたはサーバーのプロトコルレシーバーは、行または既知のカウントを持つオクテットのシーケンスの後に行が続くものを読み取ります。

2.2.1 クライアントプロトコル送信者とサーバープロトコル受信者 (Client Protocol Sender and Server Protocol Receiver)​

クライアントコマンドは操作を開始します。各クライアントコマンドには、「タグ」(Tag) と呼ばれる識別子 (通常は短い英数字の文字列、例えば A0001、A0002 など) がプレフィックスとして付けられます。クライアントは各コマンドに対して異なるタグを生成します。より正式には：クライアントはすべてのコマンドに対して一意のタグを生成すべきです (すべきである)、ただしサーバーはタグの再利用を受け入れなければなりません (しなければならない)。

クライアントはこの仕様で概説されている構文に厳密に従わなければなりません (しなければならない)。スペースや引数が欠落している、または余分なコマンドを送信することは構文エラーです。

クライアントからの行が完全なコマンドを表さない場合が2つあります。1つのケースでは、コマンド引数がオクテットカウントで引用されます (セクション 4.3 のリテラル (Literal) の説明を参照)。もう1つのケースでは、コマンド引数がサーバーフィードバックを必要とします (セクション 6.2.2 の AUTHENTICATE コマンドを参照)。いずれのケースでも、サーバーがオクテット (該当する場合) とコマンドの残りを受け取る準備ができている場合、サーバーはコマンド継続要求レスポンス (Command Continuation Request Response) を送信します。このレスポンスには、トークン "+" がプレフィックスとして付けられます。

注意：逆に、サーバーがコマンドでエラーを検出した場合、コマンドに一致するタグを持つ BAD 完了レスポンス (後述) を送信してコマンドを拒否し、クライアントがそれ以上コマンドを送信するのを防ぎます。

サーバーが他のコマンドの完了レスポンスを送信する (複数のコマンドが進行中の場合) か、タグなしデータ (Untagged Data) を送信する可能性もあります。いずれの場合も、コマンド継続要求は保留中のままです。クライアントはレスポンスに対して適切なアクションを実行し、サーバーから別のレスポンスを読み取ります。すべての場合において、クライアントは新しいコマンドを開始する前に、完全なコマンドを送信しなければなりません (しなければならない) (すべてのコマンド継続要求レスポンスを受信し、コマンドのコマンド継続を送信することを含む)。

IMAP4rev2 サーバーのプロトコルレシーバーは、クライアントからコマンド行を読み取り、コマンドとその引数を解析し、サーバーデータとサーバーコマンド完了結果レスポンスを送信します。

2.2.2 サーバープロトコル送信者とクライアントプロトコル受信者 (Server Protocol Sender and Client Protocol Receiver)​

サーバーからクライアントに送信されるデータと、コマンド完了を示さないステータスレスポンスには、トークン "*" がプレフィックスとして付けられ、タグなしレスポンス (Untagged Responses) と呼ばれます。

サーバーデータは、クライアントコマンドの結果として送信される場合もあれば (してもよい)、サーバーによって一方的に送信される場合もあります (してもよい)。特定のコマンドから生じたサーバーデータと一方的に送信されたサーバーデータの間に構文上の違いはありません。

サーバー完了結果レスポンスは、操作の成功または失敗を示します。これは、操作を開始したクライアントコマンドと同じタグでタグ付けされます。したがって、複数のコマンドが進行中の場合、サーバー完了レスポンスのタグは、レスポンスが適用されるコマンドを識別します。サーバー完了レスポンスには3つの可能性があります：OK (成功を示す)、NO (失敗を示す)、または BAD (認識できないコマンドやコマンド構文エラーなどのプロトコルエラーを示す)。

サーバーがクライアントに送信するレスポンスとデータは、形式的構文 (Formal Syntax) で説明されていないコマンドタグを使用してはなりません (してはならない)。

サーバー完了結果レスポンスには、完了ステータスに関する追加情報を提供するオプションのレスポンスコード (Response Code) を含めることができます (してもよい)。レスポンスコードは、角括弧 ([...]) で囲まれたデータで構成されます。特定のレスポンスコードを理解しないクライアントは、悪影響なしにそのレスポンスコードを受け入れることができなければなりません (しなければならない)。これは、古いクライアントに問題を引き起こすことなく、任意のレスポンスコードを任意の完了レスポンスに安全に追加できることを意味します。

IMAP4rev2 クライアントのプロトコルレシーバーは、サーバーからレスポンスを読み取り、適切に処理します。

2.3 メッセージ属性 (Message Attributes)​

メッセージテキスト (Message Texts) に加えて、各メッセージにはいくつかの属性 (Attributes) が関連付けられています。これらの属性は、メッセージシーケンス番号 (Message Sequence Number) または一意識別子 (Unique Identifier, UID) によって取得できます。

2.3.1 メッセージ番号 (Message Numbers)​

メッセージには、メッセージシーケンス番号と一意識別子 (UID) の2つの形式の識別子があります。

2.3.1.1 一意識別子 (UID) メッセージ属性 (Unique Identifier (UID) Message Attribute)​

一意識別子 (Unique Identifier, UID) は、メッセージに割り当てられた 32 ビットの非ゼロ符号なし整数値です。UID の主な目的は、複数の IMAP セッション (Sessions) にわたって永続性を保つメッセージの識別子を提供することです。サーバーは、メールボックス内のすべてのメッセージに一意の UID を割り当てることを保証しなければなりません (しなければならない)。

メッセージシーケンス番号とは異なり、メッセージの UID はセッション中でも厳密に増加します (ただし、必ずしも連続しているわけではありません)。サーバーは、メールボックスに新しいメッセージが追加される場合、新しいメッセージの UID がメールボックス内の既存のメッセージの UID よりも大きいことを保証しなければなりません (しなければならない)。

UID の一意性と厳密な増加特性の例外は、UID 有効性値 (UIDVALIDITY Value) です。UIDVALIDITY 値はメールボックスに関連付けられ、メールボックスと一緒に返されます (例えば、SELECT および EXAMINE レスポンスで)。UIDVALIDITY 値は、メールボックス内の UID がリセットされたかどうかを検出するために使用されます。

UIDVALIDITY 値はゼロより大きくなければなりません (しなければならない)。UIDVALIDITY 値の主な目的は、UID の永続性を維持できない場合に保証を提供することです。例えば、次の場合、サーバーは将来のセッションで異なる UIDVALIDITY 値を使用しなければなりません (しなければならない)：

  1. メールボックスは、既存の UID に対応するメッセージがメールボックスで有効でなくなった場合、新しい UIDVALIDITY 値を割り当てなければなりません (しなければならない)。例えば、メールボックスが削除されて再作成された場合。

  2. 明確にするために：古いメールボックスが削除され、同じ名前の新しいメールボックスが作成された場合、新しいメールボックスは古いメールボックスとは異なる UIDVALIDITY 値を持たなければなりません (しなければならない)。

  3. メールボックスを、2つの IMAP サーバーが共通のメールボックスリポジトリへのアクセスを提供しない限り、UIDVALIDITY 値を変更せずに、ある IMAP サーバーから別の IMAP サーバーに移動してはなりません (してはならない)。特別なケース：サーバーは、同じ名前を保持しながら、異なる UIDVALIDITY 値を使用して、メールボックスを別のユーザーに再割り当てしてもよい (してもよい)。

  4. メールボックス名、UIDVALIDITY、および UID の組み合わせは、そのサーバー上の単一の不変の (または削除された) メッセージを永久に参照しなければなりません (しなければならない)。特に、内部日付 (Internal Date)、RFC822.SIZE、エンベロープ (Envelope)、ボディ構造 (Body Structure)、およびメッセージテキスト (すべての BODY[...] フェッチデータアイテム) は決して変更してはなりません (してはならない)。これには、メッセージシーケンス番号や、STORE コマンドで設定できる属性 (FLAGS など) は含まれません。メッセージが削除されると、その UID は同じ UIDVALIDITY 値の下で再利用してはなりません (してはならない)。

2.3.1.2 メッセージシーケンス番号メッセージ属性 (Message Sequence Number Message Attribute)​

メッセージシーケンス番号 (Message Sequence Number) は、1 からメールボックス内のメッセージ数までの相対位置です。この位置は、昇順の一意識別子で順序付けられなければなりません (しなければならない)。各新しいメッセージが追加されると、その新しいメッセージが追加される前のメールボックス内のメッセージ数より 1 大きいメッセージシーケンス番号が割り当てられます。

メッセージシーケンス番号は、セッション中に再割り当てされる可能性があります。例えば、メッセージがメールボックスから永久に削除される (expunged) と、すべての後続メッセージのメッセージシーケンス番号が減少します。メールボックス内のメッセージ数も減少します。同様に、新しいメッセージは、削除前に他のメッセージが保持していたメッセージシーケンス番号を割り当てられる可能性があります。

メールボックス内の相対位置でメッセージにアクセスすることに加えて、メッセージシーケンス番号は数学的計算にも使用できます。例えば、タグなしの "11 EXISTS" が受信され、以前にタグなしの "8 EXISTS" が受信されていた場合、メッセージシーケンス番号 9、10、11 の 3 つの新しいメッセージが到着したことになります。別の例として、523 メッセージのメールボックスのメッセージ 287 の UID が 12345 の場合、UID が小さいメッセージが正確に 286 個、UID が大きいメッセージが 236 個あります。

2.3.2 フラグメッセージ属性 (Flags Message Attribute)​

メッセージには、「フラグ」(Flags) と呼ばれる 0 個以上の名前付きトークン (Named Tokens) のリストが関連付けられています。フラグは、このリストに追加することによって設定され、削除することによってクリアされます。IMAP4rev2 には 2 種類のフラグがあります：システムフラグ (System Flags) とキーワード (Keywords)。どちらのタイプのフラグも、永続的またはセッションのみにすることができます。

システムフラグは、この仕様で事前定義され、"" で始まるフラグ名です。特定のシステムフラグ (\Deleted および \Seen) には、このドキュメントの他の場所で説明されている特別なセマンティクスがあります。現在定義されているシステムフラグは次のとおりです：

  • \Seen - メッセージは読まれました
  • \Answered - メッセージは返信されました
  • \Flagged - メッセージは緊急/特別な注意のために「フラグ付き」です
  • \Deleted - メッセージは後の EXPUNGE による削除のために「削除済み」としてマークされています
  • \Draft - メッセージは作成を完了していません (下書きとしてマークされています)
  • \Recent - このフラグは IMAP4rev1 で使用されていましたが、現在は非推奨です

キーワード (Keyword) はサーバー実装によって定義されます。キーワードは "" で始まりません。サーバーは、クライアントがメールボックスで新しいキーワードを定義することを許可してもよい (してもよい) (詳細については、PERMANENTFLAGS レスポンスコードの説明を参照してください)。"$" で始まるいくつかのキーワードもこの仕様で定義されています。

このドキュメントでは、[RFC3501] で最初に定義されていませんでしたが、クライアント実装によって有用であることがわかったいくつかのキーワードを定義しています。これらのキーワードは、サーバー実装によってサポートされるべきです (すべきである) (SEARCH で許可され、APPEND、COPY、および MOVE コマンドで許可および保持されます)：

$Forwarded
メッセージは、新しいメッセージに埋め込まれるか、添付されることによって、別の電子メールアドレスに転送されました。電子メールクライアントは、メッセージを別の電子メールアドレスに正常に転送したときに、このキーワードを設定します。このキーワードの典型的な使用法は、転送されたメッセージに対して異なる (または追加の) アイコンを表示することです。設定されると、フラグはクリアされるべきではありません (すべきでない)。

$MDNSent
このメッセージに対してメッセージ処理通知 (Message Disposition Notification) [RFC8098] が生成され、送信されました。このキーワードの使用方法とクライアントおよびサーバーの要件の詳細については、[RFC3503] を参照してください。

$Junk
ユーザー (またはユーザーに代わって配信エージェント) は、メッセージを確実にジャンクを含むものとしてマークすることを選択できます ($Junk。関連キーワード $NotJunk も参照してください)。$Junk キーワードは、望ましくないメッセージをマーク、グループ化、または非表示にするために使用できます (そのようなメッセージは後で移動または削除される可能性があります)。詳細については、[IMAP-KEYWORDS-REG] を参照してください。

$NotJunk
ユーザー (またはユーザーに代わって配信エージェント) は、メッセージを確実にジャンクを含まないものとしてマークすることを選択できます ($NotJunk。関連キーワード $Junk も参照してください)。$NotJunk キーワードは、ユーザーが見たいメッセージをマーク、グループ化、または表示するために使用できます。詳細については、[IMAP-KEYWORDS-REG] を参照してください。

$Phishing
$Phishing キーワードは、配信エージェントによって、メッセージがフィッシング電子メールである可能性が非常に高いことをマークするために使用できます。配信エージェントによってフィッシング電子メールと判断されたメッセージは、ジャンク電子メールとも見なされ、$Junk フラグの設定やメッセージを \Junk 特殊用途メールボックス (セクション 7.3.1 を参照、利用可能な場合) に配置するなど、適切なジャンクフィルタリングが適用されるべきです (すべきである)。

$Phishing フラグと $Junk フラグの両方が設定されている場合、ユーザーエージェントはユーザーに追加の警告メッセージを表示すべきです (すべきである)。さらに、ユーザーがメッセージ内のハイパーリンクをクリックしたときに、ユーザーエージェントは「このメッセージは個人情報を盗もうとしている可能性があります」などの形式の警告を表示する可能性があります。

ユーザーエージェントが警告を表示する前に $Phishing と $Junk の両方が設定されていることを要求するのは、$Junk フラグは理解するが $Phishing フラグは理解しない既存のクライアントとのより良い下位互換性のためです。これは、拡張されていないクライアントが $Junk フラグを削除したときに、拡張されたクライアントも正しい状態を表示するようにするためです。詳細については、[IMAP-KEYWORDS-REG] を参照してください。

$Junk と $NotJunk は相互に排他的です。メッセージに対してこれらの複数が設定されている場合、クライアントは何も設定されていないかのように扱わなければならず (しなければならない)、IMAP サーバー上で両方の設定を解除すべきです (すべきである)。

その他の登録されたキーワードは、「IMAP および JMAP キーワード」レジストリ [IMAP-KEYWORDS-REG] で見つけることができます。新しいキーワードは、[RFC5788] で指定された手順を使用してこのレジストリに登録されるべきです (すべきである)。

フラグは、フラグごとに永続的またはセッションのみにすることができます。永続フラグ (Permanent Flags) は、クライアントがメッセージフラグから永続的に追加または削除できるフラグです。つまり、同時実行および後続のセッションは、永続フラグへの変更を確認します。セッションフラグ (Session Flags) への変更は、そのセッションでのみ有効です。

2.3.3 内部日付メッセージ属性 (Internal Date Message Attribute)​

内部日付 (Internal Date) メッセージ属性は、サーバー上のメッセージの内部日付と時刻です。これは [RFC5322] ヘッダーの日付と時刻ではなく、メッセージが受信された日時を反映する日付と時刻です。[SMTP] 経由で配信されたメッセージの場合、これは [SMTP] で定義されたメッセージの最終配信の日付と時刻です。IMAP4rev2 COPY または APPEND コマンドによって作成されたメッセージの場合、これはそれらのコマンドで指定された日付と時刻です。

2.3.4 RFC822.SIZE メッセージ属性 (RFC822.SIZE Message Attribute)​

RFC822.SIZE は、メッセージが [RFC5322] 形式で表現されたときのメッセージのオクテット数です。このサイズは、"FETCH BODY[]" コマンドの結果と一致すべきです (すべきである)。メッセージが内部的に他の形式で保存されている場合、サーバーはサイズを計算し、再計算の必要性を避けるために後で使用するためにそれを保存することがよくあります。

2.3.5 エンベロープ構造メッセージ属性 (Envelope Structure Message Attribute)​

エンベロープ構造 (Envelope Structure) は、メッセージの [RFC5322] ヘッダーの解析表現です。IMAP エンベロープ構造は [SMTP] エンベロープと同じではないことに注意してください。

2.3.6 ボディ構造メッセージ属性 (Body Structure Message Attribute)​

ボディ構造 (Body Structure) は、メッセージの [MIME-IMB] ボディ構造情報の解析表現です。

2.4 メッセージテキスト (Message Texts)​

メッセージの完全な [RFC5322] テキストをフェッチできることに加えて、IMAP4rev2 は完全なメッセージテキストの一部をフェッチすることを許可します。具体的には、[RFC5322] メッセージヘッダー (Message Header)、[RFC5322] メッセージボディ (Message Body)、[MIME-IMB] ボディパート (Body Part)、または [MIME-IMB] ヘッダーをフェッチすることが可能です。