PR

コマンド解説

 ここでは、POP3のコマンドとその応答などについて解説します。POP3のコマンドのなかには、必ず実装していなければならないコマンドと、実装するかどうかを選択できるコマンドの2種類があります。

Transaction状態のコマンド

 以下で説明するコマンドは、POP3では必ず実装されていなければならないコマンドです。これらはすべてTransaction状態で利用できます。

STAT
 STATコマンドは、現在サーバーに保存されているメッセージの数とその合計サイズを報告するためのものです。メッセージが保存されている場所は、“Maildrop”と呼ばれ、このSTATコマンドが返す応答はドロップ・リスト(drop list)といいます。

 STATコマンドに対する応答は、1行のみで、必ず「+OK nn mm」という形式となります。このとき、nnはMaildropにあるメッセージ数、mmはその合計サイズを示しています。メッセージを削除しなければ、nn個のメッセージがあるとSTATコマンドが応答した場合、メッセージ番号は1~nnになります。

LIST
 LISTコマンドは、Maildropにある個々のメールのサイズなどを報告するコマンドです。このLISTコマンドの結果をスキャン・リスト(Scan List)といいます。

 このコマンドの応答は必ず複数行となります。たとえMaildropにメッセージがなくとも応答は複数行です。

 その形式は、以下のようになります。

+OK n messages(mm octets)
1 s1
 :
n sn
.

 Scan listは必ず「メッセージ番号スペースメッセージ・サイズ」という行からなり、これをメッセージの数だけ繰り返します。

 LISTコマンドに引数としてメッセージ番号を入れると、指定されたメッセージのみについてのスキャン・リストを返します。このときの応答は、「+OK n m」となり、nがメッセージ番号、mがそのサイズとなる1行のみの応答です。

RETR
 実際にメッセージを取得するためのコマンドがRETRです。このコマンドは、引数として必ずメッセージ番号を必要とします。応答は、常に複数行で以下の形式となります。

+OK xxx octets
最初のヘッダー行
   :
   :
本文の最後の行
.

 つまり2行目からは、メッセージがそのまま送られて、最後にピリオドだけの行が来ます。前述したように、メッセージ中にピリオドのみからなる行があった場合、ピリオドが1つ追加され、応答の最後を表すピリオドのみの行と混同することはありません。

DELE
 DELEコマンドは、Maildrop内のメッセージを削除するためのものです。引数には、必ずメッセージ番号を指定します。

 DELEコマンドは、実際には、メッセージに対して削除するマークを付けるだけです。実際の削除は、正常にセッションが終了する直前のUpdate状態で行われます。

 しかし、一度DELEコマンドでメッセージにマークを付けると、そのメッセージ番号は、ほかのコマンドの引数としては指定できなくなります。スキャン・リストにもそのメッセージ番号は表示されなくなります。

NOOP
 このコマンドは、「なにもしない」コマンドです。応答は常に肯定的応答(+OK)であり、エラーになることはありません。なんの役にもたたないコマンドのようですが、インターネットで使われるプロトコルには、よくこうした何もしないコマンドが定義されます。これは、相手が正しく動作しているかどうかの確認や、切断タイマー(一定時間、通信がないと強制的に切断する機能)などを更新するために使います。

 TCPのレベルでは、通信が行われている状態であっても、サーバー側プログラムが何らかの原因で動作を停止する可能性があります。このとき、何もしないコマンドであれば、サーバー側にほとんど負荷をかけることなくこれを調査できます。STATなどのほかのコマンドでも調査は可能ですが、サーバー側に処理が発生するため、数多くのクライアントに対応するサーバーとしては好ましくないからです。

RSET
 RSETは、POP3セッション開始から、いままでに実行してきたコマンドの効果を取り消します。具体的には、DELEコマンドで実行した削除を取り消します。

 このコマンドは常に成功し、1行のみの肯定的応答を返します。

QUIT
 QUITコマンドは、Transaction状態だけでなく、Authorization状態でも利用可能なコマンドです。しかし、Transaction状態から実行した場合、Update状態に入ったのちにPOP3セッションが終了となります。このとき、DELEコマンドで指定されたメッセージが削除されるのですが、その結果が応答として返されます。

 なんらかの原因でメッセージが削除できない可能性もあるため、Transaction状態でのQUITコマンドは、「+OK」、「-ERR」のどちらも返す可能性があります。メッセージは、POP3を実行するサーバー・プログラム以外が実際に管理している可能性があります。たとえば、ファイルとしてメッセージを保存している場合、これを直接管理しているのはファイル・システムです。POP3サーバー・プログラムがこれを削除しようとしても、ファイルの状態によっては削除できないこともあるわけです。

 これに対してAuthorization状態で実行されるQUITコマンドは常に肯定的応答を返します。

オプション・コマンド

 オプションとされているコマンドは、以下の通りです。

USER/PASS
 基本的な認証コマンドとして想定されているのが、このUSERコマンドとPASSコマンドです。この2つのコマンドは対で使われ、最初にUSERコマンドを送信しなければなりません。USERコマンドは、以後のTransaction状態で対象とするMaildropの所有者であるユーザーを指定するためのものです。引数として必ずユーザー名(Maildrop名)を指定します。

 USERコマンドの応答は、セキュリティのことを考慮して必ずしも、Maildropの有無に連動しているわけではありません。存在しないユーザーに対してUSERコマンドでは肯定的応答を返し、PASSコマンドで否定的応答を返すということも認められています。これにより、登録されているユーザー名を調べるために、ランダムなユーザー名を入れてみるといった方法が使えなくなります。

 また、ほかの認証方法を使わせるために、MaildropがあってもUSERコマンドが否定的応答を返す場合もあります。PASSコマンドによるパスワード送信は、平文(暗号化されていない文字列)で行われるため、盗聴などによりパスワードが漏えいする危険があります。このため、APOPなどのほかの認証方法を使わせたい場合に、USERコマンドは受け付けるものの、応答として否定的応答を返すというように使います。

 PASSコマンドは、引数としてパスワードを指定します。このPASSコマンドが肯定的応答を返した場合には、Transaction状態に移行します。

 USER、PASSコマンドのどちらも応答は1行のみです。

 USER/PASSコマンドがオプションとされているのは、APOPなどほかの認証方法があるからです。ユーザー認証をオプションとして、認証自体を実施しないことは推奨されていません。ほかの認証方法を使うならば、USER/PASSコマンドは、実装されていなくともよいということです。

APOP
 APOPは、パスワードを平文で送るPASSコマンドを改良するために用意されたコマンドです。このAPOPは、通信を傍受されても、パスワード自体を知られないような形で認証を行うコマンドです(図8)。

図8 MD5を使ったチャレンジ/応答認証は、認証側(通常はサーバー)がチャレンジ文字列を作ってクライアントに送信する。双方でこのチャレンジ文字列とパスワードをつなげて1つの文字列とし、MD5を計算する。クライアントは計算結果をサーバーに転送し、サーバーはこれを自分で行った計算の結果と比較する。一致すれば、クライアントは正しいパスワードを知っていることになる。この方式では、通信を盗聴されてもMD5の逆計算ができないため、パスワードを推測することが現実上は不可能になる。

 このAPOPコマンドが実装されている場合、接続直後にサーバーが送る接続完了通知に時刻を基にした「チャレンジ」文字列が含まれます(正確にはRFC822で定義されるメッセージIDと同じ形式の文字列)。これとパスワードをつなげたものをMD(メッセージ・ダイジェスト)5と呼ばれる関数を使って変換し、それを16進数文字列としてサーバーにAPOPコマンドで送信します。

 MD5は、文字列から128ビットの数値(ハッシュ値)を求める計算です。ハッシュ値から元の文字列を推測できないという性質があります(リスト2)。また、ハッシュ値が同じになるほかの文字列を作成するのが困難という性質もあります。

リスト2

 サーバーとクライアントでハッシュ値が一致するかどうかで、パスワードが正しいかどうかを判定します。実質的に、クライアントがパスワードを送って認証を行うのと同等です。

TOP
 TOPコマンドは、メッセージの先頭から、途中までを取り出すコマンドです。メッセージ先頭にはヘッダー部分があり、TOPコマンドでは、メッセージ番号と本文の行数を指定します。本文の行数としてゼロを指定すると、ヘッダー部分のみが返されます。このときの応答の形式は、RETRコマンドの応答と同じになります。

UIDL
 メッセージ番号は、セッションごとにメッセージとの対応が違ってしまう可能性があります。UIDLは、常にメッセージとの対応が一定の文字列(これをユニークIDといいます)を返すコマンドです。このコマンドの結果を保存しておくことで、クライアントは、「前回読み込んだが削除しなかった」メッセージをそれ以後のセッションで区別できます。応答は、「メッセージ番号スペースユニークID」という形式の行を複数並べて構成します。

 このコマンドを使うことで、クライアントはメッセージ本文をTOPやRETRコマンドで調べなくても、一度読み込んだメッセージかどうかを判定できます。ただし、同じメールが2つ到達する可能性があり、クライアントは、同一のユニークIDを持つ2つの同じメッセージを区別できるようにしなければなりません。

ほかのRFCで定義されたコマンド

 RFC1939以外のRFCで定義されたコマンドがあります。

AUTH
 RFC1734で定義されたのがAUTHコマンドです。これは、新たな認証のための機構を利用するためのコマンドです。どのような認証機構を使うのかは実装に委ねられています。AUTHコマンドは、基本的な枠組みを提供するだけです。引数として認証機構の名称を必要とし、サーバー側が認証に必要なデータを行頭に“+”を付けて送信できるようにしています(リスト3)。

リスト3 AUTH以後のやりとりは、認証メカニズムにより違いがある。仕組みとしては認証のためにサーバーが行頭に“+”を付けたデータを送信できるようにしている。最後にサーバーからの認証の判定が応答として戻される。

CAPA
 RFC2449が定義するCAPAコマンドは、POP3サーバーに実装されている機能を調べるためのコマンドです。このCAPAコマンドは、リスト4のようにサーバーが装備している機能を複数行として返します。

リスト4

 これにより、クライアントはサーバーの能力に合わせて最適な動作が可能になります。

◇   ◇   ◇

 次回は、テキスト・ベースではないプロトコルの例として、ファイルの転送に利用されるTFTP(Trivial File Transfer Protocol)について解説します。