このファイルは RFC821 の日本語訳です. 本翻訳は, 参考のため提供されているものであり, 英文のものが正式です. 本翻訳の正確さを, 一切保証しません. 本翻訳は, 断り無く訂正更新されます. 翻訳者: 村岡 正洋 更新日: 1998年12月04日 この文書の訂正に協力して下さった HATさん に感謝します. ======================================================================== Network Working Group J. Postel Request for Comments: DRAFT ISI Replaces: RFC 788, 780, 772 August 1982 SIMPLE MAIL TRANSFER PROTOCOL 単純メール転送プロトコル 1. はじめに 単純メール転送プロトコル(SMTP)の目的は、メールを確実かつ効率的に転 送することです。 SMTPは特別の送信サブシステムに依存せず、確実な順序づけられたデータ ストリームチャンネルのみを要求する。付録 A、B、CおよびD は、様々な 輸送サービスとのSMTPの使用について記述する。用語集はこの文書の中で 使用される用語の定義を規定する。 SMTPの重要な特徴は輸送サービス環境を横断してメールを中継するその能 力です。輸送サービスはプロセス間通信環境(IPCE)を提供する。IPCEは一 つのネットワーク、いくつかのネットワークあるいはネットワークのサブ セットをカバーするかもしれない。輸送システム(あるいはIPCE)がネット ワークと一対一でないことを悟ることは重要です。プロセスは、任意の相 互に既知のIPCEによってある他のプロセスと直接通信することができる。 メールはプロセス間通信の応用あるいは使用です。メールは、二つの(あ るいはより多くの）IPCEに接続されたプロセスによって中継することに よって、異なるIPCE中のプロセス間で通信することができる。より詳しく 言えば、メールは両方の輸送システム上のホストによって異なる輸送シス テム上のホスト間で中継されることができる。 2. SMTPのモデル SMTPの設計は、次の通信のモデルに基づく: ユーザメールリクエストの結 果、センダーSMTPはレシーバSMTPへの双方向の送信チャネルを確立する。 レシーバSMTPは最終的な送り先、あるいは一つの途中の送り先、いずれか であるだろう。SMTPコマンドはセンダーSMTPによって生成されレシーバ SMTPに送られる。SMTP返答は、コマンドへの応答でレシーバSMTPからセン ダーSMTPへ送られる。 ひとたび送信チャネルが確立されれば、SMTPセンダーはメールの差出人を 表すMAILコマンドを送る。SMTPレシーバがメールを受理することができれ ば、それはOK 返答で答える。そして、SMTPセンダーはメールの受取人を 識別するRCPTコマンドを送る。SMTPレシーバがその受取人のためのメール を受理することができれば、それはOK 返答で答える; そうでなければ、 それは、その受取人を拒絶する(しかしメールトランザクション全体では ない)返答で答える。SMTPセンダーおよびSMTPレシーバは数人の受取人を 交渉するかもしれない。受取人が交渉されたのちに、SMTPセンダーは、 メールデータを送信して、特別なシーケンスで終了する。SMTPレシーバが メールデータを成功裡に処理すれば、それはOK 返答で答える。対話は意 図的に一度に一つづつロック-ステップです。 ------------------------------------------------------------- +----------+ +----------+ +------+ | | | | | User |<-->| | SMTP | | +------+ | Sender- |Commands/Replies| Receiver-| +------+ | SMTP |<-------------->| SMTP | +------+ | File |<-->| | and Mail | |<-->| File | |System| | | | | |System| +------+ +----------+ +----------+ +------+ センダーSMTP レシーバSMTP SMTPを使用したモデル 図 1 ------------------------------------------------------------- SMTPはメールの転送のためのメカニズムを提供する; 二つのホストが同じ 輸送サービスに接続されるときは送り出すユーザのホストから受け取る ユーザへ直接、あるいは、送り元および送り先ホストが同じ輸送サービス に接続されないときは一つ以上の中継SMTPサーバを経由して。 中継能力を提供できるために、SMTPサーバは、送り先のメールボックス名 と同じように最終的な送り先ホストの名前を与えなければならない。 MAILコマンドへの引数はリバースパスであり、それはメールが誰からであ るかを指定する。RCPTコマンドへの引数はフォワードパスであり、それは メールが誰にであるかを指定する。フォワードパスはソースルートであり、 一方リバースパスはリターンルートです(これは、エラーが中継された メッセージよって起こる場合に、差出人にメッセージを返すために、それ は使用されるかもしれない)。 同じメッセージが多数の受取人の元へ送られる場合、SMTPは、同じ送り先 ホストにいる受取人すべてのためにデータのだた写しを一部だけ送信する ことを奨励される。 メールコマンドおよび返答には厳密な構文がある。返答にはさらに数値 コードがある。下記では、実際のコマンドおよび返答を使用する例がある。 コマンドと返答の完全なリストは、セクション 4 仕様、にある。 コマンドと返答は大文字と小文字の区別をしない。すなわち、コマンドと 返答の語は大文字、小文字あるいは大文字と小文字の任意の混合かもしれ ない。これがメールボックスユーザ名に該当しないことに注意してくださ い。いくつかのホストにとって、ユーザ名は大文字と小文字の区別をし、 また、SMTPインプリメンテーションは、それらがメースボックスの引数に 表れるようにユーザ名のケースを保存する場合をとらなければならない。 ホスト名は大文字と小文字の区別をしない。 コマンドと返答は、ASCII文字集合[1]の文字から構成される。輸送サービ スが8-bitバイト(オクテト)送信チャンネルを提供するとき、各7-bit文字 は上位ビットをゼロにクリアされたオクテットにちょうど正当化されて送 信される。 コマンドあるいは返答の一般的な形式を指定するとき、引数(あるいは特 殊なシンボル)は、メタ言語の変数(または定数)です。例えば"" あるいは""。ここのアングルブランケットはこれらがメタ 言語の変数であることを示す。しかしながら、いくつかの引数ではアング ルブランケットを文字通りに使用する。例えば、実際のリバースパスはア ングルブランケットで囲まれる、つまり、"" はの実例である(アングルブランケットはコマンドまたは 返答中で現実に送信される)。 3. SMTPの手続き このセクションではいくつかのパートでSMTPの中で使用される手続きを提 示する。はじめにメールトランザクションとして定義された基本的なメー ル手続きがくる。これに続くのはメールの転送、メールボックス名の確認 およびメーリングリストの展開、メールボックスの代わりにあるいはその メールボックスと組み合わせて端末へ送ること、および(メールの)交換の 開始および終了に関する記述です。このセクションの終わりに中継につい ての解説、メールドメインに関する注釈、および役割の交替の議論がある。 このセクションのいたるところにコマンドと返答のシーケンスの部分的な 例がある。完全なシナリオは付録 Fの中で提示する。 3.1. メール SMTPメールトランザクションには三つのステップがある。このトラン ザクションはセンダー識別を与えるMAILコマンドで始められる。一連 の一つ以上のRCPTコマンドはレシーバ情報を与えながら続く。その後、 DATAコマンドはメールデータを与える。最後に、メールデータ終端表 示子(end of mail data indicator)はこの処理を確認する。 手続きの第一のステップはMAILコマンドです。には 送り元のメールボックスが入る。 MAIL FROM: このコマンドは、新しいメールトランザクションを開始することそ して受取人あるいはメールデータを含むその状態テーブルおよび バッファをすべてリセットすることをSMTPレシーバに伝える。それ は、エラーを報告するために使用することができるリバースパスを 与える。もし受理したならば、レシーバSMTPは250 OK返答を返す。 は、メールボックスだけでなくより多くのものを入 れることができる。は送り元メールボックスおよび ホストの逆のソースルーティングリストです。中の 最初のホストはこのコマンドを送るホストであるべきです。 手続きの第二のステップはRCPTコマンドです。 RCPT TO: このコマンドは1人の受取人を識別するフォワードパスを与える。 もし受理されれば、レシーバSMTPは250 OK返答を返し、フォワード パスを格納する。受取人が未知ならば、550 失敗返答を返す。この 手続きの第二のステップは何度も繰り返すことができる。 は、メールボックスだけでなくより多くのものを入 れることができる。はホストおよび送り先メール ボックスのソースルーティングリストです。中の最 初のホストはこのコマンドを受け取るホストであるべきです。 手続きの第三のステップはDATAコマンドです。 DATA もし受理されれば、レシーバSMTPは354 中間返答を返し、あとに続 く全ての行をメッセージテキストと見なす。テキストの終端が受け 取られ格納されるとき、レシーバSMTPは250 OK返答を送る。 メールデータが送信チャンネル上を送信されるので、コマンド-返 答対話が再開されるようにメールデータの終端が示されなければな らない。SMTPはピリオドだけを含んでいる行を送ることによりメー ルデータの終端を明示する。透過の手続きはこれがユーザのテキス トに干渉することを阻止するために使用される(セクション 4.5.2 を見よ)。 メールデータが Date, Subject, To, Cc, From [2] のようなメ モヘッダアイテムを含むことに注意してください。 メールデータ終端表示子はさらにメールトランザクションを確認し、 レシーバSMTPに格納された受取人およびメールデータをいま処理す ることを命じる。もし受理されれば、レシーバSMTPは250 OK返答を 返す。ただもしメール処理が不完全ならば(例えば受取人なし)、あ るいはリソースが利用可能ではないならば、DATAコマンドは失敗す るべきです。 上記の手続きはメールトランザクションの例です。これらコマンドは 上で議論された順序でのみ使用されなければならない。例 1 (下)は、 メール処理中のこれらのコマンドの使用を例示する。 ------------------------------------------------------------- SMTP手続きの例 このSMTPの例は、ホストAlpha.ARPAの SmithよりホストBata.ARPA の Jones, Greenおよび Brownに送られたメールを示す。ここでは ホストAlphaがホストBateと直接連絡をとると仮定する。 S: MAIL FROM: R: 250 OK S: RCPT TO: R: 250 OK S: RCPT TO: R: 550 No such user here S: RCPT TO: R: 250 OK S: DATA R: 354 Start mail input; end with . S: Blah blah blah... S: ...etc. etc. etc. S: . R: 250 OK メールは JonesとBrownのがいま受理された。GreenはホストBeta にメールボックスを持っていなかった。 例 1 ------------------------------------------------------------- 3.2. 転送 中の送り先情報が正しくないがレシーバSMTPは正しい 送り先を知っている場合がいくつかある。そのような場合、次の返答 のうちの一つはセンダーに正しい送り先と連絡することを許すために 使用されるべきです。 251 User not local; will forward to この返答はレシーバSMTPがユーザのメールボックスがある他の ホスト上にあることを知っていることを示し、以後正しいフォ ワードパスを使用することを示す。ホストあるいはユーザのい ずれかあるいはその両方が異なるかもしれないことに注意して ください。レシーバはメッセージの配送に対して責任を負う。 551 User not local; please try この返答はレシーバSMTPがユーザのメールボックスがある他の ホスト上にあることを知っていることを示し、正しいフォワー ドパスを使用することを示す。ホストあるいはユーザのいずれ かあるいはその両方が異なるかもしれないことに注意してくだ さい。レシーバは、このユーザへのメールの受理を拒絶する。 また、センダーは提供された情報に従ってメールを転送するか、 メールを差し出したユーザへエラー応答を返すかのいずれかで なければならない。 例 2 はこれらの応答の使用を例示する。 ------------------------------------------------------------- 転送の例 S: RCPT TO: R: 251 User not local; will forward to または S: RCPT TO: R: 551 User not local; please try のいずれか 例 2 ------------------------------------------------------------- 3.3. 検証と展開 SMTPは付加的特徴としてユーザ名を検証(verify)、あるいはメーリン グリストを展開(expand)するためのコマンドを提供する。これは文字 列の引数を持つVRFYおよびEXPNコマンドで処理する。VRFYコマンドの 場合、文字列はユーザ名です。また、応答はユーザのフルネームを含 んでいるかもしれないし、またユーザのメールボックスを含まなけれ ばならない。EXPNコマンドの場合、文字列はメーリングリストを識別 する。また、複数行の応答は、ユーザのフルネームを含んでいるかも しれないし、メーリングリスト上のメールボックスを与えなければな らない。 "ユーザ名"は曖昧な用語であり、故意に使用した。もしホストがVFRY あるいはEXPNコマンドをインプリメントするならば、少なくともロー カルのメールボックスが"ユーザ名"と認識されなければならない。ホ ストが他の文字列を"ユーザ名"として認識することを選択するならば、 それは許される。 いくつかのホストでは、共通のデータ構造が両方の型のエントリを保 持するかもしれないので、単一のメールボックスへのメーリングリス トとエリアスの相違は少々曖昧です。また、一つのメールボックスの メーリングリストを持つことは可能です。リクエストがメーリングリ ストの検証(verfy)をさせる場合、もしメッセージの受取人がアドレス された時点においてそれがリスト上のそれぞれの受取人に配送される ならば、肯定応答を与えることができる。そうでなければ、エラーを 報告するべきです(例、"550 That is a mailing list, not a user")。 リクエストがユーザ名を展開(expand)させる場合、一つのユーザ名を 含むリスト返すことにより肯定応答を形成、または、エラーを報告を することができる(例、"550 This is a user name, not a mailing list")。 複数行の返答(通常EXPNについて)の場合、ちょうど一つのメールボッ クスが、返答の各行上で指定されることになっている。曖昧なリクエ ストの場合において、例えば "VRFY Smith"、二つのSmithのがあると ころでは応答は "553 User ambiguous"でなければならない。 例 3 において示されるように、ユーザ名を確認する場合は安直です。 ------------------------------------------------------------- 　ユーザ名を確認する例 S: VRFY Smith R: 250 Fred Smith または S: VRFY Smith R: 251 User not local; will forward to または S: VRFY Jones R: 550 String does not match anything. または S: VRFY Jones R: 551 User not local; please try または S: VRFY Gourzenkyinplatz R: 553 User ambiguous. のいずれか 例 3 ------------------------------------------------------------- 例 4 において示されるように、メーリングリストを展開する場合は 複数行の返答を要求する。 ------------------------------------------------------------- メーリングリストを展開する例 S: EXPN Example-People R: 250-Jon Postel R: 250-Fred Fonebone R: 250-Sam Q. Smith R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> R: 250- R: 250 または S: EXPN Executive-Washroom-List R: 550 Access Denied to You. のいずれか 例 4 ------------------------------------------------------------- VRFYおよびEXPNコマンドの文字列引数は、ユーザ名およびメーリング リストの概念の多様性によってさらに制限されることはない。いくつ かのシステム上ではEXPNコマンドの引数としてメーリングリストを含 むファイルのファイル名であることは適切である。しかしながらイン ターネット上にはファイル命名の慣習の多様性がある。 VRFYおよびEXPNコマンドは最小限のインプリメンテーション(セクショ ン 4.5.1)には含まれない。また、それらがインプリメントされたとき に、中継を横断して動作することは要求されない。 3.4. センディングとメーリング SMTPの主要な目的は、ユーザのメールボックスにメッセージを配達す ることです。いくつかのホストより提供される非常に類似したサービ スはユーザの端末に(ユーザがホスト上でアクティブであるならば）、 メッセージを配達するということです。ユーザのメールボックスへの 配達は"メーリング"と呼ばれ、端末への配達は "センディング"と呼ば れる。多くのホストでは、センディングのインプリメンテーションと メーリングのインプリメンテーションはほぼ同一であるため、これら 二つの機能はSMTPにおいて組み合わせられる。しかしながらセンディ ングのコマンドは必要な最小のインプリメンテーション(セクション 4.5.1)には含まれていない。ユーザは自分の端末上のメッセージの書 き込みを制御する能力を持つだろう。ほとんどのホストでは、ユーザ にそのようなメッセージを受理するあるいは拒絶することを許可する。 次の三つのコマンドをセンディングのオプションをサポートするため に定義する。これらは、MAILコマンドの代わりにメールトランザク ションの中で使用され、このトランザクションの特別の意味をレシー バSMTPに通知する。 SEND FROM: SENDコマンドはメールデータがユーザのターミナルへ配達され ることを要求する。ユーザがホスト上でアクティブでない(ある いは端末のメッセージを受理しない)ならば、450 返答はRCPTコ マンドに対して返されるかもしれない。メッセージが端末へ配 達されるならば、メールトランザクションは成功する。 SOML FROM: SOML(Send Or MaiL)コマンドはユーザがホスト上でアクティブ (かつ端末のメッセージを受理する)ならば、メッセージがユー ザの端末へ配達されることを要求する。ユーザがアクティブで ない(あるいは端末のメッセージを受理しない)ならば、メール データがユーザのメールボックスに入れられる。メッセージが 端末あるいはメールボックスのいずれかへ配達されるならば、 メールトランザクションは成功する。 SAML FROM: SAML(Send And MaiL)コマンドはユーザがホスト上でアクティブ で(かつ端末のメッセージを受理する)ならば、メッセージが ユーザの端末へ配達されることを要求する。いかなる場合でも メールデータはメールボックスに入れられる。メッセージが メールボックスへ配達されるならば、メールトランザクション は成功する。 MAILコマンドに使用されるのと同じ返答コードがこれらのコマンドに 使用される。 3.5. 開始と終了 送信チャンネルが開いているそのときに、ホストがそれらが思ってい るホストと通信していることを保証するためのやり取りがある。 次の二つのコマンドは送信チャンネルの開放と閉鎖に使われる: HELO QUIT HELOコマンドでは、コマンドを送るホスト自身を識別する; コマンド は"Hello, I am "といっていると解釈されるかもしれない。 ------------------------------------------------------------- 接続開始の例 R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready S: HELO USC-ISIF.ARPA R: 250 BBN-UNIX.ARPA 例 5 ------------------------------------------------------------- ------------------------------------------------------------- 接続終了の例 S: QUIT R: 221 BBN-UNIX.ARPA Service closing transmission channel 例 6 ------------------------------------------------------------- 3.6. 中継 フォワードパスは、"@ONE,@TWO:JOE@THREE"の形式のソースルートかも しれない。ここではONE, TWEおよびTREEはホストであるとする。この 形式はアドレスとルートの区別を強調するために使用される。メール ボックスは絶対アドレスです。またルートはそこに辿り着く方法に関 する情報です。この二つの概念を混乱すべきではない。 概念的にメッセージが一つのサーバSMTPからある他のへ中継されると き、フォワードパスの要素はリバースパスへ移動される。リバースパ スは逆のソースルート(つまり、メッセージの現在の位置からメッ セージの差し出したユーザへのソースルート)です。サーバがSMTP フォワードパスからそれの識別子を削除しリバースパスにこれを挿入 するときに、サーバSMTPが異なる環境において異なる名前を持つこと が知られている場合、メールが到来する環境ではなく、送り込んでい る環境中で知られている名称を使用しなければならない。 もしSMTPにメッセージが到着したとき、フォワードパスの最初の要素 がそのSMTPの識別子でないとき、この要素はフォワードパスから削除 されない。また、メッセージを送る次のSMTPを決定するために使用さ れる。いかなる場合でも、SMTPはそれ自身の識別子をリバースパスへ 加える。 出所ルーティングを使用して、レシーバSMTPがある他のサーバSMTPへ 中継されるメールを受け取るとき、レシーバSMTPはローカルのユーザ へのメールを受理または拒絶するときと同じ方法でメールの中継の仕 事を受理または拒絶するかもしれない。レシーバSMTPはフォワードパ スからリバースパスの先頭へそれ自身の識別子を移動することにより コマンド引数を変形する。レシーバSMTPはその後、センダーSMTPにな り、フォワードパス上の次のSMTPへの送信チャンネルを確立し、それ にメールを送る。 リバースパス中の最初のホストはSMTPコマンドを送っているホストで あるべきです。また、フォワードパス中の最初のホストはSMTPコマン ドを受け取っているホストであるべきです。 フォワードパスおよびリバースパスはSMTPコマンドおよび返答におい て表れる。しかし、メッセージ中においては必要ないことに注意しな さい。すなわち、これらのパスおよび特にこの構文が "To:", "From:", "Cc:"などのメッセージヘッダのフィールドに表れる必要はない。 もしサーバSMTPがメールを中継する仕事を受理し、その後フォワード パスが不正であるか、何らかの理由のためにメールが配送されなかっ たならば、それは"配達不可能なメール(undeliverable mail)"通知 メッセージを構築し、(リバースパスによって示された)配達不可能な メールの差出人へそれを送らなければならない。 この通知メッセージはこのホストのサーバSMTPからでなければならな い。もちろん、サーバSMTPは通知メッセージに関する問題についての 通知メッセージを送るべきではない。エラーの報告におけるループを 阻止する一つの方法は通知メッセージのMAILコマンドで空のリバース パスを指定するということです。そのようなメッセージが中継される とき、リバースパスを空のままにしておくことは許容される。空のリ バースパスを持つMAILコマンドは以下のように表れる。 MAIL FROM:<> 配達不可能なメールの通知メッセージは例 7 において示される。この 通知は HOSTWの JOEより発送されまた HOSTZへと中継する命令を備え HOSTXを経由し HOSTYへ送られたメッセージに対応する。例の中で我々 が見るものは、通知メッセージの報告の第一のステップである HOSTX と HOSTYの間のトランザクションです。 ------------------------------------------------------------- 配達不可能なメールの通知メッセージの例 S: MAIL FROM:<> R: 250 ok S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA> R: 250 ok S: DATA R: 354 send the mail data, end with . S: Date: 23 Oct 81 11:22:33 S: From: SMTP@HOSTY.ARPA S: To: JOE@HOSTW.ARPA S: Subject: Mail System Problem S: S: Sorry JOE, your message to SAM@HOSTZ.ARPA lost. S: HOSTZ.ARPA said this: S: "550 No Such User" S: . R: 250 ok 例 7 ------------------------------------------------------------- 3.7. ドメイン ドメインはARPAインターネットメールシステムにおいて最近導入され た概念です。ドメインの使用は、単純な文字列のホスト名の平坦なグ ローバル空間から、階層的な根をもつ木構造のグローバルアドレスへ アドレス空間を変更する。ホスト名は、ドメイン要素は最も特有なも のから最も一般的なものの順に並ぶことを理解した上で、ピリオドに よって区切られたドメイン要素文字列のシーケンスであるドメインお よびホスト指名子に取り替えられる。 例えば、"USC-ISIF.ARPA", "Fred.Cambridge.UK"および "PC7.LCS.MIT.ARPA"はホスト-ドメイン識別子かもしれない。 ドメイン名がSMTPにおいて使用されるときは常に公式名称のみが使用 され、ニックネームまたはエリアスの使用は許されない。 3.8. 役割の交替 TURNコマンドは送信チャンネル上で通信する二つのプログラムの役割 を逆にするために使用されるかもしれない。 プロクラム-Aが現在センダーSMTPでありTURNコマンドを送りok 返答 (250)を受け取るならば、プログラム-AはレシーバSMTPになる。 プログラム-Bが現在レシーバSMTPでありTURNコマンドを受け取りok 返 答(250)を送るならば、プログラム-BはセンダーSMTPになる。 役割の交替を拒絶するためには、レシーバSMTPは 502 返答を送る。 このコマンドはオプションであることに注意してください。これは送 信チャンネルがTCPである状況では通常使用されないでしょう。しかし ながら、送信チャンネルを設立するコストが高いとき、このコマンド は全く有用かもしれない。例えば、公衆回線の電話システムを使用し たメールの交換をサポートには有用であるかもしれない。特にいくつ かのホストがメール交換のためにポーリングする場合。 4. SMTPの仕様 4.1. SMTPコマンド 4.1.1. コマンドの意味 SMTPコマンドはユーザによって要求されたメール転送あるいはメー ルシステムの機能を定義する。SMTPコマンドはによって終わ る文字列です。コマンドコード自身はパラメータが続くばらば で、そうでなければで終わるアルファベット文字列です。 メールボックスの構文はレシーバサイトの慣習に合わせなければな らない。SMTPコマンドは以下で議論される。SMTP返答はセクション 4.2で議論される。 メールトランザクションは異なるコマンドへの引数として通信され るいくつかのデータオブジェクトと関与している。リバースパスは MAILコマンドの引数です。フォワードパスはRCPTコマンドの引数で す。また、メールデータはDATAコマンドの引数です。これらの引数 あるいはデータオブジェクトは送信され、また処理を終了される メールデータ終端表示により伝えられた確認があるまで、保持され なければならない。このためのモデルは、個別のバッファがデータ オブジェクトの型を保持するために提供されることです。すなわち、 リバースパス・バッファ、フォワードパス・バッファおよびメール データ・バッファがあることです。特定のコマンドによって、情報 は特定のバッファへ追加されるあるいは一つ以上の・バッファはク リアされる。 HELLO (HELO) このコマンドはレシーバSMTPに対してセンダーSMTPを識別する ために使用される。引数フィールドにはセンダーSMTPのホスト 名が入る。 レシーバSMTPはコネクショングリーティングリプライの中で、 またこのコマンドへの応答において、センダーSMTPに対して自 分自身を識別する。 それへの、このコマンドおよびOK 返答はセンダーSMTPおよびレ シーバSMTPの両方が初期状態であることを確認する。すなわち、 進行中のトランザクションはなく、また全ての状態テーブルお よび・バッファはクリアされる。 MAIL (MAIL) このコマンドはメールデータを一つ以上のメールボックスへ配 達するメールトランザクションを開始するために使用される。 引数フィールドにはリバースパスが入る。 リバースパスはホストの任意のリストと発送したユーザのメー ルボックスからなる。ホストのリストがあるとき、それは"逆" ソースルートであり、メールがリスト上の各々のホスト(リスト 上の最初のホストが最近の中継SMTPサーバだった)を通過して中 継されたことを示している。このリストは、発送したユーザへ 不配達通知を返すためのソースルートとして使用される。各中 継ホストがリストの先頭へそれ自身を加えるときに、メールが やって来るIPCEよりむしろメールを中継する先へのIPCE中にお いて知られているそれの名前を使用しなければならない(もしそ れらが異なるならば)。エラー報告メッセージのいくつかの型 (例えば、配達不可能なメールの通知)において、リバースパス は空かもしれない(例 7 を見よ)。 このコマンドは、リバースパス・バッファ、フォワードパス・ バッファおよびメールデータ・バッファをクリアする; そして このコマンドからのリバースパス情報をリバースパス・バッ ファの中へ挿入する。 RECIPIENT (RCPT) このコマンドはメールデータの個々の受取人を識別するために 使用される; 複数の受取人はこのコマンドを複数回使用するこ とで指定される。 フォワードパスはホストの任意のリストと発送したユーザの メールボックスからなる。ホストのリストがあるとき、それは ソースルートであり、メールがリスト上の次のホストへ中継さ れさればならないことを示している。レシーバSMTPが中継機能 をインプリメントしないならば、それは未知のローカルのユー ザについての返答(550)と同じ返答を使用するだろう。 メールが中継されるとき、中継ホストはフォワードパスの先頭 からそれ自身を取り除き、リバースパスの先頭にそれ自身を置 かなければならない。メールがその最終目的地(フォワードパス には送り先メールボックスのみが入る)に届いたとき、レシーバ SMTPはそのホストのメールの慣習に従って送り先メールボック スの中にそれを挿入する。 例えば、次の引数とともに中継ホストAで受け取られたメー ルは、 FROM: TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA> 次の引数とともにホストB上へ中継されるだろう。 FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA> TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>. このコマンドによって、これのフォワードパスはフォワードパ ス・バッファへ追加される。 DATA (DATA) レシーバは、センダーからのメールデータとしてこのコマンド に続く行を取り扱う。このコマンドによって、このコマンドか らのメールデータはメールデータ・バッファへ追加される。 メールデータは128種のASCII文字コードのいくつかを含んでい る。 メールデータはピリオドだけを含んでいる行、つまり文字シー ケンス"."(セクション 4.5.2 透過を見よ)によっ ておわる。これはメールデータ終端表示です。 メールデータ終端表示は、レシーバが格納されたメールトラン ザクション情報をいま処理しなければならないことを要求する。 この処理はリバースパス・バッファ、フォワードパス・バッ ファおよびメールデータ・バッファの情報を消費する。そして、 このコマンドの完了したときこれらの・バッファはクリアされ る。処理が成功したならば、レシーバはOK返答を送らなければ ならない。処理が完全に失敗したならば、レシーバは失敗返答 を送らなければならない。 レシーバSMTPは中継するためのあるいは最終配送するための メッセージを受理するとき、それはメールデータの先頭にタイ ムスタンプ行を挿入する。タイムスタンプ行はメッセージを 送ったホストの素性、およびメッセージを受け取った(そして このタイムスタンプを挿入している)ホストの素性、およびメッ セージを受け取った日付と時間を明示する。中継されたメッ セージは複数のタイムスタンプ行を持つだろう。 レシーバSMTPがメッセージの"最終配送(final delivery)"をす るとき、それはメールデータの先頭へリターンパス行を挿入す る。リターンパス行はMAILコマンドから中の情 報を保護する。ここで、最終配送はメッセージがSMTPの世界か ら離れることを意味する。通常、この言葉は、それが送り先の ユーザへ配達されたことを意味する。しかしある場合には、そ れがある他のメールシステムによってさらに処理され送信され るかもしれない。 リターンパス中のメールボックスは実際の発送したユーザの メールボックスと異なることは可能です。例えば、エラー応 答が配達されるならば、メッセージを差し出したユーザより むしろ特別のエラーを取り扱うメールボックスへ。 前の二つのパラグラフは、最終的なメールデータはリターンパ ス行で始まり一行以上のタイムスタンプ行が続くだろうという ことを暗示する。これらの行の後に、メールデータのヘッダお よび本文[2]が続くだろう。例 8 を見よ。 メールデータ終端表示に続く処理が部分的に成功したときの応 答およびさらなる要求される動作について特記する必要がある。 数人の受取人とメールデータを受理した後で、レシーバSMTPは 受取人の内の数人には成功裡に配送することができたが他の受 取人にはできなかったこと(例えば、メールボックスの割り付け スペース問題)を知ったばらば、これは発生するかもしれない。 そのような状況においてDATAコマンドへの応答はOK 返答である に違いない。しかし、レシーバSMTPは"配達不可能なメール"通 知メッセージを構成しそのメッセージの発送したユーザへ送る。 メッセージを得ることを失敗した受取人の全てをリストした単 一のメッセージ、または個別のメッセージのいずれかは各々の 失敗した受取人について送られなければならない(例 7 を見よ)。 全ての配達不可能なメールの通知メッセージはMAILコマンドを 使用して送られる(それが、SEND, SOMLあるいはSAMLコマンドの 処理に起因しても)。 ------------------------------------------------------------- リターンパスおよびタイムスタンプの例 Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA> Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST Date: 27 Oct 81 15:01:01 PST From: JOE@ABC.ARPA Subject: Improved Mailing System Installed To: SAM@JKL.ARPA This is to inform you that ... 例 8 ------------------------------------------------------------- SEND (SEND) このコマンドは、メールデータを一つ以上の端末へ配達する メールトランザクションを開始するために使用される。引数 フィールドにはリバースパスが入る。メッセージが端末へ配達 されたならば、このコマンドは成功する。 リバースパスはホストの任意のリストと差し出したユーザの メールボックスからなる。ホストのリストがあるとき、それは "逆"ソースであり、メールがリスト上の各々のホスト(リスト上 の最初のホストが最近の中継SMTPサーバだった)を通過して中継 されたことを示している。このリストは、差し出したユーザへ 不配達通知を返すためのソースルートとして使用される。各中 継ホストがリストの先頭へそれ自身を加えるときに、メールが やって来るIPCEよりむしろメールを中継する先へのIPCE中にお いて知られているそれの名前を使用しなければならない(もしそ れらが異なるならば)。 このコマンドはリバースパス・バッファ、フォワードパス・ バッファおよびメールデータ・バッファをクリアする; そして このコマンドからのリバースパス情報をリバースパス・バッ ファの中へ挿入する。 SEND OR MAIL (SOML) このコマンドは、メールデータを一つ以上の端末あるいはメー ルボックスへ配達するメールトランザクションを開始するため に使用される。各々の受取人のためにメールデータを、受取人 がホスト上でアクティブ(かつ端末のメッセージを受理する)な らば受取人の端末へ、そうでなければ受取人のメールボックス へ配達する。引数フィールドにはリバースパスが入る。メッ セージが端末へ配達されたならば、このコマンドは成功する。 リバースパスはホストの任意のリストと差し出したユーザの メールボックスからなる。ホストのリストがあるとき、それは "逆"ソースルートであり、メールがリスト上の各々のホスト(リ スト上の最初のホストが最近の中継SMTPサーバだった)を通過し て中継されたことを示している。このリストは、差し出した ユーザへ不配達通知を返すためのソースルートとして使用され る。各中継ホストがリストの先頭へそれ自身を加えるときに、 メールがやって来るIPCEよりむしろメールを中継する先への IPCE中において知られているそれの名前を使用しなければなら ない(もしそれらが異なるならば)。 このコマンドはリバースパス・バッファ、フォワードパス・ バッファおよびメールデータ・バッファをクリアする; そして このコマンドからのリバースパス情報をリバースパス・バッ ファの中へ挿入する。 SEND AND MAIL (SAML) このコマンドは、メールデータを一つ以上の端末およびメール ボックスへ配達するメールトランザクションを開始するために 使用される。各々の受取人のためにメールデータを、受取人が ホスト上でアクティブ(かつ端末のメッセージを受理する)なら ば受取人の端末へ、また全ての受取人のメールボックスへ配達 する。引数フィールドにはリバースパスが入る。メッセージが 端末へ配達されたならば、このコマンドは成功する。 リバースパスはホストの任意のリストと差し出したユーザの メールボックスからなる。ホストのリストがあるとき、それは "逆"ソースルートであり、メールがリスト上の各々のホスト(リ スト上の最初のホストが最新の中継SMTPサーバだった)を通過し て中継されたことを示している。このリストは、差し出した ユーザへ不配達通知を返すためのソースルートとして使用され る。各中継ホストがリストの先頭へそれ自身を加えるときに、 メールがやって来るIPCEよりむしろメールを中継する先への IPCE中において知られているそれの名前を使用しなければなら ない(もしそれらが異なるならば)。 このコマンドはリバースパス・バッファ、フォワードパス・ バッファおよびメールデータ・バッファをクリアする; そして このコマンドからのリバースパス情報をリバースパス・バッ ファの中へ挿入する。 RESET (RSET) このコマンドは現在のメールトランザクションが異常終了され ることを指定します。いかなる格納された差出人、受取人、お よびメールデータも破棄されなければならない。また、全ての バッファおよび状態テーブルはクリアされる。レシーバはOK 返 答を送らなければならない。 VERIFY (VRFY) このコマンドはレシーバに引数がユーザを識別すること確認し てくれるよう依頼する。もしそれがユーザ名であれば、ユーザ のフルネーム(知っていれば)および十分に詳述されたメール ボックスを返す。 このコマンドはリバースパス・バッファ、フォワードパス・ バッファあるいはメールデータ・バッファのいかなるものにも 全く効果がない。 EXPAND (EXPN) このコマンドはレシーバに引数がメーリングリストを識別する と確認してくれるよう依頼する。もしそうであれば、そのリス トのメンバを返す。ユーザのフルネーム(知っていれば)および 十分に詳述されたメールボックスを複数行の返答で返す。 このコマンドはリバースパス・バッファ、フォワードパス・ バッファあるいはメールデータ・バッファのいかなるものにも 全く効果がない。 HELP (HELP) このコマンドによって、レシーバはHELPコマンドのセンダーへ ヘルプ情報を送らせる。このコマンドは引数(例、任意のコマン ド名)をとり、応答としてより詳細な情報を返すかもしれない。 このコマンドはリバースパス・バッファ、フォワードパス・ バッファあるいはメールデータ・バッファのいかなるものにも 全く効果がない。 NOOP (NOOP) このコマンドはいかなるパラメータあるいは以前に入力された コマンドに全く影響しない。それは、レシーバがOK 返答を送る 以外の動作を指定しない。 このコマンドはリバースパス・バッファ、フォワードパス・ バッファあるいはメールデータ・バッファのいかなるものにも 全く効果がない。 QUIT (QUIT) このコマンドは、レシーバがOK 返答を送らなければならず、そ の後、送信チャンネルを閉じなければならないことを指定する。 レシーバはQUITコマンドを受け取り、返答するまで(エラーが あったとしても)送信チャンネルを閉じるべきでない。センダー はQUITコマンドを送り、返答を受け取るまで(前のコマンドに対 するエラーが応答があったとしても)送信チャンネルを閉じるべ きでない。もし接続が時期尚早に閉じたならば、レシーバは、 あたかもRSETコマンドを受け取ったかのように(いかなる未完了 のトランザクションも取り消すが、いかなる以前に完了したト ランザクションは全く元に戻さない)行動するべきです。セン ダーは、あたかもコマンドあるいは進行中のトランザクション が一時的エラー(4xx)を受け取ったかのように動作するべきです。 TURN (TURN) このコマンドは、レシーバSMTPは、(1) OK 返答を送りその後セ ンダーSMTPの役割を引き受けなければならない。あるいは、(2) 拒否返答を送りまたレシーバSMTPの役割を保持しなければなら ない。のいずれかを指定する。 プログラム-Aは現在センダーSMTPであり、TURNコマンドを送り、 そして、OK 返答(250)を受け取るならば、プログラム-Aはレ シーバになる。プログラム-Aはその後あたかも送信チャンネル をちょうど開いたかのように初期状態にあり、またそして、そ れは 220サービスレディ・グリーティングを送る。 プログラム-Bは現在レシーバSMTPであり、TURNコマンドを受け 取り、そして、OK 返答(250)を送るならば、プログラム-Bはセ ンダーSMTPになる。プログラム-Bはその後あたかも送信チャン ネルをちょうど開いたかのように初期状態にあり、またそして、 それは 220サービスレディ・グリーティングを受け取ることを 期待する。 役割の交替を拒絶するためにレシーバは 502 返答を送る。 これらのコマンドは使用されるかもしれないときのこれらの順序に は制限がある。 セッションの最初のコマンドはHELOコマンドでなければならな い。HELOコマンドはその後もセッション中で同様に使用される かもしれない。HELOコマンド引数は受理可能でなければ、501 失敗返答を返さなければならない。また、レシーバSMTPは同じ 状態でとどまるに違いない。 NOOP, HELP, EXPNおよびVERFコマンドはセッション中いつでも 使用することができる。 MAIL,SEND,SOMLあるいはSAMLコマンドはメール処理を始める。 一度始められたメールトランザクションは、トランザクション 開始コマンドの中の一つ、一つ以上のRCPTコマンド、そして、 DATAコマンドからその順序で成る。メール処理は、RSETコマン ドによって異常終了するかもしれない。セッションにはゼロ個 以上の処理があるかもしれない。 トランザクションの始まりのコマンド引数が受理可能でないな らば、501 失敗返答を返さなければならない。また、レシーバ SMTPは同じ状態でとどまるに違いない。トランザクション中の コマンドが順序が出鱈目ならば、503 失敗返答を返さなければ ならない。また、レシーバSMTPは同じ状態でとどまるに違いな い。 セッションの最後のコマンドはQUITコマンドでなければならな い。QUITコマンドはセッションの他のところでは使用すること ができない。 4.1.2. コマンドの構文 コマンドは、引数フィールドが続くコマンドコードから成る。コマ ンドコードはアルファベト四文字です。大文字および小文字のアル ファベト文字は同一に取り扱われる。したがって、下記のいかなる ものも"メール"コマンドを表すかもしれない: MAIL Mail mail MaIl mAIl これはまた、フォワードパスの"TO"または"to"のような、パラメタ 値を示す任意のシンボルに当てはまる。コマンドコードおよび引数 フィールドは一つ以上のスペースによって区切られる。しかしなが ら、リバースパスおよびフォワードパスの引数では大文字と小文字 の区別は重要です。特に、いくつかのホストではユーザ "smith"は ユーザ "Smith"とは異なる。 引数フィールドは、文字シーケンスでおわる可変長の文字列 から成る。レシーバはこのシーケンスを受け取るまで行動を起こさ ないはずです。 角括弧は選択可能な引数フィールドを表す。オプションが使われな ければなければ、適切なデフォルトを意味する。 以下はSMTPコマンドです: HELO MAIL FROM: RCPT TO: DATA RSET SEND FROM: SOML FROM: SAML FROM: VRFY EXPN HELP [ ] NOOP QUIT TURN 上記の引数フィールドの構文は(適用可能なところは、BNF記法を使 用する)以下に与えられる。"..."表記は、フィールドが1回以上繰 り返されるかもしれないことを示す。 ::= ::= ::= "<" [ ":" ] ">" ::= | "," ::= "@" ::= | "." ::= | "#" | "[" "]" ::= "@" ::= | ::= ::= | ::= | ::= | | "-" ::= | "." ::= | ::= """ """ ::= "\" | "\" | | ::= | "\" ::= "." "." "." ::= | ::= ::= 復帰文字(ASCIIコード 13) ::= 改行文字(ASCIIコード 10) ::= スペース文字(ASCIIコード 32) ::= 範囲 0から255までの10進数の整数値を表す一,二あ るいは三桁の数字。 ::= 大文字AからZまで、および小文字aからzまでの52種 のアルファベット文字のいずれか一つ。 ::= 128種のASCII文字のいずれか一つ、しかし、 あるいはではないもの。 ::= 0から9までの十個の数字のいずれか一つ。 ::= , , クォート("),あるいはバックスラッシュ(\) 以外の128種のASCII文字のいずれか一つ。 ::= 128種のASCII文字のいずれか一つ(例外なし)。 ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." | "," | ";" | ":" | "@" """ | コントロール文 字(ASCIIコード 0から31まで、および127) バックスラッシュ "\" は、次の文字が文字通り(それの通常の解釈 のかわりに)に使用されることを示すために使用されるクォート文 字です。例えば、"Joe\,Smith"はフィールドの四文字目がカンマで ある九文字のユーザフィールドを表している。 ホストは各ホストでアドレスに変換される名前により一般に知られ ている。ドメインの名前の要素は公式名称であることに注意してく ださい -- ニックネームあるいはエリアスの使用は許されない。 時々、ホストはアドレス変換機能に知られていなく、通信が妨げら れる。この障害を回避するためにホスト"名"に二つの数値形式がさ らに許されている。一つの形式は、ポンド記号 "#" を前につけた 10進整数でこれは数値がホストのアドレスを表しています。もう一 つの形式は、ドットで区切られブラケットで囲まれた四つの小さな 10進整数で、例 "[123.255.37.2]"、これは四つの8-bitフィールド による32-bit ARPAインターネットアドレスを表している。 タイムスタンプ行およびリターンパス行は以下のように形式的に 定義される: ::= "Return-Path:" ::= "Received:" ::= ";" ::= "FROM" ::= "BY" ::= [] [] [] [] ::= "VIA" ::= "WITH" ::= "ID" ::= "FOR" ::= リンクの標準的な名前は Network Infomation Center で登録される ::= プロトコルの標準的な名前は Network Infomation Center で登録される ::=