前回は、IMAP4でできることと、できないことをまとめ、実際の活用例をご紹介しました。IMAP4には、メッセージアクセスのための豊富な機能が用意されていますが、それでも足りない機能があります。これらをフォローするために多くの拡張機能が提供されています。今回は、そのIMAP4の拡張機能について解説したいと思います。
IMAP4のコマンドとレスポンス
IMAP4の拡張プロトコルについて説明する前に、IMAP4のコマンドとレスポンスの書式を簡単に説明しておきましょう。IMAP4のコマンドの特徴は、おおよそ以下に挙げる5つです。
(1)テキストベースで行志向
基本的にIMAP4のコマンドとレスポンスは、CRLF（改行）を終端としたテキストベース、行志向のプロトコルです。従って、telnetなどを用いて簡単に動作を確認することが可能です。基本的にと断りがあるのは、改行を含んだ文字列が含まれる場合、行の中に文字列中のCRLFが含まれることがあり、結果として複数行になることがあるからです。
| C： | A001 LOGIN user password |
|---|---|
| S： | A001 OK User login |
| 例1 IMAPのコマンドとレスポンスの基本形 | |
(2)タグによるコマンドとレスポンスの対応付け
IMAP4では、非同期にコマンドを発行することが可能です。そのため、サーバから返ってきたレスポンスがどのコマンドに対応するかを判別することが必要になります。そこで、IMAP4ではタグと呼ぶ識別子を用います。コマンドとレスポンスの双方に同一のタグを付けることで、コマンドとレスポンスの対応付けを可能としています。また、応答が複数行になる場合は、最終行にだけタグを付け、それ以外の行は“*”を先頭に付けるようにします（タグなし応答）。
| C： | A001 COPY 1 SAMPLE |
←タグは“A001” |
|---|---|---|
| C： | A002 STORE 1 +FLAGS (\Flagged) |
←タグは“A002” |
| S： | A002 OK STORE completed |
←A002 STOREコマンドの成功応答 |
| S： | A001 NO SAMPLE not found |
←A001 COPYコマンドの失敗応答 |
| 例2 タグの付いたコマンドとレスポンス | ||
| C： | A003 SELECT inbox |
|---|---|
| S： | * FLAGS (\Answered \Flagged \Draft \Deleted \Seen UNSEEN) |
| S： | * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen UNSEEN \*)] |
| S： | * 4917 EXISTS |
| S： | * 2 RECENT |
| S： | * OK [UNSEEN 4913] |
| S： | * OK [UIDVALIDITY 948696898] |
| S： | A003 OK [READ-WRITE] Completed |
| 例3：タグなし応答の例（SELECTコマンドの応答で6個のタグなし応答があります） | |
(3)カッコ付きリストによる集合の表現
(4)字句の区切りにはスペースを用いる
基本的に、IMAP4の字句はスペースで区切られます。IMAP4の文法は非常に厳格で、スペース1個とスペース2個では意味が変わってしまいますので注意が必要です。また、可変個の字句の集合を表現するときは、カッコ付きリストといって“（”と“）”で字句を囲み、スペース区切りで配置します。また、カッコ付きリストはネストすることが可能です。そのため、IMAP4の応答はカッコだらけの少し分かりにくいものになっています。秀丸エディタのようなカッコの対応が分かるエディタを用いると、解析が楽になりますのでお試しください。
例3のサーバからの1つめのレスポンスを上のルールで字句に分解してみると、次のようになります。
*
スペース
FLAGS
スペース
カッコ付リスト
（リストの要素は、'\Answered'、'\Flagged'、'\Draft'、'\Deleted'、'\Seen'、'UNSEEN'）
(5)2種類の文字列表現
IMAP4では、文字列として「Literal」と「Quoted」という2種類の表現形式を持っています。Quotedは、
"String"
のように"（ダブルクォーテーション）で囲む形式です。Quotedではメール本文のような改行を含む文字列を表現できないので、それに対応する形式としてLiteralが用意されています。Literalは、
{文字数}CRLF 実際の文字列
という形式です。また、Literalでは文字列以外にバイナリデータも扱うことが可能です。以下に例を示します。
{12}CRLF
12345
67890
以上でIMAP4のコマンド／レスポンスを読む準備ができました。では、実際の拡張プロトコルを見てみましょう。
IMAP4の拡張プロトコル
IMAP4には、機能を拡張するための多くの拡張プロトコルが存在します。今回はその中から、実際の運用において便利なものをいくつかを紹介します。
CAPABILITY
ところで、クライアントは、IMAP4サーバがどの拡張プロトコルをサポートしているかをどうやって知るのでしょうか。実は、IMAP4にはサーバがサポートしている機能をクライアントに通知するコマンド（CAPABILITY）が用意されているのです。実際にCAPABILITYコマンドを実行した例を下に示します。
| C： | tag CAPABILITY |
|---|---|
| S： | * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS LANGUAGE XSENDER X-NETSCAPE XSERVERINFO AUTH=PLAIN AUTH=LOGIN |
| S： | tag OK Completed |
| 例5 サーバーがサポートする機能を取得する | |
“*”で始まるレスポンスに、CAPABILITYコマンドによって通知されたサーバの機能が羅列されています。具体的には、このサーバは表1のような機能をサポートしています。
| 対応しているIMAPのバージョン | |
|---|---|
| IMAP4 | RFC1733 DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4 |
| IMAP4rev1 | RFC2060 INTERNET MESSAGE ACCESS PROTOCOL |
| 拡張仕様 | |
| ACL | RFC2086 IMAP4 ACL extension |
| QUOTA | RFC2087 IMAP4 QUOTA extension |
| LITERAL+ | RFC2088 IMAP4 non-synchronizing literals |
| NAMESPACE | RFC2342 IMAP4 Namespace |
| UIDPLUS | RFC2359 IMAP4 UIDPLUS extension |
| LANGUAGE | draft IMAP4 Language Extension(draft) |
| 表1 例5のレスポンスから分かるサーバの機能 | |
なお、Xで始まる文字列は、おなじみだと思いますがサーバ独自の拡張を示しています。また、最後の2つの“AUTH=PLAIN”と“AUTH=LOGIN”は認証で用いるメカニズムを示しています。このサーバは、PLAIN形式（パスワードを平文で渡す）とLOGIN形式（パスワードをBase64でエンコードして渡す）をサポートしています。なお、認証メカニズムについては、RFC2195（IMAP4/POP AUTHorize Extension for Simple Challenge/Response）などで記述されています。
ACL拡張
ACL拡張は、メールボックスのアクセス権を設定／確認するためのプロトコルです。ACL拡張はメールボックスのアクセス権として以下の権限（一部）を用意しています。ACL拡張により、メールボックスを他者に読み込み専用で公開したりすることができます。なお、公開したメールボックスが、ユーザーにどのような階層構造で見えるかはACL拡張では規定されていません。それはNAMESPACE拡張によって規定されています。
| l（lookup） | メールボックスが見える（メールボックス一覧に表示される） |
|---|---|
| r（read） | メールボックスの内容を読むことができる |
| s（keep seen/unseen） | 未読・既読を設定できる |
| w（write） | 未読管理と削除以外のフラグの設定ができる |
| i（insert） | メールを書き込むことができる（コピーなど） |
| c（create） | 子メールボックスを作ることができる |
| d（delete） | メールを削除することができる |
| 表2 メールボックスのアクセス権限 | |
コマンドの詳細はRFCを読んでいただくとして、コマンドの例を以下に示します。
| C： | tag1 GETACL "mbox" |
|---|---|
| S： | * ACL Sent nonki lrswipcda |
| S： | tag1 OK Completed |
| 例6 メールボックス“mbox”のACLを取得する | |
| C： | tag2 SETACL "mbox" "hibino" lr |
|---|---|
| S： | tag2 OK Completed |
| 例7 ユーザー“hibino”にメールボックス“mbox”の読み込み権を与える | |
NAMESPACE拡張
IMAP4は、メールボックスの階層構造を規定していません。従ってサーバによって階層構造はまちまちになっています。例えばUWでは、inboxと同列に自身のメールボックスが並び、共有メールボックスは、#sharedの下に配置されます。Cyrusでは、inboxの下に自身のメールボックスが配置され、共有メールボックスは、inboxと同列の“オーナー名”の下に配置されます。
階層構造が規定されていないことで、IMAPは柔軟な階層構造を実現することができますが、クライアント（ユーザー）は「自身のメールボックス」「他人のメールボックス」「共有メールボックス」がどこに配置されるかを知らないと、メールボックスを作成することすらできません。NAMESPACE拡張は、この階層構造を知るためのプロトコルです。NAMESPACE拡張では、メールボックスの階層構造を「個人（Personal）」「他者（Other Users）」「共有（Shared）」の3種の名前空間（NAMESPACE）に分け、それぞれの名前空間のトップとなる位置とセパレータをクライアントに返します。
| C： | tag NAMESPACE |
|---|---|
| S： | * NAMESPACE (("" "/")) (("Shared Folders/User/" "/")) NIL |
| S： | tag OK Completed |
| 例8 個人名前空間はトップから始まり、セパレーターは“/”、他者名前空間は“Shared Folders/User/”から始まり、セパレーターは“/”、共有名前空間はない（NIL) | |
| C： | tag NAMESPACE |
|---|---|
| S： | * NAMESPACE (("inbox." ".")) (("User." ".")) ("Shared/" "/") |
| S： | tag OK Completed |
| 例9 個人名前空間は“inbox”から始まり、セパレーターは“.”、他者名前空間は“User”から始まり、セパレーターは"."、共有名前空間は“Shared”から始まり、セパレータは“/” | |
QUOTA拡張
QUOTA拡張は、IMAPサーバに格納できるメッセージの全体のサイズを制限するための仕様です。ユーザーごとにQUOTAのサイズは変更できますので、例えばサイズによって利用課金を設定するようなこともできるでしょう。また、QUOTAにより全体のメッセージストアの大きさを見積もることができますので、サーバのストレージサイズの見積もりにも役に立ちます。QUOTAは、基本的に管理者が設定するものなので、クライアント（メーラー）では実装されることは少ないと思います。
LANGUAGE拡張
IMAP4だけでなく、ほとんどのプロトコルではエラーメッセージなどは英語で記述されています。母国語が英語の人々にとっては問題ありませんが、母国語が英語でない人々にとっては、エラーメッセージなどが自分の母国語で表示されれば、分かりやすく、結果ユーザーサポートの手間が減ることが期待できます。LANGUAGE拡張は、メッセージを各国語に変更するための仕様です。例えば日本語を使いたいときは、
| C： | TAG LANGUAGE JA |
|---|---|
| S： | TAG OK 日本語に変更しました。 |
| 例10 メッセージを日本語に変更する（文字コードはUTF-8） | |
とします。メッセージの文字コードはUTF-8です。ちなみに同様の考え方で、SMTPでもLANGUAGE拡張が提案されています（SMTP Language Extension）。
今回はここまでにします。次回は、少しサーバ側の話題に飛び、Cyrus IMAPサーバのインストールについて説明する予定です。
Copyright © ITmedia, Inc. All Rights Reserved.