連載：インターネット・プロトコル詳説（8）
IMAP4（Internet Mail Access Protocol version 4）〜前編

梁瀬介次
2001/6/13

■いまも進化を続けるIMAP4

1986年 スタンフォード大学で最初のIMAPの原型が考案される 1988年 最初のRFCとなるRFC1064が発表される（IMAP2）。複数メールボックス／タグ／フラグなどはこの頃から仕様に含められている 1994年 最初のIMAP4仕様が、RFC1730として発表される 1995年 現在でも最も標準的なIMAP4サーバの1つであるワシントン大学IMAP4サーバ（UW IMAP）の開発が始まる 1997年 IMAP4rev1がRFC2060としてまとまる 2000年 IETFでIMAP4 Extentionワーキンググループが始まる。現実的に明らかになってきたIMAP4の問題点整理や高機能化を目的としている

表1　IMAP4の歴史年表

　前回説明したPOP3と同じく、IMAP4はメールサーバ上のメールボックスからメールを取得するためのプロトコルだ。ポート番号は一般に143が用いられる。

　目的が同じとはいえ、POP3とはその機能からプロトコル内容まで大きく異なっている。一言でいえば、POP3に比べ大変複雑で多くの機能が追加されたものだ。根本的な考え方から大きく異なっているのだ。これは、POP3が抱えていた大きな問題点への反省のもと、IMAP4が成り立ったことに由来する。

RFC2060 "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4 rev1" RFC2342 "IMAP4 Namespace" RFC2088 "IMAP4 non-synchronizing literals" RFC2177 "IMAP4 IDLE command" RFC2087 "IMAP4 QUOTA extension" RFC2193 "IMAP4 Mailbox Referrals" RFC2221 "IMAP4 Login Referrals" RFC2359 "IMAP4 UIDPLUS extension" RFC2683 "IMAP4 Implementation Recommendations" RFC2192 "IMAP URL Scheme" RFC2086 "IMAP4 ACL extension" RFC2222 "Simple Authentication and Security Layer (SASL)" RFC2195 "IMAP/POP AUTHorize Extension for Simple Challenge/Response" RFC2595 "Using TLS with IMAP4, POP3 and ACAP" ＊このほか、IETFのワーキンググループでも活発な標準化作業が行われている

表2　IMAP4関連の標準仕様

　また同時に、IMAP4は現在も大きく仕様を進化させ続けているプロトコルであり、IETFをはじめとした標準化団体から追加仕様が次々に発表されている段階である^＊1。

＊1現在のバージョンは「IMAP4 rev1」と呼ばれる。IMAP4はIMAP version 4を意味している。rev1とは、その中のリビジョン番号1という意味だ。最新仕様はRFC2060である。本連載の内容もこれに従っているが、この仕様さえも現在改正作業中である。またIMAP4は、ほかのプロトコルと比較しても、数多くの関連標準仕様から成り立っている。先に挙げた関連標準仕様も参考にしてほしい

■POP3の限界とIMAP4の可能性

　前回も述べたように、POP3にはすでに明白になっているいくつかの問題点がある。以下にまとめよう。

• モバイル環境での利用
  POP3では、基本的にメールデータをローカルPCへダウンロードするだけだ。その後、サーバにメールは残らない。ユーザーが複数の方法やデバイスでメールを読みたくなった場合に、一度メールを取り込んで消してしまうと、ほかのアクセスからはそのメールを読む手段がない。そのつど、ほかのデバイスからのアクセスのことを考慮しなくてはならないのは、大きな負担である
  
  
• メールボックスやフォルダの管理
  例えば、送信済みのメールや一度ダウンロードしてしまったメールのフォルダでの管理は、ローカルPC上でしか行えない。これは、基本的にPOP3はメールのダウンロード機能しか提供しないからで、別のPCでの送信済みメールをほかのPCから確認する手段は存在しない
  
  
• ネットワークや処理への負荷
  ヘッダやメール全体のダウンロード機能しかないため、「ネットワークが遅いから巨大な添付ファイルをダウンロードしたくない」などのニーズに対応できない

　これらの問題点を解決するには、1つの考え方しかない。メーラに完全にメールを取り込むのではなく、サーバにメールを保管し続けメーラからサーバのメールボックス全体を管理可能にする方法だ。つまり、これがIMAP4の基本的な出発点である。

■IMAPの特徴

図1　IMAP4の概略図。基本がダウンロードのみのPOP3とは異なり、サーバに対して各種の操作が行えることがわかる

　これはIMAP4の概要図である。これらIMAP4を構成する基本的な機能について、見てみることにしよう。

●認証
　IMAP4クライアント（メーラ）から認証情報を受け取り、サービスする対象ユーザーを決定する。POP3のようなユーザー名とパスワードによる単純なログイン方法や、よりセキュリティを高めた拡張仕様などが定義されている。

●メールボックスへのアクセス／管理
　まず注目すべき点として、IMAP4では「メールボックス」は1つだけではないということだ。ユーザーがログインして使用できるメールボックスは、複数存在し得る。

図2　IMAP4での複数のメールボックスの操作と管理

　唯一名称が固定化されているメールボックスは「inbox」である。新規受信用のメールボックスのことだ。IMAP4サーバは、ここに自動的に着信メールを格納する。inboxは特殊な位置付けのメールボックスなので、削除したり名前を変更することはできない。

　そのほかに、任意にユーザーが別の名前でメールボックスを作成したり、管理／削除することができる。例えば、送信済みメール格納用や整理用のメールボックスを自由に作成し使い分けることも可能だ。一般的なメーラでは、「送信済み」メールボックス（フォルダと表現されることもある）や「ドラフト」メールボックスを自動的にサーバ上へ作成し、それぞれに送信済みメールや下書きメールを保存する。POP3が各メーラ独自の形式で、ローカルPCへメールを保存することと比べると、大きな違いだ。

　また、通常のディレクトリのように階層化することも可能だ。カテゴリやプロジェクトなどによって自由にディレクトリ（フォルダ）を作成し、その下に複数のメールボックスやディレクトリを複数階層にわたって作成できる。例えば、「OYA/Kodomo/MyBox」などと、通常のディレクトリのように左から右へ表現する。区切り文字である「/（スラッシュ）」には、別の文字が使われることもある。なお、inboxを階層化することはできない。

●パブリック／共有メールボックス
　IMAP4ではパブリックメールボックスが想定されている。パブリックメールボックスとは、複数のユーザーで同時に使用できるメールボックスのことだ。複数ユーザーでメールデータやドキュメントを共有することを想定している。一方、共有メールボックスとは、ユーザーの任意のメールボックスをほかのユーザーに対して公開する機能のことだ。

●メールボックスの購読
　購読とは、ネットニュースなどでも存在する機能だ。多数存在しているメールボックスのうち、通常使用するメールボックスを登録し、デフォルトではそれらのみを使用する機能である。

　上の説明だけでは、なぜこんな機能があるのかぴんとこないことだろう。実は、IMAP4は単にメールだけでなく、ネットニュース、FTP機能、サーバ上のディレクトリなども参照できる機能を追加可能なように仕様が想定されているのだ。実際にネットニュースなどが読めるかどうかはサーバの実装しだいなのだが、例えばネットニュースのニュースグループなどは通常数万件はあるので、メールボックスやデータを無条件ですべて使用することには、リスクが伴う。そこで、購読が指定されたメールボックスのみを、通常利用するメールボックス範囲とするのである。

●メールデータの取得／変更／削除／保存
　当然のことながら、メールデータを取得／削除／変更したり、作成したメールを任意のメールボックスに保存することが自由に行える。IMAP4の大きな特徴として、サーバが格納されているメールデータをMIMEデータと認識し、必要な部分にだけアクセスすることが可能だ。ヘッダの一部だけを取り出したりメール全体をダウンロードすることなく、任意の添付ファイル、あるいはテキストのみの取得などが自由に行える。また、それらの作業のためにMIMEデータの構造を調べることも容易にできる。

●メールデータ属性
　POP3との大きな違いとして、「メッセージフラグ」という機能がある。これは、各メールメッセージに「フラグ」と呼ばれる識別属性を付加できる機能である。つまり、一種の「目印」として使用できるわけだ。フラグには以下の種類がある。

フラグ 意味 \Seen 一度クライアントによって参照されている（既読） \Answered 返信メールが作成されたことがあるのを示す \Flagged 何らかの注意喚起を引きたい際に利用する汎用的なフラグ \Deleted 削除予定フラグ。EXPUNGEコマンドによって最終的に削除される \Draft メールは草稿状態であることを示す \Recent 最近メールボックスに届いたことを意味する。サーバによってのみ付加され、クライアントからは変更できない ＊ここでは\（円記号）として表現されているが、 欧米圏ではバックスラッシュとなることに注意

表3　メッセージフラグの種類

　これらは「システムフラグ」と呼ばれ、名前が予約されており、それぞれの意味に従って使用しなければならない。クライアントからの要求によって自由にそれぞれのメールに付加できるほか、サーバが独自の判断によって付加する場合もある。複数のフラグを1つのメールに付加することもできる。ただし、「\Recent」フラグだけは、サーバによってしか付加できない。

　また、主に上記のフラグは「PERMANENT FLAGS」と呼ばれる特殊なフラグでもある。「permanent」とは「永続的」という意味だが、これはセッションが終了してもメールボックス内で保持され続けることを意味する。

　これに対して、上記にはない独自のフラグを付加できる場合もある。その場合、先頭文字は「\（円記号、またはバックスラッシュ）」以外でなければならない。また独自フラグは永続的とはならず、そのセッション内においてのみ有効となる場合もある。

●メール検索
　IMAP4では、クライアントの処理負荷を極力減らすためのすべがいろいろ用意されている。メール検索もその1つだ。わざわざメールをダウンロードしなくとも、サーバ側で任意の条件に当てはまるメールの検索が自由に行える。メールをダウンロードした場合と同様に、MIMEデータを解析するので、メールヘッダ個々に関して検索条件を指定することができる。

●メールデータの同期
　これは、特別こうした機能があるというわけではない。上記のような多彩な機能を用いて、メーラがサーバ上のデータと完全に同期する、つまりローカルにまったく同じデータのコピーを保持し続けることを前提に考えられているということだ。

　IMAP4に、ここまで述べたような機能があったとしても、必ずネットワークと「オンライン」にならなくてはメールを読めないとなると、かなり不便だ。モバイル用途などを考えると、メーラがローカルにも同じコピーを持ち、オンラインでなくともメールに関する作業が行えるようにしておき、オンライン環境に復帰した際に上記の機能を使って自動的に同期できれば利便性は向上する。こうした「オフライン」機能をメーラが持つことを、IMAP4では前提にしている。

■IMAP4プロトコルの基本フォーマット

　IMAP4で最初に引っ掛かるのが、プロトコルの複雑さだろう。以下を見てほしい。

0001 AUTHENTICATE CRAM-MD5 * CAPABILITY IMAP4 IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND 0001 OK AUTHENTICATE completed 0002 NAMESPACE * NAMESPACE (("" "/")("#mhinbox" NIL)("#mh/" "/")) (("~" "/")) (("#shared/" "/") ("#ftp/" "/")("#news." ".")("#public/" "/")) 0002 OK NAMESPACE completed 0003 LIST "" "INBOX" * LIST (\NoInferiors) NIL INBOX 0003 OK LIST completed 0004 LIST "" * * LIST (\NoInferiors) "/" &kAFP4W4IMH8wojCkMMYw4A- * LIST (\NoInferiors) "/" &Tgtm+DBN- * LIST (\NoSelect) "/" fol2 * LIST (\NoInferiors) "/" fol2/fol3 * LIST (\NoInferiors \UnMarked) "/" fol10 * LIST (\NoInferiors) NIL INBOX 0004 OK LIST completed 0005 CREATE Trash 0005 OK CREATE completed 0014 SELECT "INBOX" * 5 EXISTS * 0 RECENT * OK [UIDVALIDITY 988028003] UID validity status * OK [UIDNEXT 6] Predicted next UID * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) * OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags * OK [UNSEEN 5] first unseen message in /var/spool/mail/user 0014 OK [READ-WRITE] SELECT completed 0015 STATUS "INBOX" (MESSAGES UNSEEN UIDNEXT) * NO CLIENT BUG DETECTED: STATUS on selected mailbox: INBOX * STATUS INBOX (MESSAGES 5 UNSEEN 1 UIDNEXT 6) 0015 OK STATUS completed

図3　IMAP4プロトコルのやり取りの例

　正直にいって、この例から大体の意味をとらえるのもなかなか難しいのでないか。これまでどおり、HTTPやPOP3とも基本的なところは同じなのだが、IMAP4の場合、リクエストやレスポンスが複数行かつ多岐にわたるため、なかなか理解が難しい。

　まずは一般的な例について、その基本を押さえてみることにしよう。

●IMAP4メッセージのフォーマット
　IMAP4においても、クライアントとサーバの通信には可読可能な文字による「行」が用いられる。サーバへの要求は、コマンドそのほかを含む「リクエスト」行が送られ、サーバはその結果を「レスポンス」行として返す。レスポンスは複数行にわたる場合も多い。この「行」のフォーマットは、HTTPやSMTPなどと異なる特徴がある。これが「タグ」だ。

リクエスト：
タグ リクエストコマンド[ 引数]

レスポンス：
タグ [ステータス] [ レスポンスコード] メッセージ

　上記は簡単なリクエストとレスポンスのフォーマットだ。タグの一番の目的は、このようにリクエスト時に指定し、レスポンスでそのリクエストに対する返答であることを明示するためである。タグのフォーマットは特に決まっていないので、英数字であれば何でもよい。サーバはこのタグを基にコマンドを管理し、処理を実行する。

　また、タグには無名タグというべきものが存在している。これは、タグが「*（アスタリスク）」になっており、「タグなし行」と呼ばれる。通常、1つのリクエストに対して、必ず1つの対応するタグのレスポンス行が返される。このほかに、補足する目的や結果が複数にわたる場合、それ以外の行はタグなし行となる。複数のタグなし行が続き、最後にタグ付き行が現れるまでが一続きのレスポンスであることを示す。

図4　複数行レスポンスの例

　そのほか、「+（プラス）」タグのレスポンス行もある。これは、リクエストが複数行にわたる場合に、続けて受け入れ可能なことを示す特殊なレスポンスである。

　レスポンスのステータスは、多くの場合「OK」か「BAD」によって正常終了／異常終了かを示す。そのほか、「BYE（ログアウト時）」「NO（異常終了ではないが、何らかの問題でコマンドが拒否された場合）」「PREAUTH（サーバの設定などによって認証の必要がない場合）」が返ることがある。

　複数行のレスポンスの場合には、さまざまな追加情報を含まれることが多い。中でも [ ] に囲まれた「レスポンスコード」を含む行によって、具体的なメールやメールボックス情報を示すことになっている。レスポンスコードには、以下のような種類が定義されている。

種類 意味 RFC ALERT レスポンスのメッセージが、ユーザーに直接提示すべき警告情報であることを示す（多くの場合、メッセージがユーザーに提示されるかどうかはメーラに任されているため） RFC2060 PARSE メールのMIME構造の解析エラーを示す RFC2060 READ-ONLY そのメールボックスは読み込み専用である RFC2060 READ-WRITE そのメールボックスは読み込み／書き込みが可能である RFC2060 TRYCREATE 要求されたCOPYやAPPENDコマンドで指定されたメールボックスがなく、失敗していることを示す。つまり、先にメールボックスの作成を促すコードである RFC2060 UIDVALIDITY UID-Validity そのメールボックスのUID-Validity（一意識別子）。 RFC2060

表4　IMAP4のレスポンスコードの一覧（一部抜粋。こちらをクリックすると、別ウィンドウで一覧の完全版を表示します）

　レスポンスコードは、タグ行にもタグなし行にも任意に現れる可能性がある。現れるレスポンスコードは、要求されたコマンドによりほぼ決まることになる。多くの場合、複数行としてレスポンスコードを示す行が返され、クライアントに有用な情報を示す。

　レスポンスのメッセージが、具体的な結果を示している。多くの場合、先頭には応答したコマンドも含んでいる。

●並列処理
　IMAP4でタグが導入されている背景には、「並列処理を許容している」という事情がある。並列処理とは、SMTPのパイプラインニングなどのように、リクエストがレスポンスを待つ必要なく、次のリクエストを発行可能な機能のことだ。つまり、複数のリクエストが並列して発行されるとともに、複数のレスポンスが別々に、ときには前後して到着するかもしれない。こうした場合、それぞれの結果を識別できるタグは非常に有効な手段となる。

●UID（Unique Identifier）とメッセージ番号
　POP3と同様に、IMAP4でもUID（POP3ではUIDL）とメッセージ番号が存在している。メッセージ番号はメールボックス内の連番であり、次回セッションでは再度振り直され変わってしまう可能性がある（永続的ではない）が、UIDはメールボックス内で必ず永続的に一意であることが保証される。メールへのアクセスは主にメッセージ番号で行われるが、UIDによってメッセージを識別することもできる。特に、クライアントがローカルにメールボックスのコピーを保持している場合に有効である。

　また、メールボックス自体にも一意に識別するための数値が割り当てられる。これを「UID-Validity」と呼ぶ。言葉は似ているが、UIDとは別物だ。つまり、メールボックスはメールボックス名とUID-Validityを持っているわけだが、これは仮に一度メールボックスを削除（保持しているメールはすべて削除／移動）して、次にまったく同じ名前のメールボックスが作成された場合に、それを知らないクライアントがアクセスしても混同しないためのものだ。

---

　さて、以上でIMAP4の基本的な機能とフォーマットの意味は理解できたはずだ。後半では、IMAP4のそれぞれのコマンドと具体的な例などについて解説しよう。

　

「IMAP4〜後編」へ

「Master of IP Network総合インデックス」

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）