Rfc821

このファイルは 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文字
は上位ビットをゼロにクリアされたオクテットにちょうど正当化されて送
信される。

コマンドあるいは返答の一般的な形式を指定するとき、引数(あるいは特
殊なシンボル)は、メタ言語の変数(または定数)です。例えば"<string>"
あるいは"<reverse-path>"。ここのアングルブランケットはこれらがメタ
言語の変数であることを示す。しかしながら、いくつかの引数ではアング
ルブランケットを文字通りに使用する。例えば、実際のリバースパスはア
ングルブランケットで囲まれる、つまり、"<APRA.ISI-CSU|htimS.nhoJ#APRA.ISI-CSU|htimS.nhoJ>"
は<reverse-path>の実例である(アングルブランケットはコマンドまたは
返答中で現実に送信される)。

3. SMTPの手続き

このセクションではいくつかのパートでSMTPの中で使用される手続きを提
示する。はじめにメールトランザクションとして定義された基本的なメー
ル手続きがくる。これに続くのはメールの転送、メールボックス名の確認
およびメーリングリストの展開、メールボックスの代わりにあるいはその
メールボックスと組み合わせて端末へ送ること、および(メールの)交換の
開始および終了に関する記述です。このセクションの終わりに中継につい
ての解説、メールドメインに関する注釈、および役割の交替の議論がある。
このセクションのいたるところにコマンドと返答のシーケンスの部分的な
例がある。完全なシナリオは付録 Fの中で提示する。

3.1. メール

SMTPメールトランザクションには三つのステップがある。このトラン
ザクションはセンダー識別を与えるMAILコマンドで始められる。一連
の一つ以上のRCPTコマンドはレシーバ情報を与えながら続く。その後、
DATAコマンドはメールデータを与える。最後に、メールデータ終端表
示子(end of mail data indicator)はこの処理を確認する。

手続きの第一のステップはMAILコマンドです。<reverse-path>には
送り元のメールボックスが入る。

MAIL <SP> FROM:<reverse-path> <CRLF>

このコマンドは、新しいメールトランザクションを開始することそ
して受取人あるいはメールデータを含むその状態テーブルおよび
バッファをすべてリセットすることをSMTPレシーバに伝える。それ
は、エラーを報告するために使用することができるリバースパスを
与える。もし受理したならば、レシーバSMTPは250 OK返答を返す。

<reverse-path>は、メールボックスだけでなくより多くのものを入
れることができる。<reverse-path>は送り元メールボックスおよび
ホストの逆のソースルーティングリストです。<reverse-path>中の
最初のホストはこのコマンドを送るホストであるべきです。

手続きの第二のステップはRCPTコマンドです。

RCPT <SP> TO:<forward-path> <CRLF>

このコマンドは1人の受取人を識別するフォワードパスを与える。
もし受理されれば、レシーバSMTPは250 OK返答を返し、フォワード
パスを格納する。受取人が未知ならば、550 失敗返答を返す。この
手続きの第二のステップは何度も繰り返すことができる。

<forward-path>は、メールボックスだけでなくより多くのものを入
れることができる。<forward-path>はホストおよび送り先メール
ボックスのソースルーティングリストです。<forward-path>中の最
初のホストはこのコマンドを受け取るホストであるべきです。

手続きの第三のステップはDATAコマンドです。

DATA <CRLF>

もし受理されれば、レシーバ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:<APRA.ahplA|htimS#APRA.ahplA|htimS>
R: 250 OK

S: RCPT TO:<APRA.ateB|senoJ#APRA.ateB|senoJ>
R: 250 OK

S: RCPT TO:<APRA.ateB|neerG#APRA.ateB|neerG>
R: 550 No such user here

S: RCPT TO:<APRA.ateB|nworB#APRA.ateB|nworB>
R: 250 OK

S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah…
S: …etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 OK

メールは JonesとBrownのがいま受理された。GreenはホストBeta
にメールボックスを持っていなかった。

例 1

-------------

3.2. 転送

<forward-path>中の送り先情報が正しくないがレシーバSMTPは正しい
送り先を知っている場合がいくつかある。そのような場合、次の返答
のうちの一つはセンダーに正しい送り先と連絡することを許すために
使用されるべきです。

251 User not local; will forward to <forward-path>

この返答はレシーバSMTPがユーザのメールボックスがある他の
ホスト上にあることを知っていることを示し、以後正しいフォ
ワードパスを使用することを示す。ホストあるいはユーザのい
ずれかあるいはその両方が異なるかもしれないことに注意して
ください。レシーバはメッセージの配送に対して責任を負う。

551 User not local; please try <forward-path>

この返答はレシーバSMTPがユーザのメールボックスがある他の
ホスト上にあることを知っていることを示し、正しいフォワー
ドパスを使用することを示す。ホストあるいはユーザのいずれ
かあるいはその両方が異なるかもしれないことに注意してくだ
さい。レシーバは、このユーザへのメールの受理を拒絶する。
また、センダーは提供された情報に従ってメールを転送するか、
メールを差し出したユーザへエラー応答を返すかのいずれかで
なければならない。

例 2 はこれらの応答の使用を例示する。

-------------

転送の例

S: RCPT TO:<APRA.ISI-CSU|letsoP#APRA.ISI-CSU|letsoP>
R: 251 User not local; will forward to <APRA.FISI-CSU|letsoP#APRA.FISI-CSU|letsoP>

または

S: RCPT TO:<APRA.BISI-CSU|luaP#APRA.BISI-CSU|luaP>
R: 551 User not local; please try <APRA.FISI-CSU|sirtepakcoM#APRA.FISI-CSU|sirtepakcoM>

のいずれか

例 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 <APRA.FISI-CSU|htimS#APRA.FISI-CSU|htimS>

または

S: VRFY Smith
R: 251 User not local; will forward to <APRA.QISI-CSU|htimS#APRA.QISI-CSU|htimS>

または

S: VRFY Jones
R: 550 String does not match anything.

または

S: VRFY Jones
R: 551 User not local; please try <APRA.QISI-CSU|senoJ#APRA.QISI-CSU|senoJ>

または

S: VRFY Gourzenkyinplatz
R: 553 User ambiguous.

のいずれか

例 3

-------------

例 4 において示されるように、メーリングリストを展開する場合は
複数行の返答を要求する。

-------------

メーリングリストを展開する例

S: EXPN Example-People
R: 250-Jon Postel <APRA.FISI-CSU|letsoP#APRA.FISI-CSU|letsoP>
R: 250-Fred Fonebone <APRA.QISI-CSU|enobenoF#APRA.QISI-CSU|enobenoF>
R: 250-Sam Q. Smith <APRA.QISI-CSU|htimSQS#APRA.QISI-CSU|htimSQS>
R: 250-Quincy Smith <@USC-ISIF.ARPA:APRA.AXAV-ISI|htimS-Q#APRA.AXAV-ISI|htimS-Q>
R: 250-<APRA.xinu-oof|eoj#APRA.xinu-oof|eoj>
R: 250 <APRA.xinu-rab|zyx#APRA.xinu-rab|zyx>

または

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 <SP> FROM:<reverse-path> <CRLF>

SENDコマンドはメールデータがユーザのターミナルへ配達され
ることを要求する。ユーザがホスト上でアクティブでない(ある
いは端末のメッセージを受理しない)ならば、450 返答はRCPTコ
マンドに対して返されるかもしれない。メッセージが端末へ配
達されるならば、メールトランザクションは成功する。

SOML <SP> FROM:<reverse-path> <CRLF>

SOML(Send Or MaiL)コマンドはユーザがホスト上でアクティブ
(かつ端末のメッセージを受理する)ならば、メッセージがユー
ザの端末へ配達されることを要求する。ユーザがアクティブで
ない(あるいは端末のメッセージを受理しない)ならば、メール
データがユーザのメールボックスに入れられる。メッセージが
端末あるいはメールボックスのいずれかへ配達されるならば、
メールトランザクションは成功する。

SAML <SP> FROM:<reverse-path> <CRLF>

SAML(Send And MaiL)コマンドはユーザがホスト上でアクティブ
で(かつ端末のメッセージを受理する)ならば、メッセージが
ユーザの端末へ配達されることを要求する。いかなる場合でも
メールデータはメールボックスに入れられる。メッセージが
メールボックスへ配達されるならば、メールトランザクション
は成功する。

MAILコマンドに使用されるのと同じ返答コードがこれらのコマンドに
使用される。

3.5. 開始と終了

送信チャンネルが開いているそのときに、ホストがそれらが思ってい
るホストと通信していることを保証するためのやり取りがある。

次の二つのコマンドは送信チャンネルの開放と閉鎖に使われる:

HELO <SP> <domain> <CRLF>

QUIT <CRLF>

HELOコマンドでは、コマンドを送るホスト自身を識別する; コマンド
は"Hello, I am <domain>"といっていると解釈されるかもしれない。

-------------

接続開始の例

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:APRA.WTSOH|EOJ#APRA.WTSOH|EOJ>
R: 250 ok
S: DATA
R: 354 send the mail data, end with .
S: Date: 23 Oct 81 11:22:33
S: From: APRA.YTSOH|PTMS#APRA.YTSOH|PTMS
S: To: APRA.WTSOH|EOJ#APRA.WTSOH|EOJ
S: Subject: Mail System Problem
S:
S: Sorry JOE, your message to APRA.ZTSOH|MAS#APRA.ZTSOH|MAS 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コマンドは<CRLF>によって終わ
る文字列です。コマンドコード自身はパラメータが続くばらば<SP>
で、そうでなければ<CRLF>で終わるアルファベット文字列です。
メールボックスの構文はレシーバサイトの慣習に合わせなければな
らない。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:<APRA.YTSOH|XRESU#APRA.YTSOH|XRESU>
TO:<@HOSTA.ARPA,@HOSTB.ARPA:APRA.DTSOH|CRESU#APRA.DTSOH|CRESU>

次の引数とともにホストB上へ中継されるだろう。

FROM:<@HOSTA.ARPA:APRA.YTSOH|XRESU#APRA.YTSOH|XRESU>
TO:<@HOSTB.ARPA:APRA.DTSOH|CRESU#APRA.DTSOH|CRESU>.

このコマンドによって、これのフォワードパスはフォワードパ
ス・バッファへ追加される。

DATA (DATA)

レシーバは、センダーからのメールデータとしてこのコマンド
に続く行を取り扱う。このコマンドによって、このコマンドか
らのメールデータはメールデータ・バッファへ追加される。
メールデータは128種のASCII文字コードのいくつかを含んでい
る。

メールデータはピリオドだけを含んでいる行、つまり文字シー
ケンス"<CRLF>.<CRLF>"(セクション 4.5.2 透過を見よ)によっ
ておわる。これはメールデータ終端表示です。

メールデータ終端表示は、レシーバが格納されたメールトラン
ザクション情報をいま処理しなければならないことを要求する。
この処理はリバースパス・バッファ、フォワードパス・バッ
ファおよびメールデータ・バッファの情報を消費する。そして、
このコマンドの完了したときこれらの・バッファはクリアされ
る。処理が成功したならば、レシーバはOK返答を送らなければ
ならない。処理が完全に失敗したならば、レシーバは失敗返答
を送らなければならない。

レシーバSMTPは中継するためのあるいは最終配送するための
メッセージを受理するとき、それはメールデータの先頭にタイ
ムスタンプ行を挿入する。タイムスタンプ行はメッセージを
送ったホストの素性、およびメッセージを受け取った(そして
このタイムスタンプを挿入している)ホストの素性、およびメッ
セージを受け取った日付と時間を明示する。中継されたメッ
セージは複数のタイムスタンプ行を持つだろう。

レシーバSMTPがメッセージの"最終配送(final delivery)"をす
るとき、それはメールデータの先頭へリターンパス行を挿入す
る。リターンパス行はMAILコマンドから<reverse-path>中の情
報を保護する。ここで、最終配送はメッセージがSMTPの世界か
ら離れることを意味する。通常、この言葉は、それが送り先の
ユーザへ配達されたことを意味する。しかしある場合には、そ
れがある他のメールシステムによってさらに処理され送信され
るかもしれない。

リターンパス中のメールボックスは実際の発送したユーザの
メールボックスと異なることは可能です。例えば、エラー応
答が配達されるならば、メッセージを差し出したユーザより
むしろ特別のエラーを取り扱うメールボックスへ。

前の二つのパラグラフは、最終的なメールデータはリターンパ
ス行で始まり一行以上のタイムスタンプ行が続くだろうという
ことを暗示する。これらの行の後に、メールデータのヘッダお
よび本文[2]が続くだろう。例 8 を見よ。

メールデータ終端表示に続く処理が部分的に成功したときの応
答およびさらなる要求される動作について特記する必要がある。
数人の受取人とメールデータを受理した後で、レシーバSMTPは
受取人の内の数人には成功裡に配送することができたが他の受
取人にはできなかったこと(例えば、メールボックスの割り付け
スペース問題)を知ったばらば、これは発生するかもしれない。
そのような状況においてDATAコマンドへの応答はOK 返答である
に違いない。しかし、レシーバSMTPは"配達不可能なメール"通
知メッセージを構成しそのメッセージの発送したユーザへ送る。
メッセージを得ることを失敗した受取人の全てをリストした単
一のメッセージ、または個別のメッセージのいずれかは各々の
失敗した受取人について送られなければならない(例 7 を見よ)。
全ての配達不可能なメールの通知メッセージはMAILコマンドを
使用して送られる(それが、SEND, SOMLあるいはSAMLコマンドの
処理に起因しても)。

-------------

リターンパスおよびタイムスタンプの例

Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:APRA.CBA|EOJ#APRA.CBA|EOJ>
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: APRA.CBA|EOJ#APRA.CBA|EOJ
Subject: Improved Mailing System Installed
To: APRA.LKJ|MAS#APRA.LKJ|MAS

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"とは異なる。

引数フィールドは、文字シーケンス<CRLF>でおわる可変長の文字列
から成る。レシーバはこのシーケンスを受け取るまで行動を起こさ
ないはずです。

角括弧は選択可能な引数フィールドを表す。オプションが使われな
ければなければ、適切なデフォルトを意味する。

以下はSMTPコマンドです:

HELO <SP> <domain> <CRLF>

MAIL <SP> FROM:<reverse-path> <CRLF>

RCPT <SP> TO:<forward-path> <CRLF>

DATA <CRLF>

RSET <CRLF>

SEND <SP> FROM:<reverse-path> <CRLF>

SOML <SP> FROM:<reverse-path> <CRLF>

SAML <SP> FROM:<reverse-path> <CRLF>

VRFY <SP> <string> <CRLF>

EXPN <SP> <string> <CRLF>

HELP [<SP> <string>] <CRLF>

NOOP <CRLF>

QUIT <CRLF>

TURN <CRLF>

上記の引数フィールドの構文は(適用可能なところは、BNF記法を使
用する)以下に与えられる。"…"表記は、フィールドが1回以上繰
り返されるかもしれないことを示す。

<reverse-path> ::= <path>

<forward-path> ::= <path>

<path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"

<a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>

<at-domain> ::= "@" <domain>

<domain> ::= <element> | <element> "." <domain>

<element> ::= <name> | "#" <number> | "[" <dotnum> "]"

<mailbox> ::= <local-part> "@" <domain>

<local-part> ::= <dot-string> | <quoted-string>

<name> ::= <a> <ldh-str> <let-dig>

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig> ::= <a> | <d>

<let-dig-hyp> ::= <a> | <d> | "-"

<dot-string> ::= <string> | <string> "." <dot-string>

<string> ::= <char> | <char> <string>

<quoted-string> ::= """ <qtext> """

<qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>

<char> ::= <c> | "\" <x>

<dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>

<number> ::= <d> | <d> <number>

<CRLF> ::= <CR> <LF>

<CR> ::= 復帰文字(ASCIIコード 13)

<LF> ::= 改行文字(ASCIIコード 10)

<SP> ::= スペース文字(ASCIIコード 32)

<snum> ::= 範囲 0から255までの10進数の整数値を表す一,二あ
るいは三桁の数字。

<a> ::= 大文字AからZまで、および小文字aからzまでの52種
のアルファベット文字のいずれか一つ。

<c> ::= 128種のASCII文字のいずれか一つ、しかし、
<special>あるいは<SP>ではないもの。

<d> ::= 0から9までの十個の数字のいずれか一つ。

<q> ::= <CR>, <LF>, クォート("),あるいはバックスラッシュ(\)
以外の128種のASCII文字のいずれか一つ。

<x> ::= 128種のASCII文字のいずれか一つ(例外なし)。

<special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
| "," | ";" | ":" | "@" """ | コントロール文
字(ASCIIコード 0から31まで、および127)

バックスラッシュ "\" は、次の文字が文字通り(それの通常の解釈
のかわりに)に使用されることを示すために使用されるクォート文
字です。例えば、"Joe\,Smith"はフィールドの四文字目がカンマで
ある九文字のユーザフィールドを表している。

ホストは各ホストでアドレスに変換される名前により一般に知られ
ている。ドメインの名前の要素は公式名称であることに注意してく
ださい — ニックネームあるいはエリアスの使用は許されない。

時々、ホストはアドレス変換機能に知られていなく、通信が妨げら
れる。この障害を回避するためにホスト"名"に二つの数値形式がさ
らに許されている。一つの形式は、ポンド記号 "#" を前につけた
10進整数でこれは数値がホストのアドレスを表しています。もう一
つの形式は、ドットで区切られブラケットで囲まれた四つの小さな
10進整数で、例 "[123.255.37.2]"、これは四つの8-bitフィールド
による32-bit ARPAインターネットアドレスを表している。

タイムスタンプ行およびリターンパス行は以下のように形式的に
定義される:

<return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>

<time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>

<stamp> ::= <from-domain> <by-domain> <opt-info> ";"
<daytime>

<from-domain> ::= "FROM" <SP> <domain> <SP>

<by-domain> ::= "BY" <SP> <domain> <SP>

<opt-info> ::= [<via>] [<with>] [<id>] [<for>]

<via> ::= "VIA" <SP> <link> <SP>

<with> ::= "WITH" <SP> <protocol> <SP>

<id> ::= "ID" <SP> <string> <SP>

<for> ::= "FOR" <SP> <path> <SP>

<link> ::= リンクの標準的な名前は Network Infomation Center
で登録される

<protocol> ::= プロトコルの標準的な名前は Network Infomation
Center で登録される

<daytime> ::= <SP> <date> <SP> <time>

<date> ::= <dd> <SP> <mon> <SP> <yy>

<time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>

<dd> ::= 範囲1から31までの日を表す一または二桁の10進整数。

<mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
"JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"

<yy> ::= 範囲00から99までの年を表す二桁の10進整数。

<hh> ::= 範囲00から24までの時を表す二桁の10進整数。

<mm> ::= 範囲00から59までの分を表す二桁の10進整数。

<ss> ::= 範囲00から59までの秒を表す二桁の10進整数。

<zone> ::= "UT" 世界時間(デフォルト)あるいはタイムゾーン
指定子([2]中のように).

-------------

リターンパスの例

Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:APRA.ELBA|EOJ#APRA.ELBA|EOJ>

例 9
-------------

-------------

タイムスタンプ行の例

Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT

Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
id M12345 for APRA.QDP|htimS#APRA.QDP|htimS ; 22 OCT 81 09:23:59 PDT

例 10

-------------

4.2. SMTP返答

SMTPコマンドへの返答は、メール転送の処理におけるリクエストおよ
び動作の同期を確実にし、センダーSMTPがレシーバSMTPの状態を常に
知っていることを保証するために考案された。どのコマンドもちょう
ど一つの返答を生成しなければならない。

コマンド-返答シーケンスの詳細は、セクション 5.3 シーケンシン
グ、およびセクション 5.4 状態ダイアグラムにおいて明示される。

SMTP返答はテキストが続く(三文字の英数字として送信される)三桁の
数から成る。この数はオートマトンによる使用に対して次にどの状態
に入るかを決定させるためのものです; 三桁の数が、センダーSMTPが
テキストを検査する必要のない、また適切に、それを廃棄するかユー
ザへ伝達するかのいずれかを行えるような十分に符号化された情報に
相当するように意図される。特に、テキストはレシーバ依存であり状
況依存であるかもしれず、各返答コードのためのテキストが変更され
るだろう。返答コードの理論についての議論は、付録 E のなかで与え
られる。形式的に、返答は次のシーケンスであると定義される: 三桁
コード, <SP>, 一行のテキスト, そして<CRLF>、あるいは、複数行の
返答(付録 E で義されるように)。EXPNおよびHELPコマンドだけは通常
の状況において結果が複数行の返答であると予想される。しかしなが
ら、複数行の返答は任意のコマンドにも許される。

4.2.1. 機能グループごとの返答コード

500 構文エラー、コマンドは認識できなかった。
[これは、コマンド行が長すぎるのようなエラーを
含むかもしれない]
501 パラメータあるいは引数における構文エラー。
502 インプリメントされていないコマンド。
503 不良なコマンドのシーケンス。
504 インプリメントされていないコマンドパラメータ。

211 システムステータス、あるいはシステムヘルプ返答。
214 ヘルプメッセージ。
[レシーバの使用法あるいは非標準コマンドの意味についての
情報; この返答は人間のユーザにとってのみ有用です]

220 <domain> サービス、用意。
221 <domain> サービス、送信チャンネル閉鎖。
421 <domain> サービス、利用不可能、送信チャンネル閉鎖。
[サービスが、それがシャットダウンするに違いないことを
知っているならば、これは、任意のコマンドへの返答である
かもしれない]

250 要求されたメール動作は承認、完了した。
251 ローカルのユーザでない; <forward-path>へ転送します。
450 要求されたメール動作は行われない: メールボックスは
利用不可能。 [例えば、メールボックス使用中]
550 要求されたメール動作は行われない: メールボックスは
利用不可能。 [例えば、メールボックスがみつからない、
アクセスできない]
451 要求されたメール動作は異常終了した: 処理中の
ローカルエラー。
551 ローカルでないユーザ; <forward-path>を試してください。
452 要求された動作は行われない: システムの記憶装置が不足。
552 要求されたメール動作は異常終了した: 超過した記憶割付け。
553 要求された動作は行われない: メールボックス名は許されない。
[例、不正なメールボックスの構文]
354 メールの入力を始めよ; <CRLF>.<CRLF>で終れ。
554 処理は失敗した。

4.2.2. 数値順の返答コード

211 システムステータス、あるいはシステムヘルプ返答。
214 ヘルプメッセージ。
[レシーバの使用法あるいは非標準コマンドの意味についての
情報; この返答は人間のユーザにとってのみ有用です]
220 <domain> サービス、用意。
221 <domain> サービス、送信チャンネル閉鎖。
250 要求されたメール動作は承認、完了した。
251 ローカルのユーザでない; <forward-path>へ転送します。

354 メールの入力を始めよ; <CRLF>.<CRLF>で終れ。

421 <domain> サービス、利用不可能、送信チャンネル閉鎖。
[サービスが、それがシャットダウンするに違いないことを
しっているならば、これは、任意のコマンドへの返答である
かもしれない]
450 要求されたメール動作は行われない: メールボックスは
利用不可能。 [例えば、メールボックス使用中]
451 要求されたメール動作は異常終了した: 処理中の
ローカルエラー。
452 要求された動作は行われない: システムの記憶装置が不足。

500 構文エラー、コマンドは認識できなかった。
[これは、コマンド行が長すぎるのようなエラーを
含むかもしれない]
501 パラメータあるいは引数における構文エラー。
502 インプリメントされていないコマンド。
503 不良なコマンドのシーケンス。
504 インプリメントされていないコマンドパラメータ。
550 要求されたメール動作は行われない:メールボックスは
利用不可能。 [例えば、メールボックスがみつからない、
アクセスできない]
551 ローカルでないユーザ; <forward-path>を試してください。
552 要求されたメール動作は異常終了した:超過した記憶割付け。
553 要求された動作は行われない: メールボックス名は許されない。
[例、不正なメールボックスの構文]
554 処理は失敗した。

4.3. コマンドと返答のシーケンシング

センダーとレシーバの間の通信は、センダーによって制御された交互
の対話であるように意図される。そういうものとして、センダーはコ
マンドを出し、そして、レシーバは返答で応じる。センダーはさらに
コマンドを送る前にこの応答を待たなければならない。

重要な返答の一つはコネクション・グリーティングです。接続が完了
したとき、通常、レシーバは 220 "Service ready"返答を送るだろう。
センダーは任意のコマンドを送る前にこのグリーティング・メッセー
ジを待つべきです。

注: 全てのグリーティング型返答は、返答コードに続く最初の単語
としてサーバホストの公式名称を持つ。

例えば、

220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF>

下のテーブルは、各コマンドについて交互に成功および失敗の返答を
表にしたものです。これらは厳密に固守されなければならない; レ
シーバは返答のテキストを代用するかもしれない。しかし、コード番
号および、特別なコマンド返答シーケンスにより示される、意味と動
作は変更することができない。

コマンド-返答のシーケンス

各コマンドはそれの可能な返答とともに表にされる。可能な返答の
まえで使用される接頭辞は、"P"予備(SMTPでは使用されない)、"I"
中間、"S"成功、"F"失敗、"E"エラーです。 421 返答(サービス利
用不可能、送信チャンネル閉鎖)は、SMTPサーバがシャットダウン
しなければならないことを知っているならば、任意のコマンドへ与
えられるかもしれない。この表の作成はセクション 4.4 の状態ダ
イヤグラムに基づいて構成した。

接続の確立
S: 220
F: 421
HELO
S: 250
E: 500, 501, 504, 421
MAIL
S: 250
F: 552, 451, 452
E: 500, 501, 421
RCPT
S: 250, 251
F: 550, 551, 552, 553, 450, 451, 452
E: 500, 501, 503, 421
DATA
I: 354 -> data -> S: 250
F: 552, 554, 451, 452
F: 451, 554
E: 500, 501, 503, 421
RSET
S: 250
E: 500, 501, 504, 421
SEND
S: 250
F: 552, 451, 452
E: 500, 501, 502, 421
SOML
S: 250
F: 552, 451, 452
E: 500, 501, 502, 421
SAML
S: 250
F: 552, 451, 452
E: 500, 501, 502, 421
VRFY
S: 250, 251
F: 550, 551, 553
E: 500, 501, 502, 504, 421
EXPN
S: 250
F: 550
E: 500, 501, 502, 504, 421
HELP
S: 211, 214
E: 500, 501, 502, 504, 421
NOOP
S: 250
E: 500, 421
QUIT
S: 221
E: 500
TURN
S: 250
F: 502
E: 500, 503

4.4. 状態ダイアグラム

以下のものは単純な動作をするSMTPインプリメンテーションついての
状態ダイアグラムです。返答コードの最初の数字のみが使用される。
各々のSMTPコマンドグループについて一つの状態ダイアグラムがある。
コマンドのグルーピングは各コマンドのモデルを構築し、そして構造
上同一のモデルをもつコマンドを集めることによって決定された。

各コマンドについて可能な三つの結果がある: "成功"(S), "失敗"(F),
および "エラー"(E)。下の状態ダイアグラムにおいて、シンボル B
"開始"、および W "待ち" を使用した。

はじめに、ほとんどのSMTPコマンドを表すダイアグラム:

1,3 +-+
-
-->| E |
| +
-+
|
+-+ cmd +-+ 2 +-+
| B |
-->| W |-->| S |
+
-+ +-+ +-+
|
| 4,5 +-+
-
-->| F |
+
-+

このダイアグラムは下のコマンドのモデルです:

HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP,
NOOP, QUIT, TURN.

より複雑なダイアグラムはDATAコマンドのモデルです:

+-+ DATA +-+ 1,2 +-+
| B |
-->| W |---->| E |
+
-+ +-+ --—>+-+
3| |4,5 |
| | |
--— -— |
| | | +-+
| -
--->| S |
| | | | +
-+
| | --
| | | |
V 1,3| |2 |
+
-+ data +-+ --->+-+
| |-->| W | | F |
+-+ +-+---->+—-+
4,5

"data"ここでは、最後の行が送られるまでセンダーから応答の
ないことが期待されるレシーバへ送られる一連の行です。

4.5. 詳細

4.5.1. 最小のインプリメンテーション

SMTPを動作させるために、以下の最小インプリメンテーションは全
てのレシーバに要求される。

COMMANDS — HELO
MAIL
RCPT
DATA
RSET
NOOP
QUIT

4.5.2. 透過

データの透過のためのいくつかの準備なしに、文字シーケンス
"<CRLF>.<CRLF>" はメールテキストを終わり、ユーザによって送ら
れることができない、一般に、ユーザはそのような"禁止"シーケン
スに気付いていない。全てのユーザが作成したテキストが透過的に
送信されることを許可するために、下記の手続きは使用される。

1. メールテキストを送る前にセンダーSMTPは行の最初の文字を
チェックする。もしそれがピリオドならば、付け加えるための
一つのピリオドは行の先頭に挿入される。

2. メールテキストの行がレシーバSMTPによって受け取られると
き、もし行が単一のピリオドから構成されるならば、それは
メールの終端です。最初の文字がピリオドでその行にほかに文
字があるならば、最初の文字は削除される。

メールデータは128種のASCII文字を含む。全ての文字はフォーマッ
トエフェクタおよび他のコントロール文字を含めて、受取人のメー
ルボックスへ配達されることになっている。送信チャンネルが8-
bitバイト(オクテット)データストリームを提供するなら、7-bit
ASCIIコードは上位ビットをゼロにクリアされたオクテットにちょ
うど正当化され送信される。

いくつかのシステムでは、それが受け取られ、また格納される
ようにデータを変換する必要があるかもしれない。これは、
ローカルな文字集合としてASCIIとは異なる文字集合を使用する、
あるいは、文字列よりむしろレコードでデータを格納するホス
トのために必要かもしれない。そのような変換が必要ならば、
それらは可逆的でなければならない — 特に、そのような変換
が中継されているメールに適用されるならば。

4.5.3. サイズ

最大最小のサイズを要求されるいくつかのオブジェクトがある。す
なわち、すべてのインプリメンテーションは、少なくともこれらの
サイズのオブジェクトを受け取ることができなければならない。し
かし、これらのサイズより大きいオブジェクトを送ってはならない。


* *
* 可能な最大の大きさに対して、これらのオブジェク *
* トの長さに制限を課さないインプリメンテーション *
* の技術は使用すべきです。 *
* *

ユーザ(user)

ユーザ名の最大の合計の長さは、64文字です。

ドメイン(domain)

ドメイン名あるいは数の最大の合計の長さは、64文字です。

パス(path)

リバースパスあるいはフォワードパスの最大の合計の長さ
は、256文字です(句読記号および要素区切り文字を含む)。

コマンド行(command line)

コマンド行の最大の合計の長さは、コマンド語および
<CRLF>を含めて、512文字です。

返答行(reply line)

返答行の最大の合計の長さは、返答コードおよび
<CRLF>を含めて、512文字です。

テキスト行(text line)

テキスト行の最大の合計の長さは、<CRLF>を含めて、
1000文字です(しかし、透過のために複写された先頭のドッ
トは数えない)。

受取人・バッファ(recipients buffer)

・バッファされなければならない受取人の最大の合計の数は、
100人分です


* *
* 可能な最大の大きさに対して、これらのオブジェク *
* トの長さに制限を課さないインプリメンテーション *
* の技術は使用すべきです。 *
* *

これらの制限を超過したことによるエラーは返答コードを使用する
ことによって報告されるかもしれない。

500 行が長すぎる。

501 パスが長すぎる。

552 受取人が多すぎる。

552 メールデータが大きすぎる

付録 A

TCP 輸送サービス

TCP(Transmission Control Protocol)[3]はARPAインターネット、およ
びアメリカ国防総省(US DoD)標準のネットワーク間のプロトコルに従
う任意のネットワークにおいて使用される。

接続の確立

SMTPの送信チャンネルは、センダープロセスのポートUとレシーバ
プロセスのポートLの間に確立されたTCP接続です。この単一の全二
重接続は送信チャンネルとして使用される。このプロトコルはサー
ビスポート 25 を割り当てられる。つまり、L=25です。

データの転送

TCP接続は、8-bitバイトの送信をサポートする。SMTPデータは 7-
bit ASCII文字です。各文字は上位ビットを0にクリアした 8-bitバ
イトとして送信される。

付録 B

NCP 輸送サービス

ARPANET Host-to-Host Protocol [4] (NCPによってインプリメントさ
れる)は、ARPANETにおいて使用されるかもしれない。

接続の確立

SMTPの送信チャンネルは、センダープロセスのソケットUとレシー
バプロセスのソケットLの間にNCPによって確立される。単信方式の
接続のペアに帰着して、Initial Connection Protocol [5] に従う。
この接続のペアは送信チャンネルとして使用される。このプロトコ
ルはサービスソケット 25 を割り当てられる。つまり、L=25です。

データの転送

NCP接続は、8-bitバイトモードで確立される。SMTPデータは 7-bit
ASCII文字です。各文字は上位ビットを0にクリアした 8-bitバイト
として送信される。

付録 C

NITS

ネットワーク独立輸送サービス(Network Independent Transport
Service)[6]は使用されるかもしれない。

接続の確立

SMTPの送信チャンネルは、センダープロセスとレシーバプロセスの
間にNITSを通して確立される。センダープロセスはCONNECTパーミ
ティブを実行し、待機しているレシーバプロセスはACCEPTパーミ
ティブを実行する。

データの転送

NITS接続は、8-bitバイトの送信をサポートする。SMTPデータは 7-
bit ASCII文字です。各文字は上位ビットを0にクリアした 8-bitバ
イトとして送信される。

付録 D

X.25 輸送サービス

直接、公衆データ網によって提供されるような X.25サービス[7]を使
用することは可能でしょう。しかしながら、TCPのような確実な端間プ
ロトコルは、X.25接続の上位で使用されることが連想される。

付録 E

返答コードの理論

返答の三つの数字は各々特別な重要性をもつ。第一の数字は、応答が
良い、わるい、あるいは不完全であるかどうかを示す。洗練されてい
ないセンダーSMTPは、この第一の数字を検査することによりそれの次
の動作(計画どうりに続ける、取り消す、短縮する等)を決定ことがで
きるだろう。どの種類のエラーが発生したか(例、メールシステム・エ
ラー、コマンド構文エラー)をおおよそ知りたいセンダーSMTPは、第二
の数字を検査するかもしれない。情報のもっとも微妙な差異のために
第三の数字を取っておく。

返答コードの第一の数字のための五つの値かある:

1yz 肯定的な予備の返答。

コマンドは受理された。しかし、要求された動作は、この返
答で情報の確認があるまで休止され続けている。センダー
SMTPは動作を継続するか異常終了するかを指定する他のコマ
ンド送るべきです。

[注: SMTPは、この種の返答を許るすいかなるコマンドも
持っていない。それで、継続あるいは異常終了のコマン
ドを持っていない。]

2yz 肯定的な完了の返答。

要求された動作は、成功し完了した。新しいリクエストは開
始されるかもしれない。

3yz 肯定的な中間の返答。

コマンドは受理された。しかし、要求された動作は、さらな
る情報の受取があるまで休止され続けている。センダーSMTP
は、この情報を指定する他のコマンドを送るべきです。この
返答は、コマンドシーケンスグループにおいて使用される。

4yz 過渡的な否定的な完了の返答。

コマンドは受理されなかった。また、要求された動作は起こ
らなかった。しかしながら、エラー条件は一時的で、動作は
再び要求されるかもしれない。センダーは(もしあれば)コマ
ンドシーケンスの始めに戻るべきです。二つの異なるサイト
(レシーバおよびセンダーSMTP)が解釈を一致する必要のある
とき、"過渡的"に意味を割り当てることは難しい。このカテ
ゴリーの中の各返答は異なる時価を持つかもしれない。しか
し、センダーSMTPが再び試みることを奨励する。返答が 4yz
あるいは 5yz カテゴリー(下を見よ)へ適合するかどうかを
決定するための大ざっぱな方法は、もしそれらがコマンドの
形のあるいはセンダーかレシーバの特性のいかなる変化もな
しに繰り返されることができるならば、返答は 4yz である
ということです。(例えば、コマンドは全く同様に繰り返さ
れ、またレシーバは新しいインプリメンテーションを提供し
ない。)

5yz 恒久的な否定的な完了の返答。

コマンドは受理されなかった。また、要求された動作は起き
なっかった。センダーSMTPは、正確なリクエスト(同じシー
ケンス中の)を繰り返すこと思いどどまらせられる。いくつ
かの"恒久的"エラー条件さえ修正することができる。そのた
め、人間のユーザは将来のある時点(例、スペリングが改定
された後、あるいはユーザがアカウントステータスを改定し
た後)での直接行動によってコマンドシーケンスを再度開始
することをセンダーSMTPに命令することを望むかもしれない。

第二の数字は特定のカテゴリー中の応答をコード化する:

x0z 構文 — これらの返答は構文エラーについて言及する。
いかなる機能カテゴリーにも適合しない構文上正しいコ
マンド、およびインプリメントされていないあるいは不
必要なコマンド。

x1z 情報 — ステータスあるいはヘルプのような、情報のた
めのリクエストへの返答です。

x2z 接続 — これらは送信チャンネルに関連する返答です。

x3z まだ、無指定。

x4z まだ、無指定。

x5z メールシステム — これらの返答は、要求された転送あ
るいは他のメールシステム動作に関してレシーバメール
システムのステータスを示す。

第三の数字は第二の数字によって指定された各カテゴリーにおける
意味のより微妙な違いを与える。返答のリストはこれを例証する。
各返答テキストは必須よりもむしろ推奨され、それと関係するコマ
ンドによって変わるかもしれない。他方で、返答コードはこのセク
ションの仕様に厳密に従うべきです。レシーバのインプリメンテー
ションはここで記述されたものからわずかに異なる状況のための新
しいコードをは発明すべきではなく、むしろ既に定義されたコード
を適応するべきです。

例えば、成功した実行がセンダーSMTPに新しい情報を提供しない
NOOPのようなコマンドは250 返答を返すだろう。コマンドがインプ
リメントされていない非サイト特有の動作を要求したとき、応答は
502です。それの改良されたものは、インプリメントされたが、イ
ンプリメントされていないパラメータを要求するコマンドに対する
504 返答です。

返答テキストは、単一の行より長いかもしれない; そのような場合、
完全なテキストはマークされなければならない、そのため、センダー
SMTPがいつこれが返答を読むことをやめることができるかを知る。こ
れは、複数行の返答を表示するための特別なフォーマットを必要とす
る。

複数行の返答のための特別なフォーマットは、最後の行を除く全て
の行は、返答コードで始まり、ハイフン "-"(マイナスとしても知
られる)が直後に続き、テキストが続くことです。最後の行は、返
答コードで始まり、<SP>が直後に続き、随意のあるテキスト、そし
て、<CRLF>が続きます。

例えば:
123-First line
123-Second line
123-234 text beginning with numbers
123 The last line

多くの場合、センダーSMTPはそのとき、行の先頭で<SP>が続く返答
コードを調べることをたんに必要とし、また、前の行を全て無視す
る。まれに、返答"テキスト"中にセンダーのための重要な重要な
データがある。センダーは現在の状況からこれらの理由を知る。

付録 F

シナリオ

このセクションはSMTPセッションのいくつかの種類の完全なシナリオ
を示す。

典型的なSMTP処理のシナリオ

このSMTPの例は、ホストUSC-ISIFのSmithによってホストBBN-UNIXの
Jones, GreenおよびBrownへ送られるメールを示している。ここでは、
メールはJonesおよびBrownについて受理される。GreenはホストBBN-
UNIXにメールボックスを持っていない。

-------------

R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
S: HELO USC-ISIF.ARPA
R: 250 BBN-UNIX.ARPA

S: MAIL FROM:<APRA.FISI-CSU|htimS#APRA.FISI-CSU|htimS>
R: 250 OK

S: RCPT TO:<APRA.XINU-NBB|senoJ#APRA.XINU-NBB|senoJ>
R: 250 OK

S: RCPT TO:<APRA.XINU-NBB|neerG#APRA.XINU-NBB|neerG>
R: 550 No such user here

S: RCPT TO:<APRA.XINU-NBB|nworB#APRA.XINU-NBB|nworB>
R: 250 OK

S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah…
S: …etc. etc. etc.
S: .
R: 250 OK

S: QUIT
R: 221 BBN-UNIX.ARPA Service closing transmission channel

シナリオ 1

-------------

異常終了したSMTP処理のシナリオ

-------------

R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready
S: HELO ISI-VAXA.ARPA
R: 250 MIT-Multics.ARPA

S: MAIL FROM:<APRA.AXAV-ISI|htimS#APRA.AXAV-ISI|htimS>
R: 250 OK

S: RCPT TO:<APRA.scitluM-TIM|senoJ#APRA.scitluM-TIM|senoJ>
R: 250 OK

S: RCPT TO:<APRA.scitluM-TIM|neerG#APRA.scitluM-TIM|neerG>
R: 550 No such user here

S: RSET
R: 250 OK

S: QUIT
R: 221 MIT-Multics.ARPA Service closing transmission channel

シナリオ 2

-------------

中継されたメールのシナリオ

-------------

ステップ 1 — 送り元ホストから中継ホストへ

R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
S: HELO MIT-AI.ARPA
R: 250 USC-ISIE.ARPA

S: MAIL FROM:<APRA.IA-TIM|PQJ#APRA.IA-TIM|PQJ>
R: 250 OK

S: RCPT TO:<@USC-ISIE.ARPA:APRA.XAV-NBB|senoJ#APRA.XAV-NBB|senoJ>
R: 250 OK

S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Date: 2 Nov 81 22:33:44
S: From: John Q. Public <APRA.IA-TIM|PQJ#APRA.IA-TIM|PQJ>
S: Subject: The Next Meeting of the Board
S: To: APRA.xaV-NBB|senoJ#APRA.xaV-NBB|senoJ
S:
S: Bill:
S: The next meeting of the board of directors will be
S: on Tuesday.
S: John.
S: .
R: 250 OK

S: QUIT
R: 221 USC-ISIE.ARPA Service closing transmission channel

ステップ 2 — 中継ホストから送り先ホストへ

R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready
S: HELO USC-ISIE.ARPA
R: 250 BBN-VAX.ARPA

S: MAIL FROM:<@USC-ISIE.ARPA:APRA.IA-TIM|PQJ#APRA.IA-TIM|PQJ>
R: 250 OK

S: RCPT TO:<APRA.XAV-NBB|senoJ#APRA.XAV-NBB|senoJ>
R: 250 OK

S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ;
2 Nov 81 22:40:10 UT
S: Date: 2 Nov 81 22:33:44
S: From: John Q. Public <APRA.IA-TIM|PQJ#APRA.IA-TIM|PQJ>
S: Subject: The Next Meeting of the Board
S: To: APRA.xaV-NBB|senoJ#APRA.xaV-NBB|senoJ
S:
S: Bill:
S: The next meeting of the board of directors will be
S: on Tuesday.
S: John.
S: .
R: 250 OK

S: QUIT
R: 221 USC-ISIE.ARPA Service closing transmission channel

シナリオ 3

-------------

ユーザ名の確認およびセンディングのシナリオ

-------------

R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
S: HELO MIT-MC.ARPA
R: 250 SU-SCORE.ARPA

S: VRFY Crispin
R: 250 Mark Crispin <APRA.EROCS-US|CRM.nimdA#APRA.EROCS-US|CRM.nimdA>

S: SEND FROM:<APRA.CM-TIM|KAE#APRA.CM-TIM|KAE>
R: 250 OK

S: RCPT TO:<APRA.EROCS-US|CRM.nimdA#APRA.EROCS-US|CRM.nimdA>
R: 250 OK

S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah…
S: …etc. etc. etc.
S: .
R: 250 OK

S: QUIT
R: 221 SU-SCORE.ARPA Service closing transmission channel

シナリオ 4

-------------

センディングおよびメーリングのシナリオ

はじめに、ユーザ名は確認され、そしてユーザの端末へ送る試みがな
される。それが失敗したとき、メッセージはユーザのメールボックス
へ郵送される。

-------------

R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
S: HELO MIT-MC.ARPA
R: 250 SU-SCORE.ARPA

S: VRFY Crispin
R: 250 Mark Crispin <APRA.EROCS-US|CRM.nimdA#APRA.EROCS-US|CRM.nimdA>

S: SEND FROM:<APRA.CM-TIM|KAE#APRA.CM-TIM|KAE>
R: 250 OK

S: RCPT TO:<APRA.EROCS-US|CRM.nimdA#APRA.EROCS-US|CRM.nimdA>
R: 450 User not active now

S: RSET
R: 250 OK

S: MAIL FROM:<APRA.CM-TIM|KAE#APRA.CM-TIM|KAE>
R: 250 OK

S: RCPT TO:<APRA.EROCS-US|CRM.nimdA#APRA.EROCS-US|CRM.nimdA>
R: 250 OK

S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah…
S: …etc. etc. etc.
S: .
R: 250 OK

S: QUIT
R: 221 SU-SCORE.ARPA Service closing transmission channel

シナリオ 5

-------------

前のシナリオをより効率的に行う

-------------

R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
S: HELO MIT-MC.ARPA
R: 250 SU-SCORE.ARPA

S: VRFY Crispin
R: 250 Mark Crispin <APRA.EROCS-US|CRM.nimdA#APRA.EROCS-US|CRM.nimdA>

S: SOML FROM:<APRA.CM-TIM|KAE#APRA.CM-TIM|KAE>
R: 250 OK

S: RCPT TO:<APRA.EROCS-US|CRM.nimdA#APRA.EROCS-US|CRM.nimdA>
R: 250 User not active now, so will do mail.

S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah…
S: …etc. etc. etc.
S: .
R: 250 OK

S: QUIT
R: 221 SU-SCORE.ARPA Service closing transmission channel

シナリオ 6

-------------

メーリングリストのシナリオ

はじめに、各々二つのメーリングリストは異なるホストと個別のセッ
ションにおいて展開される。そして、メッセージは中継ホストを経由
していずれかのリストに表された各人へ送られる(しかし二通作るこ
とはない)。

-------------

ステップ 1 — 第一のリストの展開

R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready
S: HELO SU-SCORE.ARPA
R: 250 MIT-AI.ARPA

S: EXPN Example-People
R: 250-<APRA.CM-TIM|CBA#APRA.CM-TIM|CBA>
R: 250-Fred Fonebone <APRA.QISI-CSU|enobenoF#APRA.QISI-CSU|enobenoF>
R: 250-Xenon Y. Zither <APRA.IA-TIM|ZYX#APRA.IA-TIM|ZYX>
R: 250-Quincy Smith <@USC-ISIF.ARPA:APRA.AXAV-ISI|htimS-Q#APRA.AXAV-ISI|htimS-Q>
R: 250-<APRA.xinu-oof|eoj#APRA.xinu-oof|eoj>
R: 250 <APRA.xinu-rab|zyx#APRA.xinu-rab|zyx>

S: QUIT
R: 221 MIT-AI.ARPA Service closing transmission channel

ステップ 2 — 第二のリストの展開

R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready
S: HELO SU-SCORE.ARPA
R: 250 MIT-MC.ARPA

S: EXPN Interested-Parties
R: 250-Al Calico <APRA.CM-TIM|CBA#APRA.CM-TIM|CBA>
R: 250-<APRA.IA-TIM|ZYX#APRA.IA-TIM|ZYX>
R: 250-Quincy Smith <@USC-ISIF.ARPA:APRA.AXAV-ISI|htimS-Q#APRA.AXAV-ISI|htimS-Q>
R: 250-<APRA.XINU-NBB|derf#APRA.XINU-NBB|derf>
R: 250 <APRA.xinu-rab|zyx#APRA.xinu-rab|zyx>

S: QUIT
R: 221 MIT-MC.ARPA Service closing transmission channel

ステップ 3 — 中継ホストを経由して全ての人へメーリングする

R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
S: HELO SU-SCORE.ARPA
R: 250 USC-ISIE.ARPA

S: MAIL FROM:<APRA.EROCS-US|nosreP.tnuoccA#APRA.EROCS-US|nosreP.tnuoccA>
R: 250 OK
S: RCPT TO:<@USC-ISIE.ARPA:APRA.CM-TIM|CBA#APRA.CM-TIM|CBA>
R: 250 OK
S: RCPT TO:<@USC-ISIE.ARPA:APRA.AQISI-CSU|enobenoF#APRA.AQISI-CSU|enobenoF>
R: 250 OK
S: RCPT TO:<@USC-ISIE.ARPA:APRA.IA-TIM|ZYX#APRA.IA-TIM|ZYX>
R: 250 OK
S: RCPT
TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:APRA.AXAV-ISI|htimS-Q#APRA.AXAV-ISI|htimS-Q>
R: 250 OK
S: RCPT TO:<@USC-ISIE.ARPA:APRA.XINU-OOF|eoj#APRA.XINU-OOF|eoj>
R: 250 OK
S: RCPT TO:<@USC-ISIE.ARPA:APRA.XINU-RAB|zyx#APRA.XINU-RAB|zyx>
R: 250 OK
S: RCPT TO:<@USC-ISIE.ARPA:APRA.XINU-NBB|derf#APRA.XINU-NBB|derf>
R: 250 OK

S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah…
S: …etc. etc. etc.
S: .
R: 250 OK

S: QUIT
R: 221 USC-ISIE.ARPA Service closing transmission channel

シナリオ 7

-------------

メールを転送するシナリオ

-------------

R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
S: HELO LBL-UNIX.ARPA
R: 250 USC-ISIF.ARPA

S: MAIL FROM:<APRA.XINU-LBL|om#APRA.XINU-LBL|om>
R: 250 OK

S: RCPT TO:<APRA.FISI-CSU|derf#APRA.FISI-CSU|derf>
R: 251 User not local; will forward to <APRA.ISI-CSU|senoJ#APRA.ISI-CSU|senoJ>

S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah…
S: …etc. etc. etc.
S: .
R: 250 OK

S: QUIT
R: 221 USC-ISIF.ARPA Service closing transmission channel

シナリオ 8

-------------

-------------

ステップ 1 — 最初のホストのメールボックスを試みる

R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
S: HELO LBL-UNIX.ARPA
R: 250 USC-ISIF.ARPA

S: MAIL FROM:<APRA.XINU-LBL|om#APRA.XINU-LBL|om>
R: 250 OK

S: RCPT TO:<APRA.FISI-CSU|derf#APRA.FISI-CSU|derf>
R: 251 User not local; will forward to <APRA.ISI-CSU|senoJ#APRA.ISI-CSU|senoJ>

S: RSET
R: 250 OK

S: QUIT
R: 221 USC-ISIF.ARPA Service closing transmission channel

ステップ 2 — 次のホストでメールを配送する

R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready
S: HELO LBL-UNIX.ARPA
R: 250 USC-ISI.ARPA

S: MAIL FROM:<APRA.XINU-LBL|om#APRA.XINU-LBL|om>
R: 250 OK

S: RCPT TO:<APRA.ISI-CSU|senoJ#APRA.ISI-CSU|senoJ>
R: OK

S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah…
S: …etc. etc. etc.
S: .
R: 250 OK

S: QUIT
R: 221 USC-ISI.ARPA Service closing transmission channel

シナリオ 9

-------------

あまりにも多い受取人のシナリオ

-------------

R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready
S: HELO USC-ISIF.ARPA
R: 250 BERKELEY.ARPA

S: MAIL FROM:<APRA.FISI-CSU|letsoP#APRA.FISI-CSU|letsoP>
R: 250 OK

S: RCPT TO:<APRA.YELEKREB|yrbaf#APRA.YELEKREB|yrbaf>
R: 250 OK

S: RCPT TO:<APRA.YELEKREB|cire#APRA.YELEKREB|cire>
R: 552 Recipient storage full, try again in another transaction

S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah…
S: …etc. etc. etc.
S: .
R: 250 OK

S: MAIL FROM:<APRA.FISI-CSU|letsoP#APRA.FISI-CSU|letsoP>
R: 250 OK

S: RCPT TO:<APRA.YELEKREB|cire#APRA.YELEKREB|cire>
R: 250 OK

S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah…
S: …etc. etc. etc.
S: .
R: 250 OK

S: QUIT
R: 221 BERKELEY.ARPA Service closing transmission channel

シナリオ 10

-------------

現実のインプリメンテーションはセクション 4.5.3において指定され
るような多くの受取人を取り扱うかもしれない。

用語集

ASCII

情報交換のためのアメリカ標準コード[1]。

コマンド(command)

センダーSMTPからレシーバSMTPへ送られるメールサービス動作のため
のリクエスト。

ドメイン(domain)

メールシステムにおけるホストコンピュータの階層構造のグローバル
文字列アドレス。

メールデータ終端表示(end of mail data indication)

メールデータの終わりを示す文字の特別なシーケンス。五つの文字、
復帰"CR", 改行"LF", ピリオド".", 復帰"CR", 改行"LF"。この順序
で。

ホスト(host)

メールボックスあるいはSMTPプロセスが存在するインターネットワー
ク環境中のコンピュータ。

行(line)

<CRLF>でおわるASCII文字のシーケンス。

メールデータ(mail data)

ARPAインターネットテキストメッセージのフォーマトについての標準
(RFC822 [2])の標準セットに従う、任意の長さのASCII文字のシーケ
ンス。

メールボックス(mailbox)

メールが送られることになっているユーザを識別する文字列(アドレス)。
メールボックスは通常、ホストおよびユーザ指定子から成る。標準の
メールボックス命名の慣習は"user@domain"であると定義される。くわ
えて、メールが格納されるのは"コンテナ"です。

レシーバSMTPプロセス(receiver-SMTP process)

センダーSMTPプロセスと協力のもとにメールを転送するプロセス。接
続が輸送サービスを経由して設立されることを待つ。これは、セン
ダーSMTPからのコマンドを受け取り、返答を送り、特定の操作を実行
する。

返答(reply)

返答は、コマンドに応じて送信チャンネルを経由してレシーバからセ
ンダーへ送られる(肯定的あるいは否定的)受け取りの通知です。返答
の一般的な形式はテキストが続く完了コード(エラーコードを含む)で
す。コードはプログラムによって使用され、テキストは普通、人間の
ユーザのために意図される。

センダーSMTPプロセス(sender-SMTP process)

レシーバSMTPプロセスと協力のもとにメールを転送するプロセス。
ローカルな言語はコマンド/返答対話のユーザインターフェースで使
用される。センダーSMTPは、輸送サービス接続を開始する。これは、
SMTPコマンドを開始し、返答を受け取り、メールの転送を統べる。

セッション(session)

送信チャンネルが開いているあいだに発生する交換の集合。

トランザクション(transaction)

1人以上の受取人のために送信される一つのメッセージに必要な交換の
集合。

送信チャンネル(transmission channel)

コマンド、返答、およびメールデータの交換のためのセンダーSMTPと
レシーバSMTPの間の全二重通信経路。

輸送サービス(transport service)

信頼できるストリーム指向のデータ通信サービス。例えば、NCP, TCP,
NITS。

ユーザ(user)

メール転送サービスを得たい人間(あるいは人間を代表するプロセス)。
くわえて、コンピュータメールの受取人。

語(word)

印刷可能な文字のシーケンス。

<CRLF>

次の2文字、復帰"CR",改行"LF"(この順序で)。

<SP>

スペース文字

参照文献

[1] ASCII

ASCII, "USA Code for Information Interchange", United States of
America Standards Institute, X3.4, 1968. Also in: Feinler, E.
and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for
the Defense Communications Agency by SRI International, Menlo
Park, California, Revised January 1978.

[2] RFC 822

Crocker, D., "Standard for the Format of ARPA Internet Text
Messages," RFC 822, Department of Electrical Engineering,
University of Delaware, August 1982.

[3] TCP

Postel, J., ed., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, USC/Information Sciences
Institute, NTIS AD Number A111091, September 1981. Also in:
Feinler, E. and J. Postel, eds., "Internet Protocol Transition
Workbook", SRI International, Menlo Park, California, March 1982.

[4] NCP

McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246,
January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET
Protocol Handbook", NIC 7104, for the Defense Communications
Agency by SRI International, Menlo Park, California, Revised
January 1978.

[5] Initial Connection Protocol

Postel, J., "Official Initial Connection Protocol", NIC 7101,
11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET
Protocol Handbook", NIC 7104, for the Defense Communications
Agency by SRI International, Menlo Park, California, Revised
January 1978.

[6] NITS

PSS/SG3, "A Network Independent Transport Service", Study Group 3,
The Post Office PSS Users Group, February 1980. Available from
the DCPU, National Physical Laboratory, Teddington, UK.

[7] X.25

CCITT, "Recommendation X.25 - Interface Between Data Terminal
Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for
Terminals Operating in the Packet Mode on Public Data Networks,"
CCITT Orange Book, Vol. VIII.2, International Telephone and
Telegraph Consultative Committee, Geneva, 1976.

reference: http://www.sea-bird.org/doc/rfc_doc/rfc821-jp.txt