SIMPLE MAIL TRANSFER PROTOCOL
Takami Torao
SIMPLE MAIL TRANSFER PROTOCOL
Jonathan B. Postel
August 1982
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
(213) 822-1511
TABLE OF CONTENTS
1. INTRODUCTION .................................................. 1
2. THE SMTP MODEL ................................................ 2
3. THE SMTP PROCEDURE ............................................ 4
3.1. Mail ..................................................... 4
3.2. Forwarding ............................................... 7
3.3. Verifying and Expanding .................................. 8
3.4. Sending and Mailing ..................................... 11
3.5. Opening and Closing ..................................... 13
3.6. Relaying ................................................ 14
3.7. Domains ................................................. 17
3.8. Changing Roles .......................................... 18
4. THE SMTP SPECIFICATIONS ...................................... 19
4.1. SMTP Commands ........................................... 19
4.1.1. Command Semantics ..................................... 19
4.1.2. Command Syntax ........................................ 27
4.2. SMTP Replies ............................................ 34
4.2.1. Reply Codes by Function Group ......................... 35
4.2.2. Reply Codes in Numeric Order .......................... 36
4.3. Sequencing of Commands and Replies ...................... 37
4.4. State Diagrams .......................................... 39
4.5. Details ................................................. 41
4.5.1. Minimum Implementation ................................ 41
4.5.2. Transparency .......................................... 41
4.5.3. Sizes ................................................. 42
APPENDIX A: TCP ................................................. 44
APPENDIX B: NCP ................................................. 45
APPENDIX C: NITS ................................................ 46
APPENDIX D: X.25 ................................................ 47
APPENDIX E: Theory of Reply Codes ............................... 48
APPENDIX F: Scenarios ........................................... 51
GLOSSARY ......................................................... 64
REFERENCES ....................................................... 67
Network Working Group J. Postel
Request for Comments: DRAFT ISI
Replaces: RFC 788, 780, 772 August 1982
SIMPLE MAIL TRANSFER PROTOCOL
1. INTRODUCTION
Simple Mail Transfer Protocol (SMTP) の目的は確実で効率的にメールを転送す
る事である。
SMTP は特殊な転送サブシステムに依存せず、信頼できる既定されたデータスト
リームチャンネルのみを必要とする。付録 A, B, C, D はさまざまな転送サービス
における SMTP の使用方法を記述している。用語集はこのドキュメントにおいて使
用されている用語の定義を提供する。
SMTP の重要な機能は転送サービス環境をわたってメールを伝達するための能力で
ある。転送サービスはインタープロセス通信環境 (IPCE: interprocess
communication environment) を供給する。IPCE は単一のネットワーク、いくつか
のネットワークおよびネットワークのサブセットをカバーする事ができる。転送シ
ステム (もしくは IPCE) がネットワークで one-to-one でない事を実現するのは
重要である。一つのプロセスは双方で知られたどんな IPCE をも通じて直接通信す
る事ができる。メールはアプリケーションもしくはインタープロセス通信である。
メールは二つかそれ以上の IPCE に接続されたあるプロセスを通じての伝達により、
異なる IPCE においてのプロセス間で通信される事が可能である。より明確には、
メールは双方の転送システム上のホストによって、別の転送システム上のホストの
間で伝達される事が可能である。
2. THE SMTP MODEL
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|
+------+ +----------+ +----------+ +------+
Sender-SMTP Receiver-SMTP
Model for SMTP Use
Figure 1
-------------------------------------------------------------
SMTP はメール転送のためのメカニズムを供給する; 二つのホストが同じ転送サー
ビスに接続されているなら、送信元ユーザのホストから受信先ユーザのホストへ
直接、もしくは、出発地と目的地のホストが同じ転送サービスで接続されていない
なら、一つ以上の SMTP サーバ伝達によって。
伝達能力を供給する事ができるようにするため、最終的なメールボックスはもちろ
ん、SMTP サーバは最終的な目的地ホストの名前を提供されていなければならない。
MAIL コマンドの引数は逆経路であり、メールが誰から送信されたかを記述する。
RCPT コマンドの引数は順経路であり、メールが誰に送信されるかを記述する。逆
経路がリターンルートである (これは伝達されたメッセージにエラーが発生した時
メッセージを送り主に戻すために使用されるだろう) が、順経路はソースルートで
ある。
同じメッセージが複数の受取人に送られる時、SMTP は同じ目的地ホストのすべて
の受取人に対してデータの一つのコピーのみの転送を助長する。
メールコマンドと応答は厳格な文法を持つ。応答は数値コードも持つ。以下におい
て、例は実際のコマンドと応答の使用を表している。コマンドと応答の完全なリス
トはこの仕様書における Section 4 で表される。
コマンドと応答は大文字と小文字を区別しない。これは、コマンドもしくは応答の
言葉が大文字、小文字、もしくは大文字と小文字の混在であっても良いという事で
ある。これはメールボックスユーザ名に対して真ではない事に注意。いくつかのホ
ストに対して、ユーザ名は大文字と小文字を区別し、SMTP 実装はメールボックス
引数において表されたユーザ名としてその大文字と小文字を保たなければならない。
ホスト名は大文字と小文字を区別しない。
コマンドと応答は ASCII 文字セット [1] からの文字で構成される。転送サービス
が 8 ビットバイト (オクテット) 転送チャンネルを供給する時、それぞれの 7
ビット文字は、右側につめられて最上位ビットがゼロにクリアされたオクテットと
して転送される。
コマンドと応答の一般的な形式を記述する時、引数 (もしくは特別なシンボル) は、
たとえば "<string>" や "<reverse-path>" のように、メタ言語変数 (もしくは定
数) によって表されるだろう。ここで角カッコはこれらがメタ言語変数である事を
示す。しかしながら、いくつかの引数は文字どおりの角カッコを使用する。たとえ
ば、実際の reverse-path は各カッコによって囲まれている。i.e.,
"<John.Smith@USC-ISI.ARPA>" は <reverse-path> の例である (各カッコはコマン
ドや応答で実際に転送される)。
3. THE SMTP PROCEDURES
この章はいくつかの部分で SMTP において使用される手続きを紹介する。最初の物
はメールトランザクションとして定義されている基本的なメール手続きとなる。こ
れに続いてメールフォワーディング、メールボックス名検証、メーリングリストエ
クスパンド、メールボックスの代わりもしくはメールボックスと結合しての端末へ
の送信、そして交換のオープンとクローズの詳述である。このセクションの終わり
として、伝達上のコメント、メールドメインの注記、そして役割変更の論議を行う。
この章はくまなく部分的なコマンドと応答シーケンスの例であり、いくつかの完全
なシナリオは Appendix F において紹介されている。
3.1. MAIL
SMTP メールトランザクションには三つのステップがある。トランザクション
は送信元身分を明かす MAIL コマンドから開始する。受取人の情報を与える
一つ以上の RCPT コマンドの一連が続く。それから DATA コマンドがメール
データを与える。最終的に、メールデータインジケータの終わりがトランザ
クションを確認する。
手続きにおける最初のステップは 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>
このコマンドはある受取人を記述している順経路を与える。もし受け入れ
られれば、受信先 SMTP は 250 OK 応答を返し、順経路を保存する。もし
受取人が不明であれば、受信先 SMTP は 550 Failure 応答を返す。この
手続きの第二ステップは何回でも繰り返す事ができる。
<forward-path> はメールボックス以外の情報を含む事ができる。
<forward-path> はホストのソースルーティングリストと目的地メールボッ
クスである。<forward-path> における最初のホストはこのコマンドを受
け取っているホストとなるべきである。
手続きにおける第三ステップは DATA コマンドである。
DATA <CRLF>
もしうけいれられれば、受信先 SMTP は 354 Intermediate 応答を返し、
後続するすべての行がメッセージテキストであるとみなす。テキストの終
わりが受け取られて保存された時、SMTP 受信先は 250 OK 応答を送信す
る。
メールデータが転送チャンネル上で転送されるので、コマンドと応答の
交換が再開できるように、メールデータの終了が明示されなければならな
い。SMTP は一つのピリオドのみを含む行を送信する事によってメール
データの終わりを示す。透過的な手続きがこれとユーザのテキストとの干
渉を起こさないように使用される (Section 4.5.2 参照)。
メールデータは Date, Subject, To, Cc, From [2] のようなメモ
ヘッダ項目を含んでいる事に注意してください。
メールデータインジケータの終わりはメールトランザクションの最終確認
もし、受信先 SMTP に保存された受取人とメールデータを処理する事も伝
える。もし受け入れられれば、受信先 SMTP は 250 OK 応答を返す。DATA
コマンドは (たとえば受取人が指定されていないように) メールトランザ
クションが不完全であった場合、もしくはリソースが利用できない場合に
のみ失敗すべきである。
上記の手続きはメールトランザクションの一例である。これらのコマンドは上
記で論議されている順番においてのみ使用されなければならない。例 1 (下記)
はメールトランザクションにおけるこれらのコマンドの使用を例証している。
-------------------------------------------------------------
Example of the SMTP Procedure
この SMTP の例はホスト Alpha.ARPA の Smith によってホスト Beta.ARPA
の Jones, Green, Brown に送られるメールを表している。ここでわれわれ
はホスト Alpha がホスト Beta に直接コンタクトする事を仮定する。
S: MAIL FROM:<Smith@Alpha.ARPA>
R: 250 OK
S: RCPT TO:<Jones@Beta.ARPA>
R: 250 OK
S: RCPT TO:<Green@Beta.ARPA>
R: 550 No such user here
S: RCPT TO:<Brown@Beta.ARPA>
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 にメールボックスを持っていなかった。
Example 1
-------------------------------------------------------------
3.2. FORWARDING
<forward-path> における目的地情報が正しくないが、受信先 SMTP が正しい
目的地を知っているようないくつかの場合がある。このような場合、送り主が
正しい目的地と連絡できるように、以下のような応答の一つが使用されるべき
である。
251 User not local; will forward to <forward-path>
この応答は、受信先 SMTP がユーザのメールボックスが他のホストに
ある事を知っていて、以後使用されるべき正しい forward-path を示
している。ホスト、ユーザもしくはその両方のいずれかが違っている
事に注意。受信先はこのメッセージを配信する義務を持っている。
551 User not local; please try <forward-path>
この応答は、送信先 SMTP がユーザのメールボックスが他のホストに
ある事を分かっていて、使用される正しい forward-path を示してい
る。ホスト、ユーザもしくはその両方のいずれかが違っている事に注
意。受信先はこのユーザに対するメールの受付を拒否し、送信元は与
えられた情報に従ってメールをリダイレクトするか、始点となった
ユーザにエラーレスポンスを返すかのいずれかを行わなければならな
い。
例 2 はこれらのレスポンスを例証している。
-------------------------------------------------------------
Example of Forwarding
S: RCPT TO:<Postel@USC-ISI.ARPA>
R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA>
もしくは
S: RCPT TO:<Paul@USC-ISIB.ARPA>
R: 551 User not local; please try <Mockapetris@USC-ISIF.ARPA>
のどちらか。
Example 2
-------------------------------------------------------------
3.3. VERIFYING AND EXPANDING
SMTP はユーザ名を検証するためやメーリングリストに広げるコマンドである
追加的な機能を供給する。これは VRFY と EXPN コマンドを持ってなされ、
これらは文字列引数を持つ。VRFY コマンドに対して、文字列はユーザ名であ
り、レスポンスはユーザのフルネームを含んでユーザのメールボックスを示
さなければならない。EXPN コマンドに対して、文字列はメーリングリストを
示し、複数行レスポンスがユーザのフルネームを含む事ができ、メーリング
リスト上の全メールボックスを与えなければならない。
"ユーザ名" は曖昧な用語であり故意に使用される。もし乾すとが VRFT や
EXPN コマンドを実装するなら、少なくともローカルメールボックスが
"ユーザ名" として認識されなければならない。もしホストが "ユーザ名"
として別の文字列を認識することを選択すれば、それも許される。
いくつかのホストにおいて、共通データ構造がエントリがメーリングリストと
メールボックスのエイリアス両方のタイプに保持され、一つのメールボックス
のメーリングリストを持つ事が可能であるため、それらの間の相違は少々曖昧
である。もしリクエストがメーリングリストを検証するためにされれば、メッ
セージの受領としてリスト上の全員に配信されるであろうようにアドレッシン
グされているのであれば、消極的なレスポンスを返す事ができるし、他の方法
としてエラーが報告されるべきである (e.g., "550 That is a mailing list,
not user")。もしリクエストがユーザ名に広げるようにされていれば、一つの
名前を含むリストを返す事によって形成されている事ができるし、エラーが報
告される事もできる (e.g., "550 That is a user name, not a mailing list")。
複数行応答 (通常の EXPN) の場合において、一つのメールボックスが応答の
それぞれの行に正確に記述されているようになる。たとえば "VRFY Smith"
で二人の Smith が存在するのような曖昧なリクエストの場合において、レス
ポンスは "553 User ambiguous" でなければならない。
検証を行う場合、ユーザ名は例 3 において示されるように率直なものとなる。
-------------------------------------------------------------
Example of Verifying a User Name
Either
S: VRFY Smith
R: 250 Fred Smith <Smith@USC-ISIF.ARPA>
Or
S: VRFY Smith
R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA>
Or
S: VRFY Jones
R: 550 String does not match anything.
Or
S: VRFY Jones
R: 551 User not local; please try <Jones@USC-ISIQ.ARPA>
Or
S: VRFY Gourzenkyinplatz
R: 553 User ambiguous.
Example 3
-------------------------------------------------------------
expanding の場合、メールボックスリストは例 4 において表されるような複
数行応答を必要とする。
-------------------------------------------------------------
Example of Expanding a Mailing List
Either
S: EXPN Example-People
R: 250-Jon Postel <Postel@USC-ISIF.ARPA>
R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
R: 250-Sam Q. Smith <SQSmith@USC-ISIQ.ARPA>
R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
R: 250-<joe@foo-unix.ARPA>
R: 250 <xyz@bar-unix.ARPA>
Or
S: EXPN Executive-Washroom-List
R: 550 Access Denied to You.
Example 4
-------------------------------------------------------------
VRFY と EXPN コマンドの文字列引数は、ユーザ名とメールボックスリスト概
念実装の多様性のため、これ以上の制限は行わない。いくつかのシステム上で
EXPN コマンドの引数がメーリングリストを含んでいるファイルに対するファ
イル名としてふさわしいものであるかもしれないが、インターネットにおいて
はファイル名慣例の多様性がそんざいする。
VRFY と EXPN コマンドは最小実装 (Section 4.5.1) には含まれず、それらが
実装されるなら、伝達を横切って作業する必要はない。
3.4. SENDING AND MAILING
SMTP の主な目的はユーザのメールボックスにメッセージを配信する事である。
いくつかのホストによって供給されている非常に類似したサービスは (仮に
ユーザがホスト上でアクティブであるなら) ユーザの端末にメッセージを配信
する事である。ユーザのメールボックスへの配信は "mailing" と呼ばれ、ユー
ザの端末への配信は "sending" と呼ばれる。多くのホストにおいて sending
の実装が mailing の実装とほとんど同一であるため、これら二つの機能は
SMTP において結合されている。しかしながら sending コマンドは必要とされ
る最小実装に含まれていない (Section 4.5.1)。ユーザは彼らの端末上でメッ
セージの書き込みを制御する能力を持っているべきである。ほとんどのホスト
はユーザにこのようなメッセージを受け入れたり拒否したりする事を許可して
いる。
以下の三つのコマンドは sending オプションをサポートするために定義され
ている。これらは MAIL コマンドの代わりにメールトランザクションにおいて
使用され、受信先 SMTP にこのトランザクションの特別なセマンティクスを知
らせる:
SEND <SP> FROM:<reverse-path> <CRLF>
SEND コマンドは、メールデータがユーザの端末に配信される事を必
要としている。もしユーザがホスト上でアクティブでなければ (もし
くはターミナルメッセージを受け付けていなければ)、RCPT コマンド
に 450 応答が返されるだろう。もしメッセージが端末に配信されれ
ば、メールトランザクションは成功する。
SOML <SP> FROM:<reverse-path> <CRLF>
Send Or MaiL コマンドは、もしユーザがホスト上でアクティブであ
れば (そしてターミナルメッセージを受け付けていれば)、メール
データがユーザの端末に配信される事を必要としている。もしユーザ
がアクティブでなければ (もしくはターミナルメッセージを受け付け
ていなければ)、メールデータはユーザのメールボックスに入れられ
る。もしメッセージが端末かメールボックスのいずれかに配信されれ
ば、メールトランザクションは成功する。
SAML <SP> FROM:<reverse-path> <CRLF>
Send And MaiL コマンドは、もしユーザがホスト上でアクティブなら
(そして端末メッセージを受け付けていれば)、メールデータがユーザ
の端末に配信される事を必要としている。どのような場合でもメール
データはユーザのメールボックスに入れられる。もしメッセージが
メールボックスに配信されればメールトランザクションは成功する。
MAIL コマンドでしようされれている応答コードと同じ物がこれらのコマンド
に対して使用される。
3.5. OPENING AND CLOSING
転送チャンネルがオープンされた時、通信するホストが双方を認識する事を保
証するための交換が存在する。
以下の二つのコマンドは転送チャンネルのオープンとクローズで使用される:
HELO <SP> <domain> <CRLF>
QUIT <CRLF>
HELO コマンドにおいて、コマンドを送信しているホストは自分自身を明示す
る; このコマンドは "Hello, I am <domain>" と言っているように解釈される。
-------------------------------------------------------------
Example of Connection Opening
R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
S: HELO USC-ISIF.ARPA
R: 250 BBN-UNIX.ARPA
Example 5
-------------------------------------------------------------
-------------------------------------------------------------
Example of Connection Closing
S: QUIT
R: 221 BBN-UNIX.ARPA Service closing transmission channel
Example 6
-------------------------------------------------------------
3.6. RELAYING
forwarding-paht は "@ONE,@TWO:JOE@THREE" 形式のソースルートである。こ
こで ONE, TWO, THREE はホストである。この形式はアドレスと経路との違い
を強調するために使用される。メールボックスは絶対アドレスであり、経路は
その場所を得る方法に関する情報である。この二つの概念は混乱すべきでない。
概念的に forward-path の要素は、あるサーバ SMTP から別の物に伝達される
メッセージとして reverse-path に移動される。reverse-path は逆ソース
ルート (i.e., メッセージの現在の場所からメッセージの始点へのソースルー
ト) である。サーバ SMTP が forward-path からその識別子を削除し、それを
reverse-path に挿入する時、サーバ SMTP が異なる環境において異なる名前
によって知られている場合、メールがきたところの環境ではなく、メッセージ
を送信しているところの環境で知られている名前を使用しなければならない。
もしメッセージが SMTP に到着した時 forward-path の最初の要素がその SMTP
の識別子ではないなら、要素は forward-path から削除されず、メッセージを
送信する次の SMTP を予測するために使用される。どのような場合でも SMTP
は reverse-path にそれ自身の識別子を加える。
ソースルーティングを使う事で、受信先 SMTP は別のサーバ SMTP に伝達され
るメールを受信する。受信先 SMTP は、ローカルユーザに対するメールを受け
入れるか拒否するかというある方法においてメールを伝達するタスクを受け入
れるか拒否する事ができる。受信先 SMTP は forward-path から reverse-path
の開始までそれ自身の識別子を移動する事によってコマンド引数を変形する。
この時、受信先 SMTP は送信元 SMTP となり、forward-path における次の
SMTP に転送チャンネルを確立し、それにメールを送信する。
reverse-path の最初のホストは SMTP コマンドを送信するホストであり、
forward-path の最初のホストは SMTP コマンドを受信するホストとなるべき
である。
forward-path と reverse-path は SMTP コマンドと応答において現れるが、
メッセージにおいては必要ない事に注意。これは、これらの経路や特にこの構
文が "To:", "From:", "CC:" などのメッセージヘッダのフィールドに現れる
必要がないという事である。
もし既にサーバ SMTP がメール伝達のタスクを受け入れ、そして後に
forward-path が不正である事に気づいたり、何らかの理由でメールを送信で
きない事に気づいたなら、"配信不能なメール" 通知メッセージを構築して
(reverse-path によって示されるような) 配信不能メールの始点に送信しなけ
ればならない。
この通知メッセージはこのホストでサーバ SMTP からでなければならない。も
ちろん、サーバ SMTP は通知メッセージに対しての問題に関する通知メッセー
ジを送るべきではない。エラーレポートにおけるループを防ぐ一つの方法は、
通知メッセージの MAIL コマンドに空の reverse-path を記述する事である。
このようなメッセージが伝達される時、reverse-path を空のままにしておく
事が許される。空の reverse-path を持つ MAIL コマンドは以下のように表さ
れる:
MAIL FROM:<>
配信不能メール通知メッセージは例 7 において表される。この通知は HOSTW
の JOE によって開始され、HOSTZ 上に伝達するための相互連動を伴って HOSTX
経由で HOSTY に送られたメッセージのレスポンスにおけるものである。われ
われが例で見る物は HOSTY と HOSTX 間のトランザクションである。これは通
知メッセージの復帰における最初のステップである。
-------------------------------------------------------------
Example Undeliverable Mail Notification Message
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
Example 7
-------------------------------------------------------------
3.7. DOMAINS
ドメインは現在 ARPA インターネットメールシステムにおいて導入されている
概念である。ドメインの使用は単純な文字列ホスト名の単調なグローバル空間
から、グローバルアドレスのツリーに取りまとめられている階層構造にアドレ
ス空間を変える。ホスト名は、ドメイン要素がもっとも具体的なものからもっ
とも一般的なものになるよう整理されているように解釈される、ピリオドに
よって区切られたドメイン名要素文字列のシーケンスであるドメインとホスト
指定子によっておきかえられる。
たとえば、"USC-ISIF.ARPA", "Fred.Cambridge.UK", "PC7.LCS.MIT.ARPA" は
host-and-domain 識別子であろう。
ドメイン名が SMTP において使用され、公式な名前のみが使用されている場合、
ニックネームやエイリアスの使用は許されない。
3.8. CHANGING ROLES
TURN コマンドは転送チャンネル上で通信している二つのプログラムの役割を
逆転させるために使用されるだろう。
もし現在 program-A が送信元 SMTP で、それが TURN コマンドを送信し、OK
応答 (250) を受け取ったなら、この時 program-A は受信先 SMTP となる。
もし現在 program-B が送信先 SMTP で、それが TURN コマンドを受信し、OK
応答 (250) を送信したなら、この時 program-B は送信先 SMTP となる。
役割変更を拒絶するために受信先は 502 応答を送る。
このコマンドがオプションである事に注意してください。これは転送チャンネ
ルが TCP であるところの状況では通常使用されないだろう。しかしながら、
転送チャンネル確立のコストが高い時、このコマンドはまったく有用である。
たとえば、このコマンドは、転送チャンネルとして public switched
telephone system を使用しているメール交換をサポートしている場合、特に
いくつかのホストがメール交換のため他のホストを得る場合に有用であろう。
4. THE SMTP SPECIFICATIONS
4.1. SMTP COMMANDS
4.1.1. COMMAND SEMANTICS
SMTP コマンドはユーザによってリクエストされるメール転送とメールシ
ステム機能を定義している。SMTP コマンドは <CRLF> によって終了する
文字列である。コマンドコード自身は、もしパラメータが続くなら <SP>
で終了し、そうでなければ <CRLF> で終了するアルファベット文字である。
メールボックスの文法は送信先サイトの取り決めに準じなければならない。
SMTP コマンドは以下で論議される。SMTP 応答は Section 4.2 において
論議される。
メールトランザクションは別のコマンドに引数として通信されるいくつか
のデータオブジェクトを含む。reverse-path は MAIL コマンドの引数で
あり、forward-path は RCPT コマンドの引数であり、そしてメールデー
タは DATA コマンドの引数である。これらの引数やデータオブジェクトは
トランザクションを完結するメールデータインジケータの終わりによって
通信される確認が終わるまで転送され、保持されなければならない。これ
に対するモデルは、reverse-path バッファ、forward-path バッファ、そ
してメールデータバッファがある、別のバッファがデータオブジェクトの
タイプを保持するために供給されている。特定のコマンドは、特定のバッ
ファに付け加えられる情報を与えるか、クリアされる一つ以上のバッファ
を与える。
HELLO (HELO)
このコマンドは送信元 SMTP を受信先 SMTP と見分けるために使用さ
れる。引数フィールドは送信元 SMTP のホスト名を含んでいる。
送信先 SMTP は接続グリーティング応答とこのコマンドのレスポンス
において受信先 SMTP と自分自身を識別する。
このコマンドとそれの OK 応答は送信元 SMTP と受信先 SMTP の両方
が初期状態となる事を確認する。これは、過程においてトランザクショ
ンが存在せず、すべての状態テーブルとバッファがクリアされるとい
う事である。
MAIL (MAIL)
このコマンドはメールデータが一つ以上のメールボックスに配信され
るメールトランザクションを初期化するために使用される。引数フィー
ルドは reverse-path を含んでいる。
reverse-path はホストと送信元メールボックスの付加的なリストか
ら成り立つ。ホストのリストが与えられた時、それは "reverse"
ソースルートであり、メールがそのリスト上のそれぞれのホストを通
じて伝達された事を示す (リストの最初のホストはもっとも最新伝達
となる)。このリストは送信元に非配信通知を返すためのソースルート
として使用される。それぞれの伝達ホストがリストの先頭に自分自身
を追加するときには、メールが送られてきた所ではなく、それが伝達
しているメールの IPCE において知られているその名前を使わなけれ
ばならない (もしそれらが異なっているなら)。エラー報告メッセージ
のいくつかのタイプにおいて (たとえば配信不能メール通知)、
reverse-path は空であろう (例 7 参照)。
このコマンドは reverse-path バッファ、forward-path バッファ、
そしてメールデータバッファをクリアする; そしてこのコマンドから
reverse-path 情報を reverse-path バッファに挿入する
RECIPIENT (RCPT)
このコマンドはメールデータの個々の受取人を識別するために使用さ
れる; 複数の受取人がこのコマンドの重複使用によって記述される。
forward-path は付加的なホストのリストと必要とされる目的地メール
ボックスで構成される。ホストのリストが与えられる時、これはソー
スルートであり、メールがリスト上の次のホストに伝達されなければ
ならない事を示す。もし受信元 SMTP が伝達機能を実装していなけれ
ば、不明なローカルユーザに対するある応答 (550) を使用するだろ
う。
メールが伝達された時、伝達ホストは forward-path の先頭から自分
自身を削除して reverse-path の先頭に自身を付けなければならない。
メールがその最終的な目的地に到着した時 (forward-path は目的地
メールボックスのみを含んでいる)、受信先 SMTP はそのホストメー
ル慣例と一致する目的地メールボックスにそれを入れる。
たとえば、以下の引数を付けて伝達ホスト A に受け取られた
メールは
FROM:<USERX@HOSTY.ARPA>
TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA>
以下の引数を付けてホスト B に伝達されるだろう。
FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA>
TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>
このコマンドはその forwad-path 引数を forward-path バッファに
追加するようにさせる。
DATA (DATA)
受信側はこのコマンドに続く行を送信側からのメールデータとして扱
う。このコマンドはこのコマンドからのメールデータをメールデータ
バッファに追加するようにさせる。メールデータは 128 ASCII 文字
コードのどんなものも含む事ができる。
メールデータはピリオドのみを含んでいる行によって終了する。これ
は文字シーケンス "<CRLF>.<CRLF>" (Transparency の Section 4.5.2
参照) である。これはメールデータの終了指標である。
このメールデータ終了指標は、受信側が保存しているメールトランザ
クション情報を今処理しなければならない事を必要とする。このプロ
セスは reverse-path バッファ、forward-path バッファ、そして
メールデータバッファの情報を消費し、このコマンドの完了でそれら
のバッファはクリアされる。もしプロセスが成功すれば、受信側は OK
応答を送らなければならない。もしプロセスが完全に失敗すれば受信
側は失敗応答を送らなければならない。
受信先 SMTP が伝達のためや最終的な配信ためのいずれかでメッセー
ジを受け付けた時、それはメールデータの先頭にタイムスタンプ行を
挿入する。このタイムスタンプ行はメッセージを送信したホストの身
元と、メッセージを受信した (そしてこのタイムスタンプを挿入して
いる) ホストの身元、そしてこのメッセージが受診された日付と時刻
を示す。伝達されたメッセージは複数のタイムスタンプ行を持ってい
るだろう。
受信先 SMTP がメッセージの "最終配信" を行う時、それはメール
データの先頭にリターンパス行を追加する。リターンパス行は MAIL
コマンドからの <reverse-path> の情報を維持する。ここで、最終配
信はメッセージが SMTP 通信から離れる事を意味する。通常、これは
目的地ユーザに配信されている事を意味するが、いくつかの場合は別
のメールシステムによってさらに処理されたり転送されたりするかも
しれない。
実際の送信元メールボックスと違ったリターンパスにおけるメール
ボックスが可能である。たとえば、もしエラーレスポンスがメール
送信者ではなく特別なエラー処理メールボックスに配信される場
合である。
前述の二つのパラグラフは、最終的なメールデータがリターンパス行
から始まり、一つ以上のタイムスタンプ行が続くであろうという事を
意味している。これらの行の後にはメールデータヘッダとボディ [2]
が続くだろう。例 8 を参照。
メールデータ終了の指標に続く処理が部分的に成功する時に必要とさ
れるレスポンスとさらなる動作について特別に言及しておく必要があ
る。これはもし何人かの受信者とメールデータを受け入れた後なら、
受信先 SMTP はメールデータがその受信者の何人かにうまく配信され
たが、その他の人に対してはうまく行かなかった (たとえば、メール
ボックス空間割り当ての問題のため) ことを検出する。このような状
況において、DATA コマンドのレスポンスは OK 応答でなければなら
ない。しかし、受信側 SMTP はメッセージの開始者に "配信不能メール"
通知メッセージを構築して送信しなければならない。メッセージの受
信に失敗したすべての受信者をリストしている単一の通知、もしくは
別々の通知メッセージのどちらかが、それぞれの失敗された受信者に
対して送られなければならない (例 7 参照)。すべての配信不能メー
ル通知メッセージは (たとえそれらが SEND, SOML, SAML コマンドの
処理から発生したとしても) MAIL コマンドの使用で送られる。
-------------------------------------------------------------
Example of Return Path and Received Time Stamps
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 ...
Example 8
-------------------------------------------------------------
SEND (SEND)
このコマンドはメールデータが一つ以上の端末に配信されるメールト
ランザクションを開始するために使用される。この引数フィールドは
reverse-path を含んでいる。このコマンドはメッセージが端末に配
信されたなら成功する。
reverse-path はオプション的なホストのリストと送信元メールボッ
クスで構成される。ホストのリストが与えられた時、それは "逆"
ソースルートであり、メールがリスト上のそれぞれのホスト (リスト
の最初のホストがもっとも最近伝達を行ったホスト) を通って伝達さ
れてた事を示す。このリストは送り主に配信不能通知を返すための
ソースルートとして使用される。それぞれの伝達ホストは自身をリス
トの先頭に追加するが、これは、メールが来たところの IPCE ではな
く、メールが伝達されている所の IPCE において知られる名前を使用
しなければならない (もしそれらが異なるなら)。
このコマンドは reverse-path バッファ、forward-path バッファ、
そしてメールデータバッファをクリアする; そしてこのコマンドから
reverse-path 情報を取り出して reverse-path バッファに追加する。
SEND OR MAIL (SOML)
このコマンドはメールデータが一つ以上の端末もしくはメールボック
スに配信されるメールトランザクションを開始する。それぞれの受取
人に対して、もし受取人がホスト上でアクティブなら (そしてターミ
ナルメッセージを受け付けているなら)、メールデータは受取人の端
末に配信されるが、そうでなければ受取人のメールボックスに送られ
る。引数フィールドは reverse-path を含んでいる。このコマンドは
メッセージが端末かメールボックスに配信されれば成功する。
reverse-path はオプション的なホストのリストと送信者のメール
ボックスで構成される。ホストのリストが与えられた時、それは "逆"
ソースルートであり、リスト上のそれぞれのホストを通ってメールが
伝達された事を示す (リストの最初のホストはもっとも最近伝達を
行ったホストである)。このリストは送信者に配信不能通知を返す
ソースルートとして使用される。それぞれの伝達ホストは自身をリス
トの先頭に追加するが、これは、メールが来たところの IPCE ではな
く、メールが伝達されている所の IPCE において知られる名前を使用
しなければならない (もしそれらが異なるなら)。
このコマンドは reverse-path バッファ、forward-path バッファ、
そしてメールデータバッファをクリアする; そしてこのコマンドから
reverse-path 情報を取り出して reverse-path バッファに追加する。
SEND AND MAIL (SAML)
このコマンドはメールデータが一つ以上の端末とメールボックスに配
信されるトランザクションを開始するために使用される。それぞれの
受取人に対して、もし受取人がホスト上でアクティブなら (そして
ターミナルメッセージを受け付けていれば) メールデータは受取人の
端末と、すべての受取人に対して受取人のメールボックスに配信され
る。この引数フィールドは reverse-path を含んでいる。メッセージ
がメールボックスに配信されればコマンドは成功する。
reverse-path はオプション的なホストのリストと送信者のメール
ボックスで構成される。ホストのリストが与えられた時、それは "逆"
ソースルートであり、リスト上のそれぞれのホストを通ってメールが
伝達された事を示す (リストの最初のホストはもっとも最近伝達を
行ったホストである)。このリストは送信者に配信不能通知を返す
ソースルートとして使用される。それぞれの伝達ホストは自身をリス
トの先頭に追加するが、これは、メールが来たところの IPCE ではな
く、メールが伝達されている所の IPCE において知られる名前を使用
しなければならない (もしそれらが異なるなら)。
このコマンドは reverse-path バッファ、forward-path バッファ、
そしてメールデータバッファをクリアする; そしてこのコマンドから
reverse-path 情報を取り出して reverse-path バッファに追加する。
RESET (RSET)
このコマンドは現在のメールトランザクションが中止される事を示す。
保存されている送信元、受取人、メールデータのすべてが破棄され、
すべてのバッファと状態テーブルはクリアされなければならない。受
取人は OK 応答を送らなければならない。
VERIFY (VRFY)
このコマンドは引数がユーザを示している事を受信側に問い合わせる。
もしそれがユーザ名であれば、ユーザの完全な名前 (もし分かってい
れば) と完全なメールボックスが返される。
このコマンドは reverse-path バッファ、forward-path バッファ、
もしくはメールデータバッファに何の影響も与えない。
EXPAND (EXPN)
このコマンドは引数がメーリングリストを示しているかどうかを受信
側に問い合わせる。もしそうであれば、このリストの会員を返す。
ユーザの完全な名前 (もし分かるなら) と完全に記述されたメール
ボックスが複数行応答で返される。
このコマンドは reverse-path バッファ、forward-path バッファ、
もしくはメールデータバッファに何の影響も与えない。
HELP (HELP)
このコマンドは HELP コマンドの送信側に補助的な情報を送信するた
め受信側から与えられる。このコマンドは一つの引数 (e.g., あるコ
マンド名) をとる事ができ、レスポンスとしてより詳細な情報を返す。
このコマンドは reverse-path バッファ、forward-path バッファ、
メールデータバッファのいずれにも影響を与えない。
NOOP (NOOP)
このコマンドはどんなパラメータにも以前送られたコマンドにも影響
しない。これは受信側が OK 応答を返す以外にどのような動作も指定
しない。
このコマンドは reverse-path バッファ、forward-path バッファ、
メールデータバッファのいずれにも影響を与えない。
QUIT (QUIT)
このコマンドは受信側が OK 応答を返し、それから転送チャンネルを
クローズしなければならない事を指定する。
受信側は (たとえエラーが発生しても) QUIT コマンドを受信して応
答するまで転送チャンネルをクローズすべきではない。送信側は (た
とえ直前のコマンドがエラーレスポンスだったとしても) QUIT コマ
ンドを送信して応答を受信するまで転送チャンネルをクローズすべき
ではない。もし接続が早まってクローズされたら、受信側は RSET コ
マンドを受信したように動作すべきであり (保留中のすべてのトラン
ザクションをキャンセルするが、直前の完了したトランザクションに
は何もしない)、送信側は過程におけるコマンドやトランザクション
が一時的なエラー (4xx) を受信したように動作すべきである。
TURN (TURN)
このコマンドは、受信側が (1) OK 応答を送り送信側 SMTP に取って
代わるか、(2) 拒絶的応答を返して受信側 SMTP の役割を保つかのど
ちらかを示す。
もし現在 program-A が送信側 SMTP で、それが TURN コマンドを送
り OK 応答 (250) を受け取ったなら、program-A は受信側 SMTP に
なる。program-A は転送チャンネルが開いているなら初期状態となり、
220 service ready グリーティングを送る。
もし現在 program-B が受信側 SMTP で、それが TURN コマンドを受
信して OK 応答 (250) を送ったなら、program-B は送信側 SMTP と
なる。program-B は転送チャンネルがオープンされているなら初期
状態となり、220 service ready グリーティングを受信する事を想定
する。
役割を変更する事を拒否するため、受信側は 502 応答を送る。
これらのコマンドが使用できる順番の制限がある。
セッションにおける最初のコマンドは HELO コマンドでなければなら
ない。HELO コマンドはセッションにおいて後でもまた使う事ができる。
もし HELO コマンドの引数が受け入れられなければ、501 失敗応答が
返されなければならず、送信側 SMTP は同じ状態にとどまらなければ
ならない。
NOOP, HELP, EXPN, VRFY コマンドはセッション内のいつでも使う事
ができる。
MAIL, SEND, SOML, SAML コマンドはメールトランザクションを開始
する。いったんメールトランザクションが開始すると、トランザク
ションはトランザクション開始コマンドの一つ、一つ以上の RCPT
コマンドと DATA コマンドがこの順番で成り立つ。メールトランザク
ションは RSET コマンドによって中止する事ができる。一つのセッ
ションにおいてゼロかそれ以上のトランザクションが存在できる。
もしトランザクション開始コマンド引数が受け入れられなければ、
501 失敗応答が返されなければならず、受信側 SMTP は同じ状態にと
どまらなければならない。もしトランザクションのコマンドが順番ど
おりでなければ、503 失敗応答が返されなければならず、受信側 SMPT
は同じ状態にとどまらなければならない。
セッションにおける最後のコマンドは QUIT コマンドである。QUIT
コマンドはセッションにおいてどんな時でも使う事ができる。
4.1.2. COMMAND SYNTAX
コマンドはコマンドコードとそれに続く引数フィールドから構成される。
コマンドコードは 4 桁のアルファベット文字である。大文字や小文字の
アルファベットは同一とみなされる。従って、以下のどれもが MAIL コマ
ンドとして示される:
MAIL Mail mail MaIl mAIl
これは forward-path に対する "TO" や "to" のようなパラメータ値を表
すすべてのシンボルにも適用される。コマンドコート度引数フィールドは
一つ以上の空白によって区切られる。しかしながら、 reverse-path や
forward-path 引数の内部では、大文字と小文字を区別する。特に、いく
つかのホストにおいてユーザ "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 表記法が適用されている) は下記で与
えられる。"..." 表記は、フィールドが一回以上繰り返す事ができる事を
示す。
<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> ::= the carriage return character (ASCII code 13)
<LF> ::= the line feed character (ASCII code 10)
<SP> ::= the space character (ASCII code 32)
<snum> ::= one, two, or three digits representing a decimal
integer value in the range 0 through 255
<a> ::= any one of the 52 alphabetic characters A through Z
in upper case and a through z in lower case
<c> ::= any one of the 128 ASCII characters, but not any
<special> or <SP>
<d> ::= any one of the ten digits 0 through 9
<q> ::= any one of the 128 ASCII characters except <CR>,
<LF>, quote ("), or backslash (\)
<x> ::= any one of the 128 ASCII characters (no exceptions)
<special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
| "," | ";" | ":" | "@" """ | the control
characters (ASCII codes 0 through 31 inclusive and
127)
バックスラッシュ (円記号) "\" は引用文字であり、次の文字が文字通り
に使われる事 (その通常の解釈ではなく) を示すために使用されている。
たとえば、"Joe\,Smith" はフィールドの 4 番目の文字がコンマである一
つの 9 文字のユーザフィールドを示すために使用される。
一般的にホストはそれぞれのホストにおいてアドレスを特定するために転
送される名前によって知る事ができる。ドメインの名前要素は公式名であ
る事に注意 -- ニックネームやエイリアスの仕様は許されない。
時々、ホストはトランザクション機能を知られず、通信がブロックされる。
この障害を回避するため、二つの数値形式もホスト "ネーム" に対して許
される。一つのフォームはポンド記号 "#" によって開始する 10 進数で
あり、これは、この数字がホストのアドレスである事を示す。別の形式は
"[123.288.37.2]" のようにピリオドで分割された小さな 10 進数整数値
で、ブラケットで閉じられている。これは四つの 8 ビットフィールドに
おける 32 ビット 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> ::= The standard names for links are registered with
the Network Information Center.
<protocol> ::= The standard names for protocols are
registered with the Network Information Center.
<daytime> ::= <SP> <date> <SP> <time>
<date> ::= <dd> <SP> <mon> <SP> <yy>
<time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
<dd> ::= the one or two decimal integer day of the month in
the range 1 to 31.
<mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
"JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
<yy> ::= the two decimal integer year of the century in the
range 00 to 99.
<hh> ::= the two decimal integer hour of the day in the
range 00 to 24.
<mm> ::= the two decimal integer minute of the hour in the
range 00 to 59.
<ss> ::= the two decimal integer second of the minute in the
range 00 to 59.
<zone> ::= "UT" for Universal Time (the default) or other
time zone designator (as in [2]).
-------------------------------------------------------------
Return Path Example
Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA>
Example 9
-------------------------------------------------------------
-------------------------------------------------------------
Time Stamp Line Example
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 Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT
Example 10
-------------------------------------------------------------
4.2. SMTP REPLIES
SMTP コマンドの応答はリクエストの同期とメール転送のプロセスにおける動
作を保証し、転送側 SMTP が常に送信先 SMTP の状態を知る事を保証するため
に工夫されている。それぞれのコマンドは正確に一つの応答を生成しなければ
ならない。
コマンド - 応答シーケンスの詳細は Section 5.3 の Sequencing と
Section 5.4 の State Diagrams で明確にされる。
SMTP 応答は (三文字の英数文字として転送される) 三桁の数字とそれに続く
あるテキストで構成される。この数字は次にどんな状態を入れるかを決定す
るためのオートマトンによる使用に対して意味を持つ; テキストは人間の
ユーザに対して意味を持つ。これは、送信側 SMTP がテキストを調べる必要
がなく、ユーザに対して適切にそれを破棄するか渡すかという十分にエン
コードされた情報をこの三桁の数字が含んでいる事を意味する。特に、この
テキストは受信先依存、状況依存であり、それぞれの応答コードに対して多
様性を持つだろう。応答コードの理論の論議は Appendix E において与えら
れる。正式には、応答はシーケンスとして定義されている: 三桁の数字コー
ド、<SP>、一行分のテキスト、そして <CRLF> もしくは複数行応答 (Appendix
E で定義されている) である。EXPN と HELP コマンドは通常の状態で複数行
応答をもたらすと予想されるが、しかしながら複数行応答はどのようなコマ
ンドに対しても返す事ができる。
4.2.1. REPLY CODES BY FUNCTION GROUPS
500 Syntax error, command unrecognized
[これはコマンド行が長すぎるようなエラーも包括できる]
501 Syntax error in parameters or arguments
502 Command not implemented
503 Bad sequence of commands
504 Command parameter not implemented
211 System status, or system help reply
214 Help message
[受信側の使い方や特殊な非標準コマンドの使い方情報; この応答は
人間のユーザに対してのみ有用である]
220 <domain> Service ready
221 <domain> Service closing transmission channel
421 <domain> Service not available, closing transmission channel
[これは、もしこのサービスがシャットダウンされなければならない
なら、どんなコマンドに対しても返される可能性がある]
250 Requested mail action okay, completed
251 User not local; will forward to <forward-path>
450 Requested mail action not taken: mailbox unavailable
[E.g., メールボックスがビジーな場合]
550 Requested action not taken: mailbox unavailable
[E.g., メールボックスが見つからなかったりアクセスできない場合]
451 Requested action aborted: error in processing
551 User not local; please try <forward-path>
452 Requested action not taken: insufficient system storage
552 Requested mail action aborted: exceeded storage allocation
553 Requested action not taken: mailbox name not allowed
[E.g., メールボックスの構文が不正な場合]
354 Start mail input; end with <CRLF>.<CRLF>
554 Transaction failed
4.2.2. NUMERIC ORDER LIST OF REPLY CODES
211 System status, or system help reply
214 Help message
[受信側の使い方や特殊な非標準コマンドの使い方情報; この応答は
人間のユーザに対してのみ有用である]
220 <domain> Service ready
221 <domain> Service closing transmission channel
250 Requested mail action okay, completed
251 User not local; will forward to <forward-path>
354 Start mail input; end with <CRLF>.<CRLF>
421 <domain> Service not available, closing transmission channel
[これは、もしこのサービスがシャットダウンされなければならない
なら、どんなコマンドに対しても返される可能性がある]
450 Requested mail action not taken: mailbox unavailable
[E.g., mailbox busy]
451 Requested action aborted: local error in processing
452 Requested action not taken: insufficient system storage
500 Syntax error, command unrecognized
[This may include errors such as command line too long]
501 Syntax error in parameters or arguments
502 Command not implemented
503 Bad sequence of commands
504 Command parameter not implemented
550 Requested action not taken: mailbox unavailable
[E.g., mailbox not found, no access]
551 User not local; please try <forward-path>
552 Requested mail action aborted: exceeded storage allocation
553 Requested action not taken: mailbox name not allowed
[E.g., mailbox syntax incorrect]
554 Transaction failed
4.3. SEQUENCING OF COMMANDS AND REPLIES
送信側と受信側の間の通信は、送信側によって制御される交互の交換という意
図がある。送信側はコマンドを発行し、受信側は応答で答える。送信側は以後
のコマンドを送る前にこのレスポンスを待たなければならない。
一つの重要な応答は接続グリーティングである。通常、接続が完了すれば受信
側は 220 "Service ready" 応答を送るだろう。送信側はどのようなコマンド
を送る前にもこのグリーティングメッセージを待つべきである。
注意: すべてのグリーティング型応答は応答コードに続く最初の言葉とし
てサーバホストの公式名を持つ。
たとえば、
220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF>
下記のテーブルはそれぞれのコマンドに対する成功と失敗のどちらかの応答を
りすとしている。これらは厳密に支持されなければならない; 受信側は応答に
テキストを代用できるが、コード番号と記述されたコマンド応答シーケンスに
よって意味を成す意味と動作は変えられない。
COMMAND-REPLY SEQUENCES
それぞれのコマンドはその可能な応答付きでリストされる。可能な応答の
前に付けられているプレフィクスは、予備のための "P" (SMTP において
使用されていない)、中継のための "I"、成功に対する "S"、失敗に対す
る "F"、そしてエラーのための "E" である。421 応答 (サービスが利用
できない、転送チャンネルを閉じている) は、もし SMTP 受信先がシャッ
トダウンされなければならない事を分かればどのようなコマンドにも与え
られるだろう。このリストは Section 4.4 の State Diagrams を元に形
成されている。
CONNECTION ESTABLISHMENT
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. STATE DIAGRAMS
以下は簡単な SMTP 実装に対する状態ダイアグラムである。応答コードの最初
の数字のみが使用されている。コマンドのグループ化はそれぞれのコマンドに
対するモデルを構築する事によって決定され、構造上同一のモデルが付随する
コマンドと共に制御されている。
それぞれのコマンドに対して、三つの可能な結果 "success" (S), "failure"
(F), "error" (E) が存在する。下記の状態ダイアグラムにおいて、われわれ
は "begin" に対して記号 B を使用し、"wait for reply" に対して記号 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. DETAILS
4.5.1. MINIMUM IMPLEMENTATION
SMTP 作業テーブルを作るため、以下の最小実装がすべての受信側に要求
される:
COMMANDS -- HELO
MAIL
RCPT
DATA
RSET
NOOP
QUIT
4.5.2. TRANSPARENCY
データ透過性に対するある準備なしに、文字シーケンス "<CRLF>.<CRLF>"
はメールテキストを終了し、ユーザによって送られる事はできない。一般
的に、ユーザはこのような "禁止" シーケンスを意識していない。透過的
に転送される構成されたテキストをユーザに許可するため、以下の手順が
使用される。
1. メールテキストの行を送る前に、転送側 SMTP は行の先頭文字を
チェックする。もしそれがピリオドであれば、行の先頭に一つの追加
ピリオドが挿入される。
2. メールテキストの１行が受信先 SMTP によって受信された時、受
信側はその行をチェックする。もしその行が単一のピリオドから成り
立てば、それはメールの終了である。もし先頭の文字がピリオドで、
その他の文字がその行に存在するなら、最初の文字は削除される。
メールデータは 128 ASCII 文字のどんな物も含む事ができる。すべての
文字は、フォーマットエフェクタとその他の制御文字を含む受け取り人の
メールボックスに配信される。もし転送チャンネルが 8 ビットバイト
(オクテット) データストリームを供給するなら、7 ビット ASCII コード
を右側につめて最上位ビットを 0 にクリアして転送される。
いくつかのシステムにおいて、それが受信され保存されるようにデー
タを変化させる必要があるかもしれない。これは、ホスト上で ASCII
以外のローカル文字セットを使用していたり、文字列ではなくレコー
ドとしてデータを保存するようなホストに対して必要となるかもしれ
ない。もしこのような変化が必要ならば、 -- 特にもしこの変化が伝
達されるメールにも適用されるなら -- このような変化は可逆でなけ
ればならない。
4.5.3. SIZES
最小値・最大値を必要とするいくつかのオブジェクトが存在する。これは、
それぞれの実装がこれらのサイズの最小値のオブジェクトを受信できなけ
ればならず、これらのサイズより大きいオブジェクトを送ってはならない
という事である。
****************************************************
* *
* TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
* TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
* OF THESE OBJECTS SHOULD BE USED. *
* *
****************************************************
user
ユーザ名の総最大長は 64 文字である。
domain
ドメイン名や番号の総最大長は 64 文字である。
path
reverse-path や forward-path の総最大長は 256 文字である
(句読点や要素セパレータも含む)。
command line
コマンド文字や <CRLF> を含むコマンド行の総最大長は 512 文
字である。
reply line
応答コードと <CRLF> を含む応答行の総最大長は 512 文字であ
る。
text line
<CRLF> を含むテキスト行の総最大長は 1000 文字である (ただ
し透過性のために追加された先頭のピリオドは含まない)。
recipients buffer
バッファリングされなければならない受取人の総最大数は 100
人である。
****************************************************
* *
* TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
* TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
* OF THESE OBJECTS SHOULD BE USED. *
* *
****************************************************
これらの制限によるエラーは応答コードを使用する事によって報告される
だろう。たとえば:
500 Line too long.
501 Path too long
552 Too many recipients.
552 Too much mail data.
APPENDIX A
TCP 転送サービス
転送制御プロトコル (TCP: Transmission Control Protocol) [3] は ARPA
インターネットやインターネットワークプロトコルのための US DoD 標準に
従うすべてのネットワークにおいて使用される。
接続の確立
SMTP 転送チャンネルは、送信側プロセスポート U と受信側プロセス
ポート L 間で確立した TCP 接続である。この単一の全二重接続は転送
チャンネルとして使用される。このプロトコルはサービスポート 25
(8 進数で 31)、L=25 として割り当てられている。
データ転送
TCP 接続は 8 ビットバイトの転送をサポートしている。SMTP データは
7 ビット ASCII 文字である。それぞれの文字は最上位ビットがゼロに
クリアされた 8 ビットバイトとして転送される。
APPENDIX B
NCP 転送サービス
ARPANET Host-to-Host Protocol [4] (Network Control Program によって
実装されている) は ARPANET において使用されている。
接続の確立
SMTP 転送チャンネルは、送信側プロセスソケット U と受信側プロセスソ
ケット L 間の NCP 経由で確立される。Initial Connection Protocol [5]
は単一接続のペアにおいてもたらされる。この接続のペアは転送チャンネ
ルとして使用される。このプロトコルはコンタクトソケット 25 (8 進数で
31)、L=25 として割り当てられている。
データ転送
NCP データ接続は 8 ビットバイトモデルにおいて確立される。SMTP デー
タは 7 ビット ASCII 文字である。それぞれの文字は最上位ビットがゼロ
にクリアされた 8 ビットバイトとして転送される。
APPENDIX C
NITS
Network Independent Transport Service [6] を使用する事ができる。
接続の確立
SMTP 転送チャンネルは送信側プロセスと受信側プロセス間の NITS 経由
で確立される。送信側プロセスは CONNECT プリミティブを実行し、待機
中のプロセスは ACCEPT プリミティブを実行する。
データ転送
NITS 接続は 8 ビットバイトの転送をサポートしている。SMTP データは
7 ビット ASCII 文字である。それぞれの文字は最上位ビットがゼロにク
リアされた 8 ビットバイトとして転送される。
APPENDIX D
X.25 転送サービス
Public Data Networks によって直接供給されるような X.25 サービス [7]
を使用する事ができるが、TCP のような信頼できる end-to-end プロトコル
が X.25 接続の上層で使用される事が提案される。
APPENDIX E
応答コードの理論
応答それぞれの 3 桁の数字は特別な意味を持っている。最初の数字はレス
ポンスが肯定的か否定的か、もしくは不完全かを示している。単純な送信側
SMTP はそれが次に行う動作 (設計、再実行、削除など) をこの最初の数字
を簡単に調べる事で決定する事ができる。どのような種類のエラー (たとえ
ばメールシステムエラー、コマンド構文エラーなど) が発生したかを適切に
知りたい送信側 SMTP は二番目の数字を調べる事ができ、情報の詳細な過程
のために三番目の数字を予約しておく。
応答コードの最初の文字として 5 つの値がある。
1yz 肯定的予備応答
コマンドが受け入れられたが、要求された動作は未定として保持
されて、この応答における情報の確認を保留している。送信側
SMTP は動作を続けるか中止するかを記述する別のコマンドを送
るべきである。
[注意: SMTP はこの種類の応答が可能などんなコマンドも
持っていないし、続けるか中止するかのコマンドも持って
いない]
2yz 肯定的完了応答
要求された動作がうまく完了した。新しいリクエストをはじめ
る事ができる。
3yz 肯定的中間応答
コマンドは受け入れられたが、要求された動作は未定として保持
され、以後の情報の受領が保留される。送信側 SMTP はこの情報
に記述されている別のコマンドを送るべきである。この応答はコ
マンドシーケンスグループにおいて使用される。
3yz 一時的な否定的完了応答
コマンドは受け入れられ、要求された動作は発生しなかった。し
かしながら、このエラー状況は一時的な物であり、動作を再度要
求する事ができる。送信側はコマンドシーケンスの最初に戻るべ
きである。二つの異なるサイト (送信側と受信側 SMTP) が解釈
において合意しなければならないなら、"一時的" にとって意味
がある事を割り当てるのは難しい。このカテゴリにおけるそれぞ
れの応答は異なる時刻値を持つだろうが、送信側 SMTP は再試行
する事を推奨される。応答が 4yz か 5yz カテゴリ (下記参照)
のどちらと一致するか決定するルールは、コマンドの形式や、送
信側や受信側の特性においてどんな変更も無しに繰り返す事がで
きるなら 4yz 応答となる (e.g., コマンドは同じく繰り返され、
受信側は新しい実装をしない)。
5yz 恒久的な否定的完了応答
コマンドは受け入れられず、要求された動作は発生していない。
送信側 SMTP は (あるシーケンスにおける) 正確な要求の繰り返
しをとどめられる。いくつかの "恒久的" エラー状況は、人間の
ユーザが以後ある地点の直接の動作 (スペルを変更した後や、
ユーザがアカウントステータスを変更した後など) によるコマン
ドシーケンスを再初期化するために送信側 SMTP を指定したいか
もしれないため、訂正する事ができる。
二番目の数字は詳細なカテゴリにおけるレスポンスを符号化している:
x0z 構文 -- これらの応答は、構文エラーや、機能的なカテゴリの
どれとも一致しない構文的に正しいコマンド、実装されていな
かったり不必要なコマンドを示している。
x1z 情報 -- これらは状態やヘルプのような情報に対するリクエス
トの応答である。
x2z 接続 -- これらは転送チャンネルを示す応答である。
x3z まだ詳述されない。
x4z まだ詳述されない。
x5z メールシステム -- これらの応答は要求された転送の受信側
vis-a-vis メールシステムや他のメールシステム動作の状態を
示す。
三番前の数字は二番目の数字によって示されたそれぞれのカテゴリにおけ
る詳細な過程の意味を与える。応答のリストはこれを表している。それぞ
れの応答テキストは義務ではないが推奨され、それに割り当てられている
コマンドにしたがって変化するだろう。言い換えれば、応答コードはこの
章における仕様を正確に基づかなければならない。受信側実装はここで記
されているコードとわずかに異なる状況に対して新しいコードを創り出す
べきではないが、適合しているコードは既に定義されている。
たとえば、送信側 SMTP にどんな新しい情報も提供しない NOOP のような
コマンドは 250 応答を返すだろう。コマンドが未実装の
non-site-specific 動作を要求するならレスポンスは 502 である。
これの改良は実装されているコマンドに対する 504 応答であるが、これは
未実装パラメータを要求する。
応答テキストは単一の行よりも長いかもしれない; このような場合、完全なテ
キストは応答を送信するのを中断する時、送信側 SMTP が知っているように
マークされなければならない。これは複数行応答を示すための特別なフォー
マットを要求する。
複数行応答に対するこのフォーマットは、最後の以外のそれぞれの行が、
テキストを後に続けるハイフン "-" (マイナスとしても知られる) によっ
て応答コードのすぐ後に続いてる。最後の行は応答コードで始まり、すぐ
後ろに <SP> と付加的なあるテキストと <CRLF> が続く。
たとえば:
123-First line
123-Second line
123-234 text beginning with numbers
123 The last line
多くの場合、送信側 SMTP は単純に後ろに <SP> を伴う行頭の応答を検索
する必要があり、先行するすべての行は無視される。いくつかの場合、
応答 "テキスト" に送信側にとって重要なデータがある。送信側は現在の
状況からこれらの場合を知るだろう。
APPENDIX F
シナリオ
この章は SMTP セッションのいくつかのタイプの完全なシナリオを紹介する。
典型的な SMTP トランザクションシナリオ
この SMTP の例はホスト USC-ISIF の Smith によってホスト BBN-UNIX の
Jones, Green, Brown に送られるメールを表している。ここでわれわれはホ
スト USC-ISIF がホスト BBN-UNIX に直接コンタクトする事を想定している。
メールは 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:<Smith@USC-ISIF.ARPA>
R: 250 OK
S: RCPT TO:<Jones@BBN-UNIX.ARPA>
R: 250 OK
S: RCPT TO:<Green@BBN-UNIX.ARPA>
R: 550 No such user here
S: RCPT TO:<Brown@BBN-UNIX.ARPA>
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
Scenario 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:<Smith@ISI-VAXA.ARPA>
R: 250 OK
S: RCPT TO:<Jones@MIT-Multics.ARPA>
R: 250 OK
S: RCPT TO:<Green@MIT-Multics.ARPA>
R: 550 No such user here
S: RSET
R: 250 OK
S: QUIT
R: 221 MIT-Multics.ARPA Service closing transmission channel
Scenario 2
-------------------------------------------------------------
メール伝達シナリオ
-------------------------------------------------------------
Step 1 -- Source Host to Relay Host
R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
S: HELO MIT-AI.ARPA
R: 250 USC-ISIE.ARPA
S: MAIL FROM:<JQP@MIT-AI.ARPA>
R: 250 OK
S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA>
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 <JQP@MIT-AI.ARPA>
S: Subject: The Next Meeting of the Board
S: To: Jones@BBN-Vax.ARPA
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
Step 2 -- Relay Host to Destination Host
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:JQP@MIT-AI.ARPA>
R: 250 OK
S: RCPT TO:<Jones@BBN-VAX.ARPA>
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 <JQP@MIT-AI.ARPA>
S: Subject: The Next Meeting of the Board
S: To: Jones@BBN-Vax.ARPA
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
Scenario 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 <Admin.MRC@SU-SCORE.ARPA>
S: SEND FROM:<EAK@MIT-MC.ARPA>
R: 250 OK
S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
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
Scenario 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 <Admin.MRC@SU-SCORE.ARPA>
S: SEND FROM:<EAK@MIT-MC.ARPA>
R: 250 OK
S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
R: 450 User not active now
S: RSET
R: 250 OK
S: MAIL FROM:<EAK@MIT-MC.ARPA>
R: 250 OK
S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
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
Scenario 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 <Admin.MRC@SU-SCORE.ARPA>
S: SOML FROM:<EAK@MIT-MC.ARPA>
R: 250 OK
S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
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
Scenario 6
-------------------------------------------------------------
メーリングリストシナリオ
最初に二つのメーリングリストのそれぞれが異なるホストの分割セッショ
ンにおいて広げられる。それからメッセージは伝達ホスト経由でそれぞれ
のリスト (重複していない) に現れる全員に送られる。
-------------------------------------------------------------
Step 1 -- Expanding the First List
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-<ABC@MIT-MC.ARPA>
R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
R: 250-Xenon Y. Zither <XYZ@MIT-AI.ARPA>
R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
R: 250-<joe@foo-unix.ARPA>
R: 250 <xyz@bar-unix.ARPA>
S: QUIT
R: 221 MIT-AI.ARPA Service closing transmission channel
Step 2 -- Expanding the Second List
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 <ABC@MIT-MC.ARPA>
R: 250-<XYZ@MIT-AI.ARPA>
R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
R: 250-<fred@BBN-UNIX.ARPA>
R: 250 <xyz@bar-unix.ARPA>
S: QUIT
R: 221 MIT-MC.ARPA Service closing transmission channel
Step 3 -- Mailing to All via a Relay Host
R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
S: HELO SU-SCORE.ARPA
R: 250 USC-ISIE.ARPA
S: MAIL FROM:<Account.Person@SU-SCORE.ARPA>
R: 250 OK
S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA>
R: 250 OK
S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA>
R: 250 OK
S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA>
R: 250 OK
S: RCPT
TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
R: 250 OK
S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA>
R: 250 OK
S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA>
R: 250 OK
S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA>
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
Scenario 7
-------------------------------------------------------------
フォーワーディングシナリオ
-------------------------------------------------------------
R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
S: HELO LBL-UNIX.ARPA
R: 250 USC-ISIF.ARPA
S: MAIL FROM:<mo@LBL-UNIX.ARPA>
R: 250 OK
S: RCPT TO:<fred@USC-ISIF.ARPA>
R: 251 User not local; will forward to <Jones@USC-ISI.ARPA>
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
Scenario 8
-------------------------------------------------------------
-------------------------------------------------------------
Step 1 -- Trying the Mailbox at the First Host
R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
S: HELO LBL-UNIX.ARPA
R: 250 USC-ISIF.ARPA
S: MAIL FROM:<mo@LBL-UNIX.ARPA>
R: 250 OK
S: RCPT TO:<fred@USC-ISIF.ARPA>
R: 251 User not local; will forward to <Jones@USC-ISI.ARPA>
S: RSET
R: 250 OK
S: QUIT
R: 221 USC-ISIF.ARPA Service closing transmission channel
Step 2 -- Delivering the Mail at the Second Host
R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready
S: HELO LBL-UNIX.ARPA
R: 250 USC-ISI.ARPA
S: MAIL FROM:<mo@LBL-UNIX.ARPA>
R: 250 OK
S: RCPT TO:<Jones@USC-ISI.ARPA>
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
Scenario 9
-------------------------------------------------------------
多すぎる受信者のシナリオ
-------------------------------------------------------------
R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready
S: HELO USC-ISIF.ARPA
R: 250 BERKELEY.ARPA
S: MAIL FROM:<Postel@USC-ISIF.ARPA>
R: 250 OK
S: RCPT TO:<fabry@BERKELEY.ARPA>
R: 250 OK
S: RCPT TO:<eric@BERKELEY.ARPA>
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:<Postel@USC-ISIF.ARPA>
R: 250 OK
S: RCPT TO:<eric@BERKELEY.ARPA>
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
Scenario 10
-------------------------------------------------------------
実際の実装が Section 4.5.3 において詳述されているような多くの受信
者をハンドルしなければならない事に注意。
GLOSSARY
ASCII
情報交換のための American Standard Code [1]。
コマンド
送信側 SMTP によって受信側 SMTP に送られるメールサービス動作のための
要求。
ドメイン
メールシステムでのホストコンピュータの、構造化された階層構造グローバ
ル文字列アドレス。
メールデータの終了インジケータ
メールデータの終了を示す文字列の特別なシーケンス。特に、キャリッジリ
ターン、ラインフィード、ピリオド、キャリッジリターン、ピリオドのこの
順番通りの 5 文字。
ホスト
メールボックスや SMTP プロセスにあるインターネットワーク環境のコン
ピュータ。
行
<CRLF> で終了する ASCII 文字のシーケンス。
メールデータ
任意の長さを持つ ASCII 文字のシーケンス。Standard for the ARPA
Internet Text Message (RFC 822 [2]) における標準セットと一致する。
メールボックス
メールが誰に送信されるかというユーザを示す文字列 (アドレス)。通常メー
ルボックスはホストとユーザ詳述で構成される。標準メールボックス名慣例
は "user@domain" として定義される。追加的に、メールが保存される
"container"。
受信側 SMTP プロセス
送信側 SMTP プロセスとの協調においてメールを転送するプロセス。転送
サービス経由で確立される接続を待機している。送信側 SMTP から SMTP
コマンドを受信し、応答を返し、詳述されている処理を実行する。
応答
応答はコマンドのレスポンスとして転送チャンネル経由で受信側から送信側
に送られる (肯定的もしくは否定的) 通知である。応答の一般的な形式はテ
キスト文字列が後に続く (エラーコードを含む) 完了コードである。この
コードはプログラムによって使用され、通常テキストは人間のユーザに対し
ての目的を持つ。
送信側 SMTP プロセス
受信側 SMTP と協調してメールを転送するプロセス。ローカル言語がユーザ
インターフェースコマンド／応答交換で使用されるだろう。送信側 SMTP は
転送サービス接続を開始する。SMTP コマンドを開始し、応答を受信し、
メール転送をつかさどる。
セッション
トランザクションチャンネルが開いている間に発生する交換のセット。
トランザクション
一つ以上の受取人に転送される一つのメッセージを必要とする交換のセット。
転送チャンネル
コマンド、応答、メールテキストを交換するための、送信側 SMTP と受信側
SMTP の間の全二重通信経路。
転送サービス
信頼できるストリーム指向データ通信サービス。NCT, TCP, NITS など。
ユーザ
メール転送サービスを行う事を望んでいる人間 (もしくは人間のためのプロ
セス)。追加的に、コンピュータメールの受取人。
言葉
印字可能な文字のシーケンス。
<CRLF>
キャリッジリターンとラインフィードの (この順番通りの) 文字。
<SP>
空白文字。
REFERENCES
[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.