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

5. 運用上の考慮事項 (Operational Considerations)

すべての IMAP4rev2 実装が適切に相互運用できるようにするために、以下のルールがここにリストされています。

5.1 メールボックスの命名 (Mailbox Naming)​

IMAP4rev2 では、メールボックス名は Net-Unicode [NET-UNICODE] でエンコードされます (これは IMAP4rev1 とは異なります)。クライアント実装は Net-Unicode メールボックス名を作成しようとしてもよく (してもよく)、LIST によって返される 8 ビットメールボックス名を [NET-UNICODE] として解釈しなければなりません (しなければなりません)。サーバー実装は、Net-Unicode に準拠していない 8 ビットメールボックス名の作成を禁止しなければなりません (しなければなりません)。ただし、サーバーは非正規化 UTF-8 メールボックス名を受け入れ、メールボックス作成前に (Net-Unicode 要件に従って) Unicode 正規化形式 C (NFC) に変換してもよい (してもよい)。このような非正規化 UTF-8 メールボックス名を受け入れることを選択したサーバーは、メールボックス名パラメータを持つすべての IMAP コマンドでそれらを受け入れなければなりません (しなければなりません)。特に、SELECT <name> は、<name> が非正規化 UTF-8 メールボックス名であっても、CREATE <name> で正常に作成されたのと同じメールボックスを開かなければなりません。

大文字小文字を区別しないメールボックス名 INBOX は、「このサーバー上のこのユーザーのプライマリメールボックス」を意味するために予約された特別な名前です。(この特別な名前は、一部のサーバーの一部のユーザーには存在しない場合があることに注意してください。たとえば、ユーザーが個人名前空間へのアクセス権を持たない場合。) 他のすべての名前の解釈は実装依存です。

特に、この仕様は非 INBOX メールボックス名の大文字小文字の区別について立場を取りません。一部のサーバー実装は ASCII 範囲で完全に大文字小文字を区別します。他のサーバーは新しく作成された名前の大文字小文字を保持しますが、それ以外では大文字小文字を区別しません。さらに他のサーバーは名前を特定の大文字小文字に強制します。クライアント実装は、これらのいずれとも対話できなければなりません。

新しいメールボックス名を作成する際には、特定のクライアント考慮事項があります：

  1. atom-specials の 1 つである任意の文字 (セクション 9 の「正式な構文」を参照) は、メールボックス名が引用文字列またはリテラルとして表現されることを要求します。

  2. CTL およびその他の非グラフィック文字は、ユーザーインターフェイスで表現するのが難しく、避けるのが最善です。サーバーは Unicode CTL 文字を含むメールボックス名の作成を拒否してもよい (してもよい)。

  3. リストワイルドカード文字 ("%" および "*") はメールボックス名で有効ですが、ワイルドカード解釈との競合のため、LIST コマンドでこのようなメールボックス名を使用するのは困難です。

  4. 通常、1 つの文字 (サーバー実装によって決定される) が階層レベルを区切るために予約されています。

  5. 慣例により、2 つの文字 "#" および "&" には意味があり、その慣例で使用される場合を除いて避けるべきです。それぞれセクション 5.1.2.1 および付録 A.1 を参照してください。

5.1.1 メールボックス階層の命名 (Mailbox Hierarchy Naming)​

階層的なメールボックス名をエクスポートすることが望ましい場合、メールボックス名は左から右への階層でなければならず (しなければならず)、単一の ASCII 文字を使用して階層レベルを区切ります。単一の名前内のすべての階層レベルに同じ階層セパレータ文字が使用されます。

5.1.2 名前空間 (Namespaces)​

個人名前空間 (Personal Namespace): サーバーが特定の接続で認証されたユーザーの個人スコープ内にあると見なす名前空間。通常、認証されたユーザーのみが個人名前空間内のメールボックスにアクセスできます。これは、ユーザーに属し、メールボックスに割り当てられる名前空間の一部です。ユーザーに INBOX が存在する場合、ユーザーの個人名前空間内に表示されなければなりません (しなければなりません)。通常のケースでは、サーバー上のユーザーごとに 1 つの個人名前空間のみがあるべきです (あるべきです)。

他のユーザーの名前空間 (Other Users' Namespace): 他のユーザーの個人名前空間からのメールボックスで構成される名前空間。他のユーザーの名前空間内のメールボックスにアクセスするには、現在認証されているユーザーに明示的にアクセス権が付与されなければなりません (しなければなりません)。たとえば、マネージャーが管理サポートスタッフに自分のメールボックスへのアクセス権を付与することは一般的です。通常のケースでは、サーバー上のユーザーごとに 1 つの他のユーザーの名前空間のみがあるべきです (あるべきです)。

共有名前空間 (Shared Namespace): ユーザー間で共有されることを意図しており、ユーザーの個人名前空間内には存在しないメールボックスで構成される名前空間。

サーバーが使用する名前空間は、ユーザーごとに異なる場合があります (してもよい)。

5.1.2.1 歴史的メールボックス名前空間の命名規則 (Historic Mailbox Namespace Naming Convention)​

慣例により、"#" で始まる任意のメールボックス名の最初の階層要素は、名前の残りの部分の「名前空間」を識別します。これにより、それぞれが独自の名前空間を持つ異なるタイプのメールボックスストア間の曖昧さを解消できます。

たとえば、USENET ニュースグループへのアクセスを提供する実装は、"#news" 名前空間を使用して USENET ニュースグループ名前空間を他のメールボックスの名前空間から分割してもよい (してもよい)。したがって、comp.mail.misc ニュースグループは "#news.comp.mail.misc" のメールボックス名を持ち、名前 "comp.mail.misc" は異なるオブジェクト (たとえば、ユーザーのプライベートメールボックス) を参照できます。

"#" 文字を含む名前空間は IMAP URL [IMAP-URL] フレンドリーではなく、URL 内では "#" 文字を %23 として表現する必要があります。そのため、サーバー実装者は代わりに "#" 文字を含まない名前空間プレフィックスの使用を検討してもよい (してもよい)。

5.1.2.2 一般的な名前空間モデル (Common Namespace Models)​

このプロトコルの以前のバージョンでは、デフォルトのサーバー名前空間は定義されていませんでした。2 つの一般的な名前空間モデルが進化しました：

「個人メールボックス」(Personal Mailbox) モデルは、提示されるデフォルトの名前空間がユーザーの個人メールボックスのみで構成されるものです。共有メールボックスにアクセスするには、ユーザーはエスケープメカニズムを使用して別の名前空間に到達する必要があります。

「完全階層」(Complete Hierarchy) モデルは、提示されるデフォルトの名前空間にユーザーの個人メールボックスとアクセス権を持つ他のメールボックスが含まれるものです。

5.2 メールボックスサイズとメッセージステータスの更新 (Mailbox Size and Message Status Updates)​

サーバーはいつでも、クライアントが要求していないデータを送信できます。この仕様および/または拡張によってこのような動作が要求される場合があります。たとえば、サーバー以外のエージェントがメールボックスにメッセージを追加したり (新しいメッセージの配信など)、メールボックス内のメッセージのフラグを変更したり (複数のエージェントによる同じメールボックスへの同時アクセスなど)、メールボックスからメッセージを削除したりする場合があります。コマンドの処理中にメールボックスサイズの変更が観察された場合、サーバーはメールボックスサイズの更新を自動的に送信しなければなりません (しなければなりません)。サーバーは、クライアントがそのような更新を明示的に要求することなく、メッセージフラグの更新を自動的に送信すべきです (すべきです)。

同期エラーを防ぐために、メッセージの削除に関するサーバーのクライアントへの通知には特別なルールがあります。詳細については、EXPUNGE レスポンスの説明 (セクション 7.5.1) を参照してください。特に、メールボックス内のメッセージ数を減らす EXISTS レスポンスを送信することは許可されていません。これを実行できるのは EXPUNGE レスポンスのみです。

クライアントがサーバーからのデータを記憶することに関してどのような実装上の決定を行うかに関係なく、クライアント実装はメールボックスサイズの更新を記憶しなければなりません (しなければなりません)。初期メールボックス選択後のコマンドがメールボックスのサイズを返すと仮定してはなりません (してはなりません)。

5.3 コマンドが進行中でない場合の応答 (Response When No Command in Progress)​

サーバー実装は、コマンドが進行中でない場合にタグなしレスポンス (EXPUNGE を除く) を送信することが許可されています。このようなレスポンスを送信するサーバー実装は、フロー制御の考慮事項に対処しなければなりません (しなければなりません)。具体的には、(1) データのサイズが基礎となるトランスポートの利用可能なウィンドウサイズを超えないことを確認するか、(2) 非ブロッキング書き込みを使用するかのいずれかを行わなければなりません (しなければなりません)。

5.4 自動ログアウトタイマー (Autologout Timer)​

サーバーが認証後のセッションに適用される非アクティブ自動ログアウトタイマーを持っている場合、そのタイマーの期間は少なくとも 30 分でなければなりません (しなければなりません)。その間隔中にクライアントから任意のコマンドを受信すると、自動ログアウトタイマーがリセットされます。

この仕様には、クライアント認証が成功する前に使用される自動ログアウトタイマーに関する制限はないことに注意してください。特に、サーバーはサービス拒否攻撃から身を守るために短縮された認証前タイマーを使用することが許可されています。

5.5 進行中の複数のコマンド (コマンドパイプライン化) (Multiple Commands in Progress / Command Pipelining)​

クライアントは、曖昧さルール (下記参照) および基礎となるデータストリームのフロー制御制約に従って、コマンドの完了結果レスポンスを待たずに別のコマンドを送信してもよい (してもよい)。同様に、サーバーは、曖昧さルールに従って、現在のコマンドを完了まで処理する前に別のコマンドの処理を開始してもよい (してもよい)。ただし、任意のコマンド継続要求レスポンスおよびコマンド継続は、後続のコマンドが開始される前にネゴシエートされなければなりません (しなければなりません)。

例外は、他のコマンドの結果に影響を与えるコマンドのために曖昧さが生じる場合です。サーバーが可能性のある曖昧さを検出した場合、クライアントが指定した順序でコマンドを完了まで実行しなければなりません (しなければなりません)。

曖昧さの最も明白な例は、あるコマンドが別のコマンドの結果に影響を与える場合です。1 つの例は、\Seen フラグを設定する FETCH と SEARCH UNSEEN コマンドです。

タグなし EXPUNGE レスポンスを許可するコマンド (FETCH、STORE、および SEARCH 以外のコマンド) では、タグなし EXPUNGE レスポンスが後続のコマンドのシーケンス番号を無効にする可能性があるため、明白でない曖昧さが発生します。FETCH、STORE、または SEARCH コマンドについては、これらのコマンドのいずれかが進行中の間、サーバーが EXPUNGE レスポンスを送信することが禁止されているため、これは問題ではありません。したがって、クライアントが FETCH、STORE、または SEARCH 以外のコマンドを送信する場合、メッセージシーケンス番号を含むコマンドを送信する前に完了結果レスポンスを待たなければなりません (しなければなりません)。

注意：UID FETCH、UID STORE、および UID SEARCH が進行中の間、EXPUNGE レスポンスが許可されます。クライアントが UID コマンドを送信する場合、メッセージシーケンス番号を使用するコマンド (これには UID SEARCH が含まれる可能性がある) を送信する前に完了結果レスポンスを待たなければなりません (しなければなりません)。UID SEARCH への引数内の任意のメッセージシーケンス番号は、UID SEARCH によって返される任意のタグなし EXPUNGE レスポンスの効果より前のメッセージに関連付けられます。

たとえば、以下の非待機コマンドシーケンスは無効です：

に最終更新