IMAP4をより使いやすくする拡張機能：モバイル環境に優しいメールプロトコルIMAP（2）

» 2002年03月23日 00時00分公開

[日比野洋克，オレンジソフト]

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

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

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

※以下、便宜上“C：”で始まる行はクライアントが発行したコマンド、“S：”で始まる行はサーバからのレスポンスを意味します（注：実際のコマンドやレスポンスには“S：”、“C：”は付いていません）。

(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

例4：Literalの例（「1234567890」という文字列を表現しています）

※本当はもっと細かいルールがあるのですが、レスポンスを解析するのであれば、これで十分だと思います。

　以上で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と同列の“オーナー名”の下に配置されます。

図1　UW IMAP ServerとCyrus IMAPのメールボックスの階層構造の違い

　階層構造が規定されていないことで、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拡張

※上記の3拡張はすでにRFCになっているものですが、LANGUAGE拡張はまだドラフトの段階なので、仕様が変わる可能性があります。

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