POP3（Post Office Protocol version 3）：インターネット・プロトコル詳説（7）

» 2001年06月05日 00時00分公開

メール転送プロトコルのもう一方の担い手「POP3」


1984年	最初のPOP仕様 RFC918が発表される。基本的なコマンド体系は、この頃すでに確立されている
1988年	POP3としての最初の仕様である、RFC1081が発表される
1996年	幾度かの改定を経て、RFC1939がスタンダード（STD53）として確立する
表1　POP3の歴史年表

　今回はSMTPと並ぶメール転送プロトコルの一方の雄、POP3について解説しよう。POP3については、いまさら説明することもないだろう。メールサーバ（多くの場合、MTAサーバ）に到着したメールを、PCなどのクライアントに取り込む（ダウンロード）ためのプロトコルだ。皆さんが使っているメーラは、このPOP3に例外なく対応しているはずだ。


RFC1939 （STD53）	"Post Office Protocol - Version 3"
RFC2449	"POP3 Extension Mechanism"
RFC1734	"POP3 AUTHentication command"
RFC2195	"IMAP/POP AUTHorize Extension for Simple Challenge/Response"
表2　POP3関連の標準仕様

　なおPOP3とは、「POP version3」という意味だ。ということは、「バージョン1や2もある」ということなのだが、現在では、これらはほとんど使われることはない。また、POP3とオリジナルのPOP／POP2とは、互換性も維持されていない。

なぜPOP3が必要か

　POP3の説明に入る前に、少しだけこのプロトコルの位置付けを確認してみよう。

図1　POP3の動作模式図。POP3の主な仕事は、SMTPルーティングによって配信されたメールを、POP3サーバとPOP3クライアント（メーラ）との間でやり取りすることだ

　POP3は、ユーザーエージェント（「メーラ」または「POP3クライアント」）とメールサーバ（POP3サーバ）とをつなぐプロトコルである。前回説明したSMTPサーバとは別の機能だ。つまり、MTAを司るプロセスやジョブとは別のサーバ機能によって、POP3サーバ機能は提供されている。実際、TCPポートもMTA（SMTP）は25番を使用するが、POP3は110番を用いる。当然、設定も通常はまったく別々に行わなければならない。

　MTAの仕事は、MTAサーバ上のユーザーごとの「メールボックス（POP3では「メールドロップ：mail drop」と呼ばれる）」に正しくメールを届けるところまでだ。メールボックスに届いたメールをどのように読んだり入手するかは、個々のユーザーの自由裁量である。

　歴史的には、メールサーバはUNIXで運用されてきたので、ユーザーはメールサーバへTelnetなどでログインし、コマンドラインからメールを読めばよかった。また、当時はマシンが高価なため、共有環境が一般的で、MIMEなど複雑なメールもなかった頃の話である。

　しかし、PCの普及に代表されるような1人1台の環境が整備されても、個々のマシンにMTAを立ち上げてメール配信をさせるのは非現実的だ。そこで、MUA（Mail User Agent）機能を個々のユーザーのPCに任せ、メールサーバはMTAに専念する方法が一般化した。そこで、メールをサーバからローカルPCに取り出すために考え出されたのがPOPなのである。POP3は、「ローカルPCまでは届かないメールの『最後の1ホップ』を埋めるためのプロトコルだ」という言い方ができるだろう。

　POP3の特徴としては、以下のことが挙げられる。

プロトコルやコマンド体系がシンプル
SMTPなどと同様に比較的実装しやすく、処理負荷も低い
ストア・アンド・フォワード型のサービスである
ストア・アンド・フォワードとは、メールサーバにメールが溜まると、そこから一方的にメールを取り込むサービス方法のことだ。つまり、サーバとの関わりは最初にメールを取り込んだ時だけでしかない

　元々メール取り込みのためだけに開発されたプロトコルなので当然なのだが、言い方を換えれば、個々のローカルマシンでしかメールの管理は行えず、モバイル環境などには不向きだ。

　近年、こうした点から、POP3では十分にMUAの役割が果たせないことが明らかになりつつある。これらの問題点については、次回以降、IMAP4に関連して述べることにしよう。

POP3コマンド

　このような特徴をもつPOP3の機能は、SMTP以上にシンプルだ。主に以下の機能から成り立っている。

認証
ユーザー名とパスワードによる認証によって、対象とするユーザーのメールボックスを認識する
メールのダウンロードや一覧情報の確認
メールボックスに届いているメールの取り出しや、届いているメール数、サイズの確認
メールの削除
メールボックスからのメール削除

　では、実際のプロトコル例を眺めてみよう。以下は、一般的なメーラでの例だ。

図2　POP3による、サーバとクライアント間でのやり取りの様子

　POP3も多聞に漏れず、HTTPやSMTPのようにテキスト（ASCIIコード）ベースのプロトコルである。文字列の終端が「CR（0x0d）＋LF（0x0a）」で示される行からなるリクエストとレスポンスによって、通信が行われる。

　リクエストは、コマンドとパラメータからなる、1行のみのデータだ。レスポンスは1行の場合もあれば、複数行に渡る場合もある。複数行に渡る場合は、最終行は「.（ピリオド）」のみの行によって、レスポンスの最終行であることを示さなければならない。

　レスポンスの1行目は、必ずステータスを示している。ステータスは単純で、正常（+OK）かエラー（-ERR）かしか存在していない。エラー番号などは定義されておらず、詳細はステータス・メッセージから判断される。

[+OK|-ERR] ステータス・メッセージやパラメータ

　まず接続が開始されると、サーバからはグリーティング・メッセージが返される（(1)）。次に、クライアントはログイン認証を行う。USERコマンドとPASSコマンドで、ユーザー名とパスワードを送出している。認証が正常に終了すると、サーバはユーザーのメールボックスに届いているメール数と全体サイズ（バイト単位）を表示する（(2)）。認証後は、そのユーザーのメールボックスをサービスすることになる。

　なお、ほかのPCなどから同じユーザーですでにログインしていた場合には、エラーとなり、接続はできない。これは、POP3では「トランザクション状態」という考え方があるためだ。例えば、同時に同じユーザーがログインして別々のメールを削除したり、あるいはログイン中にも新規メールが届くかもしれないが、それによって処理に矛盾が出てしまう可能性がある。そこで、ログイン後はサーバによってメールボックスはロックされ、新規メールの到着も遅延される。このトランザクション状態は、ログイン後からログアウト時まで継続される。

　では、そのほかのコマンドを説明しよう。

STAT

　現在のメールボックスのステータス表示を行う。正常終了時には、以下のようなレスポンスが返る。

+OK メールボックスに保存されているメール数メール全体のサイズ

　内容は、グリーティング・メッセージとほぼ同等だ。注意してほしいのは、「メール数」とは、あくまでメールボックスに現在存在しているメールの数だということだ。必ずしも新規に到着したメールとは限らない。POP3では、新規メールという概念は元々存在していないのだ。メーラで新規メールチェックなどの機能があるが、これはこの後説明するLISTやUIDLコマンドによって定期的にメールボックスをチェックし、前回と比べた変化から検出しているに過ぎない。

LIST [メッセージ番号]

　メールボックス内メールの一覧表示を行う。レスポンスの1行目はSTATのレスポンスとほぼ同じ意味だ。2行目以降に、以下のようなメールごとの情報が並ぶ。

メッセージ番号メールごとのサイズ

　メッセージ番号とは、メールボックス内での順序番号である。メールボックスへの到着順に1から順に割り振られる。注意しなければならないのは、例えば、途中の1メールだけが削除されると、次回接続時には、番号は再度到着の早い順に振られ直されるということだ。つまり、現在の接続で割り振られている番号が、次回接続時も同じメールを指しているとは限らない。おそらくは変わっていると考えるべきである。

　引数として、メッセージ番号をとることもできる。この場合は、指定されたメッセージ番号のメールの情報のみを表示する。

RETR メッセージ番号

　メールメッセージの取得（ダウンロード）を行う。引数として、必ずメッセージ番号を指定する。例によって、レスポンスの1行目にステータスを表示した後、2行目以降に実際のメールデータが表示される。そして、最後の「.（ビリオド）」がデータの終端を示している。メールデータは、MIMEの回で説明したようなヘッダとボディからなるメールメッセージである。

　RETRメッセージは、単にメールメッセージのダウンロードを行うだけだ。メールの削除は、明示的にDELEコマンドが発行されない限り行われないことに注意しよう。RETRコマンドは、メールのダウンロードを行う最もメインのコマンドである。通常は、LISTコマンドによって全メール数を取得して、RETRコマンドを繰り返して順にメールを取り出す……といった使い方をする。

TOP メッセージ番号 Line数

　TOPコマンドはRETRコマンドに酷似している。RETRは単にメールメッセージ全体をダウンロードするだけだったが、TOPコマンドは、Line数を指定することでダウンロードするメールメッセージのボディーの行数を指定できる。ヘッダーは必ずダウンロードされる。0とするとメールヘッダーのみ（メールメッセージのうち、最初の空行の部分まで）となるので、主にメール一覧のみ必要としている場合などによく使用される。

DELE メッセージ番号

　指定したメッセージ番号の示すメールをメールボックスから削除する。一般に、POP3対応メーラには「サーバにメールを残すかどうか」というオプションがあるが、これをオンにした場合には、このDELEコマンドによって、メールダウンロード後に該当メールを削除しているわけだ。

　LISTコマンドの項でも述べたが、DELEコマンドによって欠番が生じると、次回接続時にはメッセージ番号が再度順番に割り振られる。ただし、DELEコマンドの発行後、ログアウトを行うまでは欠番のまま番号は保持される。

図3　DELEコマンド後のメッセージ番号の変化。LISTコマンドを実行したところ、2が欠番となっているが、セッションが続いている間は欠番のまま保持される

RSET

　これまで行われた処理のリセットを行う。おもに、DELEコマンドの結果を取り消すために行われる。つまり、それまでに行った削除命令はすべてキャンセルされる。

UIDL [メッセージ番号]

　UIDL（Unique ID Listing）によるメール一覧の表示を行う。ステータス行に引き続いて、メッセージ番号とUIDLからなるレスポンス行が返答される。UIDLとは、メールメッセージ個々に割り振られたユニークとなるIDのことだ。POP3サーバの管理下では、暗黙的にすべてのメールがこうしたIDを保持する。多くのPOP3サーバでは、実際にメールのヘッダにもUIDLヘッダを挿入する。

　前述したメッセージ番号は、その接続でのみユニークであり、UIDLとはまったく意味合いは異なっている。形式は任意だが、英数字などのASCII文字を用いた1〜70文字からなる^＊1。例えば、メールボックスからメールを削除しなかった場合、全メールをダウンロードすることなく、前回まで存在していなかった新規のメールがあるかどうか見分けるためにUIDLが用いられる。

^＊1RFC1939では「メッセージのダイジェスト」ともしているが、実際には時刻などを組み合わせていることが多い

NOOP

　何もしない。必ず正常終了となる。クライアントが、サーバが稼働しているかを確認するために用いられる。

QUIT

　ログアウトを行う。トランザクション状態が終了し、削除処理が反映され、メールボックスのロックも解除される。

APOP ユーザー名ダイジェスト

　USER／PASSコマンドに代わるログイン認証を行うコマンドだ。いわゆるチャレンジ・アンド・レスポンス方式を採用している。USER／PASS方式では、パスワードが生でネットワークを流れることになるが、チャレンジに対するダイジェストをクライアントからサーバへ渡すことでこれを防ぎ、セキュリティレベルを高めることを目的としている。

図4　APOP（チャレンジ・アンド・レスポンス）の例

　そのほか、SMTPの回に紹介したSASL（Simple Authentication and Security Layer）による認証も使用されることがある。

　拡張仕様も含めて、コマンド一覧を別表にまとめた。参考にしてほしい（こちらをクリックすると、別ウィンドウで表示します）。

Telnetでプロトコル内容を確認してみよう

　POP3に限ったことではないが、学習や実際の業務のために、実際にネットワーク上でやり取りされているプロトコル内容を確認してみたい場合もあるだろう。じつは、POP3を始めとしたインターネットプロトコルは、すべてTelnetプロトコルを元にしている。つまり、Telnetコマンドを使って、それぞれのサーバに接続可能なのだ。

　実際にPOP3サーバへ接続した例を以下に挙げよう。

　これは、Telnet経由でPOP3サーバへ接続した例だ。本来のTelnet接続とは異なり、自分の入力が表示されない（エコーバックされない）ので分かりづらいが、USER／PASSを入力後、STATコマンドとRETRコマンドを試している。このような接続を行うには、Windowsのコマンドプロンプトの場合だと、

telnet POP3サーバ名 110

と入力する。110はPOP3のTCPポート番号だ。これを忘れると単なるTelnet接続になってしまうので注意。

　ここでは、手元のPCから実際にPOP3サーバへ接続して、STATコマンドで届いているメール数を確認している。いうなれば、POP3クライアントとしてサーバに接続しているわけだ。もっとも、Telnetで接続しているだけなので、サーバから取り込むメールもただ画面に表示されるだけでしかない。メーラは、Telnetでは画面に表示されるデータをローカルファイルに保存したり、MIMEをデコードして表示するなど、さまざまな機能を付加しているのだ。

　とはいえ、自分で実際にこれまで説明したようなさまざまなコマンドを試したり、その結果を確認することは、プロトコル動作を理解するには大いに役立つ。これまでのHTTPやSMTPの回の説明も含めて、試してみてほしい。

このようにシンプルなPOP3だが、メールシステムの足りない一角を埋める重要な位置を占めるに至っている。とはいえ、完全に満たされているわけではなく、これからのインターネットの発展において実力不足とされていることも事実だ。次回はそのような観点からも、IMAP4について解説しよう。

「次回」へ

「インターネット・プロトコル詳説」バックナンバー