今回のおもな内容 IMAP4のコマンドとレスポンス IMAP4の拡張プロトコル CAPABILITY／ACL拡張 NAMESPACE拡張／QUOTA拡張 LANGUAGE拡張

　前回は、IMAP4でできることと、できないことをまとめ、実際の活用例をご紹介しました。IMAP4には、メッセージアクセスのための豊富な機能が用意されていますが、それでも足りない機能があります。これらをフォローするために多くの拡張機能が提供されています。今回は、そのIMAP4の拡張機能について解説したいと思います。

IMAP4のコマンドとレスポンス

　IMAP4の拡張プロトコルについて説明する前に、IMAP4のコマンドとレスポンスの書式を簡単に説明しておきましょう。IMAP4のコマンドの特徴は、おおよそ以下に挙げる5つです。

　基本的にIMAP4のコマンドとレスポンスは、CRLF（改行）を終端としたテキストベース、行志向のプロトコルです。従って、telnetなどを用いて簡単に動作を確認することが可能です。基本的にと断りがあるのは、改行を含んだ文字列が含まれる場合、行の中に文字列中のCRLFが含まれることがあり、結果として複数行になることがあるからです。

　IMAP4では、非同期にコマンドを発行することが可能です。そのため、サーバから返ってきたレスポンスがどのコマンドに対応するかを判別することが必要になります。そこで、IMAP4ではタグと呼ぶ識別子を用います。コマンドとレスポンスの双方に同一のタグを付けることで、コマンドとレスポンスの対応付けを可能としています。また、応答が複数行になる場合は、最終行にだけタグを付け、それ以外の行は“*”を先頭に付けるようにします（タグなし応答）。

　基本的に、IMAP4の字句はスペースで区切られます。IMAP4の文法は非常に厳格で、スペース1個とスペース2個では意味が変わってしまいますので注意が必要です。また、可変個の字句の集合を表現するときは、カッコ付きリストといって“（”と“）”で字句を囲み、スペース区切りで配置します。また、カッコ付きリストはネストすることが可能です。そのため、IMAP4の応答はカッコだらけの少し分かりにくいものになっています。秀丸エディタのようなカッコの対応が分かるエディタを用いると、解析が楽になりますのでお試しください。

　例3のサーバからの1つめのレスポンスを上のルールで字句に分解してみると、次のようになります。

　IMAP4では、文字列として「Literal」と「Quoted」という2種類の表現形式を持っています。Quotedは、

のように"（ダブルクォーテーション）で囲む形式です。Quotedではメール本文のような改行を含む文字列を表現できないので、それに対応する形式としてLiteralが用意されています。Literalは、

という形式です。また、Literalでは文字列以外にバイナリデータも扱うことが可能です。以下に例を示します。

　以上でIMAP4のコマンド／レスポンスを読む準備ができました。では、実際の拡張プロトコルを見てみましょう。

IMAP4の拡張プロトコル

　IMAP4には、機能を拡張するための多くの拡張プロトコルが存在します。今回はその中から、実際の運用において便利なものをいくつかを紹介します。

　ところで、クライアントは、IMAP4サーバがどの拡張プロトコルをサポートしているかをどうやって知るのでしょうか。実は、IMAP4にはサーバがサポートしている機能をクライアントに通知するコマンド（CAPABILITY）が用意されているのです。実際にCAPABILITYコマンドを実行した例を下に示します。

　“*”で始まるレスポンスに、CAPABILITYコマンドによって通知されたサーバの機能が羅列されています。具体的には、このサーバは表1のような機能をサポートしています。

　なお、Xで始まる文字列は、おなじみだと思いますがサーバ独自の拡張を示しています。また、最後の2つの“AUTH=PLAIN”と“AUTH=LOGIN”は認証で用いるメカニズムを示しています。このサーバは、PLAIN形式（パスワードを平文で渡す）とLOGIN形式（パスワードをBase64でエンコードして渡す）をサポートしています。なお、認証メカニズムについては、RFC2195（IMAP4/POP AUTHorize Extension for Simple Challenge/Response）などで記述されています。

　ACL拡張は、メールボックスのアクセス権を設定／確認するためのプロトコルです。ACL拡張はメールボックスのアクセス権として以下の権限（一部）を用意しています。ACL拡張により、メールボックスを他者に読み込み専用で公開したりすることができます。なお、公開したメールボックスが、ユーザーにどのような階層構造で見えるかはACL拡張では規定されていません。それはNAMESPACE拡張によって規定されています。

　コマンドの詳細はRFCを読んでいただくとして、コマンドの例を以下に示します。

　IMAP4は、メールボックスの階層構造を規定していません。従ってサーバによって階層構造はまちまちになっています。例えばUWでは、inboxと同列に自身のメールボックスが並び、共有メールボックスは、#sharedの下に配置されます。Cyrusでは、inboxの下に自身のメールボックスが配置され、共有メールボックスは、inboxと同列の“オーナー名”の下に配置されます。

　階層構造が規定されていないことで、IMAPは柔軟な階層構造を実現することができますが、クライアント（ユーザー）は「自身のメールボックス」「他人のメールボックス」「共有メールボックス」がどこに配置されるかを知らないと、メールボックスを作成することすらできません。NAMESPACE拡張は、この階層構造を知るためのプロトコルです。NAMESPACE拡張では、メールボックスの階層構造を「個人（Personal）」「他者（Other Users）」「共有（Shared）」の3種の名前空間（NAMESPACE）に分け、それぞれの名前空間のトップとなる位置とセパレータをクライアントに返します。

　QUOTA拡張は、IMAPサーバに格納できるメッセージの全体のサイズを制限するための仕様です。ユーザーごとにQUOTAのサイズは変更できますので、例えばサイズによって利用課金を設定するようなこともできるでしょう。また、QUOTAにより全体のメッセージストアの大きさを見積もることができますので、サーバのストレージサイズの見積もりにも役に立ちます。QUOTAは、基本的に管理者が設定するものなので、クライアント（メーラー）では実装されることは少ないと思います。

　IMAP4だけでなく、ほとんどのプロトコルではエラーメッセージなどは英語で記述されています。母国語が英語の人々にとっては問題ありませんが、母国語が英語でない人々にとっては、エラーメッセージなどが自分の母国語で表示されれば、分かりやすく、結果ユーザーサポートの手間が減ることが期待できます。LANGUAGE拡張は、メッセージを各国語に変更するための仕様です。例えば日本語を使いたいときは、

とします。メッセージの文字コードはUTF-8です。ちなみに同様の考え方で、SMTPでもLANGUAGE拡張が提案されています（SMTP Language Extension）。

　今回はここまでにします。次回は、少しサーバ側の話題に飛び、Cyrus IMAPサーバのインストールについて説明する予定です。

「連載 モバイル環境に優しいメールプロトコルIMAP」