RFC821 日本語訳
0821 Simple Mail Transfer Protocol. J. Postel. August 1982. (Format: TXT=124482 bytes) (Obsoletes RFC0788) (Obsoleted by RFC2821) (Also STD0010) (Status: STANDARD)
RFC一覧
英語原文
RFC 821
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
RFC 821 August 1982
Simple Mail Transfer Protocol
目次
1. はじめに ...................................................... 1
2. SMTP 方式 ..................................................... 2
3. SMTP 手順 ..................................................... 4
3.1. 郵送 ..................................................... 4
3.2. 回送 ..................................................... 7
3.3. 確認と展開 ............................................... 8
3.4. 送信と郵送（メーリング） ................................ 11
3.5. 開始と終了 .............................................. 13
3.6. 中継 .................................................... 14
3.7. ドメイン（Domains） ..................................... 17
3.8. 役割変更 ................................................ 18
4. SMTP 仕様 .................................................... 19
4.1. SMTP 命令 ............................................... 19
4.1.1. 命令意味 .............................................. 19
4.1.2. 命令構文 .............................................. 27
4.2. SMTP 応答 ............................................... 34
4.2.1. 機能別応答コード ...................................... 35
4.2.2. 数値順応答コード ...................................... 36
4.3. 命令と応答の配列 ........................................ 37
4.4. 状態図式 ................................................ 39
4.5. 詳細 .................................................... 41
4.5.1. 最小装備 .............................................. 41
4.5.2. 透過性 ................................................ 41
4.5.3. サイズ ................................................ 42
付録 A: TCP ..................................................... 44
付録 B: NCP ..................................................... 45
付録 C: NITS .................................................... 46
付録 D: X.25 .................................................... 47
付録 E: 応答コードの理論 ........................................ 48
付録 F: シナリオ ................................................ 51
用語辞典 ......................................................... 64
参照資料 ......................................................... 67
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に接続された処理を通じて中継することによって、交流することができ
ます。より特異的にはメールは、異なる転送システムのホスト間を両方の転
送システムのホストによって、中継されることができます。
[#^]
Postel [Page 1]
August 1982 RFC 821
Simple Mail Transfer Protocol
2. SMTP 方式
SMTP設計は交流の以下のモデルに基づいています：利用者メール請求の結果
として、sender-SMTP（送信-SMTP）は双方向転送チャンネル（流れ）をreceiver-
SMTP（受信-SMTP）を確立します。受信-SMTPは、最終行き先もしくは途中で
あるかもしれません。SMTP命令は送信-SMTPによって生成され、受信-SMTPに
送られます。命令への応答で、SMTP応答は受信-SMTPから送信-SMTPへ送られ
ます。
一旦転送チャンネルが確立すると、SMTP-sender（SMTP-送信）は、メール送
信を示唆するMail命令を送ります。SMTP-receiveがメールを受け入れると、
それはOK応答で反応します。そこで、SMTP-senderは、メールの受取人を示
唆するRCPT命令を送ります。SMTP-receiverがその受取人むけのメールを受
け入れたら、それはOK応答で反応します；ない場合その受取人（しかし、全
てのメール処理ではなく）を拒絶する応答で反応します。SMTP-senderと
SMTP-receiverは、数人の受取人と交渉します。その受取人達と交渉する場
合SMTP-sendeは、mail data、特別な文字連続体で終る、を送ります。
SMTP-receiverがうまくmail dataを処理すれば、それはOK応答で反応しま
す。The dialog is purposely lock-step, one-at-a-time.
-------------------------------------------------------------
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Sender- |Commands/Replies| Receiver-|
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
Sender-SMTP Receiver-SMTP
（送信者-SMTP） （受信者-SMTP）
SMTP使用モデル
図 1
-------------------------------------------------------------
SMTPは、メールの転送用の機構を提供します；二つのホストが同じ転送サー
ビスに接続されている場合送信利用者ホストから受信利用者ホストへ直接的
[Page 2] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
にもしくは元と行き先ホストが同じ転送サービスに接続されていない場合一
つ以上の中継SMTP-サーバー経由で。
中継能力を提供することができるために、SMTP-serverは行き先メールボッ
クス名と同じように行き先ホストの名前を供給されなければなりません。
MAIL命令の引き数は、そのメールが誰からかを特定する、反転-経路です。
RCPT命令の引き数は、このメールはだれにかを特定する、前方-経路です。
前方-経路は資源ルートで、一方反転-経路は返却ルート（中継メッセージで
エラーが生じた場合、送信者にメッセージを返却するのに使われます）で
す。
同じメッセージが複数の受取手に送られる場合、SMTPは同じ行き先ホストの
受取手全員にデーターの複写の一つだけの転送を奨励します。
メール命令と応答は厳格な構文を持っています。応答も数値コードを持って
います。以下において、命令と応答を実際に使用した例が現われます。命令
と応答の完全なリストは、仕様書のセクション4で出てきます。
命令と応答は大文字小文字を区別しません。つまり、命令もしくは応答単語
は、大文字・小文字もしくは大文字と小文字の混在です。これはメールボッ
クス利用者名では正しくないことに注意して下さい。ホストによっては、利
用者名は大文字小文字を区別し、SMTP装備は、メールボックス引き数に現わ
れるので、利用者名が大文字か小文字かを保存するよう注意しなければなり
ません。ホスト名は大文字小文字を区別しません。
命令と応答はASCII文字セット[1] の文字から構成されます。転送サービス
が8-ビットバイト（オクテット）転送チャンネルを提供する場合、各7-ビッ
ト文字は上位のビットをゼロにしたオクテットに正しく調整されて転送され
ます。
命令もしくは応答の一般的な書式を特定する場合、引き数（もしくは特別な
記号）はメタ-言語的な変数（もしくは定数）、例えば""もしくは
""、によって表示されます。ここで、鈎括弧はこれらがメタ-言
語的な変数であることを指しています。しかし、引き数によっては鈎括弧を
文字通りに使うものもあります。例えば、実際の反転-経路は鈎括弧で囲ま
れ、例えば""はの例です（鈎括弧
は命令もしくは応答の中で実際に転送されます）。
[#^]
Postel [Page 3]
August 1982 RFC 821
Simple Mail Transfer Protocol
3. SMTP 手順
このセクションは、SMTPで使用される手順を幾つかの部分にわけて提示しま
す。最初に、メール処理として定義された基本的なメール手順がきます。次
いで、メールを返送すること・メールボックス名を検証すること・メールリ
ストを展開すること・メールボックスの代わりにもしくは結合して、端末に
送信することそして交換を開始と終了すること、の説明です。このセクショ
ンを通して、一部の命令と応答の例があり、完全なシナルオは付録 Fにあり
ます。
3.1. 郵送（MAIL）
SMTPメール処理に三つの段階があります。処理は、MAIL命令ではじま
り、この命令は送信者情報を与えます。続いて、ひとつ以上の一連の
RCPT 命令は、受信者情報を与えるます。DATA 命令はメールデーターを
与えます。そして最後に、メールデーター指標の終が処理を確認しま
す。
手順の最初の段階はMAIL 命令です。は元のメールボッ
クスを内容としています。
MAIL FROM:
この命令はSMTP受信者に新しいメール処理がはじまっていることを知
らせ、如何なる受取人もしくはメールデーターを含めて、全ての状態
表とバッファーを再設定することを知らせます。エラーを報告するの
に使用される反転-経路（reverse-path）を与えます。受け入れる
と、受信SMTPは250もしくはOK応答を返します。
は、メールボックス（mailbox）だけを内容にしてい
るのではありません。はホストと元のメールボックス
の反転資源経路一覧です。で最初のホストは、この命
令を送信するホストでなければなりません。
手順の二番目の段階は、RCPT 命令です。
RCPT TO:
この命令は、受取人を識別同定する前方-経路（forward-path）をあ
たえます。受け入れられると、受信者-SMTPは250 OK応答を返し、そ
の前方-経路を保存します。受信者が不明なら、受信者-SMTPは失敗応
答 550 を返します。手順でのこの二番目の段階は、何度も繰り返え
されることができます。
[Page 4] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
は、メールボックス（mailbox）だけを内容にしてい
るのではありません。はホストと元のメールボックス
の反転資源経路一覧です。で最初のホストは、この命
令を受信するホストでなければなりません。
この手順の三番目の段階は、DATA 命令です。
DATA
受け入れられたら、受信者-SMTPは中間応答 354 を返し、続く行全て
がメッセージテキストである、と考えます。テキストの終を受信保存
したら、SMTP受信者は250 OK応答を送ります。
メールデーターは転送チャンネルに送られるので、メールデーターの
終は、命令と応答ダイアログが再開できること、を示唆されなければ
なりません。SMTPは、ピリオドだけを内容とする行を送信することに
よって、メールデーターの終を示唆します。透明な手順は、利用者の
テキストと干渉する書式を回避するのに、使用されます（セクション
4.5.2 参照）。
メールデーターは、Date・Subject・To・Cc・From [2] のような
メモヘッダー用語を含んでいること、に注意して下さい。
メールデーターの終も、メール処理を確認し、受信者-SMTPに、では
保存された受取人とメールデーターを処理しますと伝えます。受け入
れられたら、受信者-SMTPは250 OK応答を返します。DATA 命令は、
メール処理が完全でないかもしくは資源が入手できない場合だけに失
敗すべきです。
以上の手順は、メール処理の例です。これらの命令は、上で議論された
順序でだけ使用されなければなりません。例1（以下の）で、メール処理
でのこれらの命令の使い方を図式化して表示しています。
Postel [Page 5]
August 1982 RFC 821
Simple Mail Transfer Protocol
-------------------------------------------------------------
SMTP手順の事例
これの SMTP 事例は、ホストAlpha.ARPAでSmith氏がホスト
Beta.ARPAのJones・ GreenそしてBrown氏に送ったメールを示してい
ます。ここでは、ホストAlphaは直接Betaと接触している、と仮定し
ています。
S: MAIL FROM:
R: 250 OK
S: RCPT TO:
R: 250 OK
S: RCPT TO:
R: 550 No such user here
S: RCPT TO:
R: 250 OK
S: DATA
R: 354 Start mail input; end with .
S: Blah blah blah...
S: ...etc. etc. etc.
S: .
R: 250 OK
メールはJones と Brown氏を受け入れています。Green氏はホスト
Betaにメールボックス（郵便箱）を持っていません。
例 1
-------------------------------------------------------------
[Page 6] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
3.2. 回送（FORWARDING）
の行き先情報が正しくないが、受信者-SMTPは正しい宛名
を知っていると言ったケースもあります。そのような場合、以下の応答
の一つで、送信者が正しい行き先と接触することができます。
251 User not local; will forward to
この応答は、受信者-SMTPは利用者の郵便箱が別のホストであるこ
とを知っていることを示唆しそして今後使用する正しいforward-
pathを示唆しています。ホストか利用者もしくは両方とも異なる
かもしれないことに注意してください。受信者はメッセージを配
達することの責任があります。
551 User not local; please try
この応答は、受信-SMTP は利用者郵便箱が別のホストにあること
を知っていることを示唆し、そして使用すべき正しい forward-
path を示唆しています。ホストか利用者もしくは両者が異なるか
もしれないことに注意して下さい。受信者がこの利用者宛のメー
ルを受け取ることを拒否し、送信者は提供された情報に従って
メールを送信し直すかもしくは元の利用者にエラー応答を返さな
ければなりません。
例2は、これらの応答の使用を図式表示しています。
-------------------------------------------------------------
回送の事例
S: RCPT TO:
R: 251 User not local; will forward to
または、
S: RCPT TO:
R: 551 User not local; please try
例 2
-------------------------------------------------------------
Postel [Page 7]
August 1982 RFC 821
Simple Mail Transfer Protocol
3.3. 確認と展開（VERIFYING AND EXPANDING）
SMTPは追加機能として、利用者の名前を確認もしくはメーリングリスト
を展開する、命令を提供しています。これは、文字列引数をもっている、
VRFYとEXPN命令でなされます。VRFY 命令では、文字列は利用者名で、応
答は利用者のフルネームを含むかもしれませんし、利用者の郵便箱を含
んでいなければなりません。EXPN 命令では、文字列はメーリングリスト
を識別同定し、そして多行の応答は利用者のフルネームを含んでいるか
もしれないし、メーリングリストでの郵便箱を与えなければなりませ
ん。
"User name"は、曖昧で、目的に応じて使用されます。ホストはVRFY or
EXPN 命令を装備しているなら、少なくともローカル郵便箱は"User
name"として認識されなければなりません。ホストが"User name"として
別の文字列を認識することを選ぶなら、それは許されます。
ホストによっては、命令データー構造が両タイプの実体を保持するかも
しれないので、メーリングリストと単一郵便箱の別名との区別が多少曖
昧なものがあります。メーリングリストの確認のために要求がなされた
場合ポジティブ応答、そのように接近されたメッセージの請求について
それがリストの全ての人に配達されるなら、が与えられることができ、
そうでないならエラーが報告されるべきです（例えば、" 550 それはメ
ーリングリストであって、利用者ではない"）。
多行応答（EXPNでは普通です）の場合、正確に一つの郵便箱が応答の各
行で特定されるべきです。どうにでも解釈される請求、例えば二つの
Smith's がある"VRFY Smith"、の場合その応答は"553 User ambiguous"
（553 利用者が曖昧）でなければなりません。
利用者名の確認のケースは、例3に示すように、廻りくどくないものです。
[Page 8] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
-------------------------------------------------------------
利用者名の確認例
S: VRFY Smith
R: 250 Fred Smith
もしくは、
S: VRFY Smith
R: 251 User not local; will forward to
もしくは、
S: VRFY Jones
R: 550 String does not match anything.
もしくは、
S: VRFY Jones
R: 551 User not local; please try
もしくは、
S: VRFY Gourzenkyinplatz
R: 553 User ambiguous.
例 3
-------------------------------------------------------------
Postel [Page 9]
August 1982 RFC 821
Simple Mail Transfer Protocol
メーリングリストの展開のケースは、例4に示すように、多行応答が必要
になります。
-------------------------------------------------------------
メーリングリストの展開例
S: EXPN Example-People
R: 250-Jon Postel
R: 250-Fred Fonebone
R: 250-Sam Q. Smith
R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
R: 250-
R: 250
もしくは、
S: EXPN Executive-Washroom-List
R: 550 Access Denied to You.
例 4
-------------------------------------------------------------
VRFY と EXPN 命令の文字列引数は、利用者名と郵便箱名の色々な装備に
よって、さらに厳密にされることはできません。システムによっては、
メーリングリストを内容としているファイル用のファイル名であること
が、EXPN 命令の引数にとって適切であるかもしれませんが、さらに色々
なインターネットでのファイル命名慣例があります。
VRFY and EXPN 命令は、最小装備（セクション 4.5.1）に含まれません
し、装備される際中継を越えて作動するように要求されていません。
[Page 10] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
3.4. 送信と郵送（SENDING AND MAILING）
SMTPの主目的は、利用者の郵便箱にメッセージを配達することです。ホ
ストによって提供される非常に似たサービスは、メッセージを利用者の
端末に配達するものです（提供された利用者はホスト上で作動中）。利
用者の郵便箱への配達は"mailing"（郵送）と言われ、利用者の端末への
配達は"sending"（送信）と言われます。多くのホストで送信の装備は郵
送の装備と殆ど同じですから、この二つの機能はSMTPでは結合されてい
ます。しかし、送信命令は必須最小装備（セクション 4.5.1）に含まれ
ていません。利用者は端末でメッセージを書くことを制御する能力を持
つべきです。大部分のホストは利用がそのようなメッセージを拒絶もし
くは受け入れることを可能にしています。
以下の三つの命令は、送信選択をサポートするのに定義されています。
これらは、MAIL命令の代りに、メール処理で使用され、この処理の特別
な構文について受信-SMTPに情報を伝えます：
SEND FROM:
SEND 命令は、メールデーターが利用者の端末に配達されることを
要求します。利用者がホスト上で作動中でない（端末メッセージ
を受け付けない）場合、450 応答がRCPT 命令に返えされます。
メール処理は、メッセージが端末に配達されれば、成功です。
SOML FROM:
Send Or MaiL 命令は、メールデーターが、利用者がホスト上で作
動中（端末メッセージを受け付ける）なら、利用者の端末に配達
することを要求します。利用者が作動中でない（端末メッセージ
を受け付けない）なら、そのときはメールデーターは利用者の郵
便箱に入ります。メール処理は、メッセージが端末かもしくは郵
便箱に配達されたら、成功です。
SAML FROM:
Send And MaiL 命令は、メールデーターは、利用者がホスト上で
作動中（端末メッセージを受け付けない）場合、利用者の端末に
配達されることを要求します。如何なる場合でもメールデーター
は、利用者の郵便箱に入ります。メール処理は、メッセージが郵
便箱に配達されれば、成功です。
Postel [Page 11]
August 1982 RFC 821
Simple Mail Transfer Protocol
MAIL 命令に使用されるのと同じ応答がこれらの命令でも使用されます。
[Page 12] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
3.5. 開始と終了（OPENING AND CLOSING）
転送チャンネルが開かれる際、ホストはそれと考えるホストと交流して
いることを確認するための交換があります。
以下の二つの命令は、転送チャンネル開始と終了に使用されます。
HELO
QUIT
HELO 命令で、命令を送るホストが自身を同定します；この命令は
「Hello、私はですと言ってると解釈されるかもしれませ
ん。
-------------------------------------------------------------
接続開始の例
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
-------------------------------------------------------------
Postel [Page 13]
August 1982 RFC 821
Simple Mail Transfer Protocol
3.6. 中継（RELAYING）
forward-pathは "@ONE,@TWO:JOE@THREE" 書式の資源ルートで、そこには
一・二そして三のホストがあります。この書式は、アドレスとルートの
区別を強調するのに使われます。郵便箱は絶対アドレスで、ルートはど
のようにしてそこへ行くのかの情報です。二つの概念は、混乱させられ
るべきではありません。
概念的に、forward-pathは、メッセージは一つのサーバーSMTPから別の
ものに中継されますので、reverse-pathに移動します。reverse-path は
反転資源ルート（例えば、今のメッセージ場所からメッセージの創作者
への資源ルート）です。サーバーSMTPがforward-pathからその識別子を
削除しそれにreverse-pathを挿入する際、そのサーバーSMTPが異なる環
境で異なる名前によって知られている場合メールが送られて来た環境で
はなく送信する環境で知られている名前を使用しなければなりません。
メッセージがSMTPに届く時forward-path の最初の要素がそのSMTPの識別
子でないなら、その要素はforward-pathから削除され、メッセージを送
る次のSMTPを決めるために使用されます。どんな場合でも、SMTPは
reverse-pathにそれ自身の識別子を付け加えます。
資源ルートを使って受信者-SMTPは、別のサーバーSMTPに中継されるメー
ルを受け取ります。受信者-SMTPは、ロカール利用者向けのメールを受け
付けもしくは拒絶するのと同じやり方で、そのメール中継する仕事を受
け付けたりもしくは拒絶したりするかもしれません。それから、受信者
SMTPは送信者-SMTPになり、次のforward-patのSMTPに転送チャンネルを
確立し、そこにメールを送信します。
reverse-pathの最初のホストはSMTP命令を送るSMTPであるべきで、そし
てforward-pathの最初のホストはSMTP命令を受信したホストであるべき
です。
forward-path と reverse-pathは SMTP 命令と応答に現われますが、
メッセージには必要がありません。つまり、これらの経路や特に構文に
とって、メッセージヘッダーの"To:"・"From:"・"CC:"などのフィールド
に現われる必要はありません。
サーバーSMTPがメール中継の仕事を受け入れ、後でforward-pathが正し
くないこともしくはメールは何らかの理由で配達されることができない
ことが分かったら、
[Page 14] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
くないこともしくはメールは何らかの理由で配達されることができない
ことが分かったら、その時は「未配達メール」通告メッセージを作り、
それを配達できないメールの創作者に送信しなければなりません
（reverse-pathで示唆された通りに）。
この通告メッセージは、このホストのサーバーSMTPからでなければなり
ません。勿論、サーバーSMTPは通告メッセージと伴に問題についての通
告メッセージを送信すべきではありません。エラー報告でループを防ぐ
一つの方法は、通告メッセージのMAIL 命令でヌール（空白）reverse-
pathを特定することです。ヌール（空白）reverse-pathのMAIL 命令は、
以下のような見かけになります：
MAIL FROM:<>
配達できないメール通告メッセージは、例 7で示しています。この通告
は、HOSTW でJOE氏によって創作されHOSTX経由で、HOSTZにそれを中継
する構造を持ったHOSTYに、送るメッセージへの反応です。この例に見ら
れるものは、HOSTY と HOSTX の間の処理で、それは通告メッセージの返
還での第一歩です。
Postel [Page 15]
August 1982 RFC 821
Simple Mail Transfer Protocol
-------------------------------------------------------------
未配達メール通告メッセージ例
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: メールシステム問題
S:
S: JOEさん、残念ながら、SAM@HOSTZ.ARPA宛のあなたのメッセージ
S: は、迷っています。
S: HOSTZ.ARPA はこう言っています：
S: "550 そのような利用者は見当たりません。
S: .
R: 250 ok
例 7
-------------------------------------------------------------
[Page 16] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
3.7. ドメイン（DOMAINS）（範囲・領域）
ドメインは最近 ARPA インターネットメールシステムで導入された概念
です。ドメインの使用は、アドレス空間を単純文字列ホスト名の平坦な
グローバルな空間から、グローバルなアドレスの階層木樹構造に変えま
す。ホスト名はドメインとホスト設計者で置き代えら、これは最も特異
的なものから最も一般的なものに順序付けられたドメイン要素文字列を
理解する、ピリオドで区別された一連のドメイン要素文字列です。
例えば、"USC-ISIF.ARPA"・"Fred.Cambridge.UK"そして"PC7.LCS.MIT.ARPA"
は、ホスト-そして-ドメイン（host-and-domain）識別子です。
ドメイン名がSMTPで使われる場合は必ず、公式名のみが使用され、ニッ
クネームもしくは別名は許されていません。
Postel [Page 17]
August 1982 RFC 821
Simple Mail Transfer Protocol
3.8. 役割変更（CHANGING ROLES）
TURN 命令は、転送チャンネルを通じて交流している二つのプログラムの
役割を逆転するのに使われます。
プログラム-A が現在sender-SMTPで、TURN 命令を送信し、ok 応答
（250）を受け取ったら、プログラム-Aは受信SMTPになります。
プログラム-Bが現在受信者-SMTPで、TURN 命令を受け、ok応答（250）を
送信したら、プログラム-Bは送信r-SMTPになります。
役割を変更することを拒否するには、受信者は502応答を送ります。
この命令は選択性であることに注意してください。転送チャンネルが
TCP の状況では、普通は使用されません。しかし、転送チャンネルを確
立することのコストが高い場合、この命令は大変有益です。例えば、こ
の命令は、転送チャンネルとして公衆切り替え電話システム、特にホス
トがメール交換用に別のホストを登録している場合、を使ったメール交
換をサポート際に、有用かもしれません。
[#^]
[Page 18] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
4. SMTP 仕様
4.1. SMTP 命令
4.1.1. 命令の意味（COMMAND SEMANTICS）
SMTP 命令はメール転送もしくは利用者が請求するメールシステム機
能を定義します。SMTD 命令はで終る文字列です。この命令
コード自身は、パラメーターとでないなら、で終るアル
ファベット文字です。郵便箱の構文は、サイト慣例を受け取るように
順応しなければなりません。SMTP命令は以下で議論されます。SMTP応
答はセクション 4.2 で議論されます。
メール処理は、引数として異なる命令と交流する、幾つかのデーター
対象を含んでいます。reverse-pathは MAIL命令の引数で、forward-
pathは RCPTの引数で、そしてmail dataは DATA命令の引数です。こ
れらの引数もしくはデーター対象は、転送され、処理終了を示唆する
mail data の終によって伝えられる確認を待ち続けなければなりませ
ん。このメール方針は、データー対象タイプを保存するために別個の
バッファーを提供することで、つまり、reverse-pathバッファー・
aforward-pathバッファーそしてmail dataバッファーがあります。特
別な命令で、特別なバッファーに情報が付け加えられるかもしくは一
つ以上のバッファーがクリアーされます。
HELLO (HELO)
この命令は、送信者-SMTPを受信者-SMTPに確認するのに使われま
す。 引数フィールドは送信者-SMTPのホスト名を内容としていま
す。
受信者-SMTPは、自身を送信者-SMTPに挨拶応答で確認します。
この命令とそれへのOK応答は、送信者-SMTPと受信者-SMTP両者が
初期状態で、つまり進行中の処理はなんらなく、全ての状態表ち
バッファーはクリアーされています。
Postel [Page 19]
August 1982 RFC 821
Simple Mail Transfer Protocol
MAIL (MAIL)
この命令は、メールデーターが一つ以上の郵便箱に配達される、
メール処理を初期化するのに使用されます。その引数フィールド
は反転-経路（reverse-path）を内容としています。
反転-経路は、ホストと送信者郵便箱の選択性のリストから構成さ
れています。ホストのリストがある場合、それは「反転」資源
ルートで、そのメールがリスト（リストの最初のホストは一番最
近の中継です）の各ホストを通って中継されたことを示唆してい
ます。このリストは、送信者に未配達通告を返すために資源ルー
トとして使用されます。各中継ホストはリストのはじめに自身を
付け加え、それはメールが来たIPCEというよりも（それが異なっ
ているなら）メールを中継しているIPCEで知られているような名
前を使わなければなりません。エラー報告メッセージのタイプに
ようっては（例えば、未配達メール通告）、反転-経路
（reverse-path）はヌール（例 7参照）であるかもしれません。
この命令は、反転-経路バッファーをクリアーにします；そしてこ
の命令からの反転-経路情報を反転-経路バッファーに挿入します。
受信者（RECIPIENT (RCPT)）
この命令はメールデーターの個人の受取人を識別するのに使われ
ます；多数の受取人はこの命令の多元使用によって特定されま
す。
forward-pathは、ホストと要求された行き先郵便箱の選択的なリ
ストからなっています。ホストのリストが在る場合、それは資源
ルートで、メールがリストの次のホストに中継されなければなら
ないことを示唆しています。受信者-SMTPが中継機能を装備してい
ないなら、不明のローカル利用者用と同じ応答を使うかもしれま
せん（550）。
メールが中継される時、中継ホストは最初のforward-pathから自
身を除き、reverse-pathの最初に自身を置かなければなりません。
メールが最後の行き先（forward-pathは行き先郵便箱だけを内容
としています）に到達したら、受信者-SMTPは、ホストメール慣例
に従って、それを行き先の郵便箱に挿入します。
[Page 20] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
例えば、メールは、中継ホストAで引数とともに、受信しました。
FROM:
TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA>
は、引数と一緒にホストBで中継されます。
FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA>
TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>.
この命令で、そのorward-path引数がforward-pathバッファーに付
け加えられます。
データー DATA (DATA)
受信者はこの命令に続く行を送信者かたのメールデーターとして
処理します。この命令によって、この命令からのメールデーター
はメールでーたーバッファーに付け加えられます。メールデー
ターは128のASCIIコードを内容としているかもしれません。
メールデーターは、ピリオドだけ、つまり文字列""、を内容
とする行で終ります（セクション 4.5.2 透明化参照）。これは
メールデーター指標の終です。
メールデーター指標の終は、受信者は保存された処理情報を今す
ぐ処理しなければなららいことを要求しています。この処理は
reverse-pathバッファー・forward-path バッファー・mail data
バッファーの情報も使いはたし、そしてこの命令の完了でこれら
のバッファーはクリアーにされます。この処理が成功すれば、受
信者はOK応答を送らなければなりません。この処理に完全に失敗
すれば、失敗応答をおくらなければなりません。
受信者-SMTPがメッセージを中継もしくは最終配達として受け入れ
る場合、それはメールデーターのはじめにタイムスタンプ（時間
刻印）を挿入します。このタイムスタンプ行は、メッセージを
送ったホストの識別とメッセージ（そしてこのタイムスタンプを
挿入している）を受け取ったホストの識別そしてメッセージが受
け取られたその日付と時刻、を示唆します。中継されたメッセー
ジは多元のタイムスタンプ行を持っています。
受信-SMTPは、メッセージの「最終配達」作る際、それはメール
Postel [Page 21]
August 1982 RFC 821
Simple Mail Transfer Protocol
データーのはじめに、返却経路行を挿入します。返却経路行は
MAIL 命令からの情報を保持します。ここで最終配
達は、メッセージがSMTPの世界を離れることを意味します。普
通、これは、それは行き先利用者に配達されたことを意味します
が、ある場合それは、さらに別のメールシステムによって処理さ
れそして転送されるかもしれません。
返却経路で郵便箱は実際の送信者の郵便箱と異なることが可能
で、例えば、エラー反応はメッセージ送信者よりも特別なエ
ラー取り扱い郵便箱に配達されなければなりません。
この一連の二つのパラグラフは、最終メールデーターは返却経路
行ではじまり、次いで一つ以上のタイムスタンプ行がくることを
示しています。これらの行は、メールデーターヘッダーとボディ
[2] が続きます。例 8 参照。
メールデーター指標の終に続く処理が部分的に成功する場合に要
求される、反応とさらなる行動についての特別の記述が必要にな
ります。幾つかの受取人とメールデーターを受け入れた後受者-
SMTPがそのメールデーターは成功裡にある受取人に配達されたが
別の人にすることができない（例えば、郵便箱空間割り当て問
題）ことに気付く場合、これが生じることがあります。そのよう
な状況下で、DATA 命令への反応は、OK応答でなければなりませ
ん。しかし受信者-SMTPは、メッセージの創作者（オリジネイ
ター）に「未配達メール」通告メッセージを送信しなければなり
ません。メッセージが得られなかった受信者の全てをリストした
単一の通告もしくは別個の通告メッセージのどちらかが、各失敗
させられて受取人にむけて送信されなければなりません（例 7参
照）。全ての未配達メール通告メッセージは、MAIL（例え、彼等
は、SEND・SOMLもしくはSAML 命令の処理からでも、生じます）命
令を使って、送られます。
[Page 22] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
-------------------------------------------------------------
返却経路と受信タイムスタンプ（時間刻印）の例
Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA>
Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST
Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST
Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST
Date: 27 Oct 81 15:01:01 PST
From: JOE@ABC.ARPA
Subject: Improved Mailing System Installed
To: SAM@JKL.ARPA
This is to inform you that ...
例 8
-------------------------------------------------------------
送信 SEND (SEND)
この命令はメールデーターが一つ以上の端末に配達されるメール
処理を初期化するのに使われます。引数フィールドはreverse-
pathを内容としています。この命令は、メッセージが端末に配達
されたら、成功です。
reverse-pathは、ホストと送信者郵便箱の選択的（任意）なリス
トからなっています。ホストのリストがある場合、それは反転
"reverse"資源ルートで、そのメールリスト（リストの最初のホス
トは最も最近の中継です）上の各ホストを経て中継されることを
示唆しています。このリストは、未配達通告を送信者に返すため
の資源ルートとして使用されます。各中継ホストはリストのはじ
めに自身を付け加えますので、メールが来たIPCEでなくメールを
中継しているIPCEで知られている名前を使用しなければなりませ
ん（それらが異なるなら）。
この命令はreverse-pathバッファー・forward-pathバッファーそ
してmail dataバッファーをクリアーにします；そしてこの命令か
らのreverse-path情報をreverse-pathバッファーに挿入します。
送信もしくは郵送 SEND OR MAIL (SOML)
この命令は、メールデーターを一つ以上の端末もしくか郵便箱に
配達するメール処理を初期化するのに、使用されます。
Postel [Page 23]
August 1982 RFC 821
Simple Mail Transfer Protocol
各受取人にとってメールデーターは、受取人がホストで作動中
（そして端末メッセージを受け付けている）なら、受取人の端末
に配達され、そうでないなら郵便箱に配達されます。引数フィー
ルドはreverse-pathを内容としています。この命令は、メッセー
ジが端末もしくは郵便箱に配達されたら、成功となります。
reverse-pathは、ホストと送信者郵便箱の選択的なリストからな
ります。ホストのリストがある場合、それは反転"reverse"資源
ルートで、そのメールがリスト上の各ホストを経て中継されたこ
とを示唆しています（リストの最初のホスルは最近の中継で
す）。このリストは、送信者に未配達通告メッセージをを返すた
めの資源として使用されます。各中継ホストは、そのリストのは
じめに自身を付け加えますので、メールが来たIPCEでなくメール
を中継しているIPCEで知られている名前を使用しなければなりま
せん（それらが異なるなら）。
この命令はreverse-pathバッファー・forward-pathバッファーそ
してmail dataバッファーをクリアーにします；そしてこの命令か
らのreverse-path情報をreverse-pathバッファーに挿入します。
送信と郵便 SEND AND MAIL (SAML)
この命令は、メールデーターは一つ以上の端末もしくは郵便箱に
配達されるメール処理を初期化するのに使われます。各受取人に
とって、メールデーターは、受取人がホスト上で作動中（端末
メッセージを受け入れる）なら、受取人の端末に配達し、そして
受取人全てに受取人の郵便箱に配達します。引数フィールドは
reverse-pathを内容としています。この命令は、メッセージが郵
便箱に配達されたら、成功です。
反転経路reverse-pathは、ホストと送信者郵便箱の選択的なリス
トです。リストが在る場合、それは反転"reverse"資源ルートで、
メールがリストの各ホスト経て配達されたことを示唆しています
（リストの最初のホストは最近の中継です）。リストは、送信者
に未配達通告を返す資源ルートとして使用されます。各中継ホス
トは、そのリストのはじめに自身を付け加えますので、メールが
来たIPCEでなくメールを中継しているIPCEで知られている名前を
使用しなければなりません（それらが異なるなら）。
この命令はreverse-pathバッファー・forward-pathバッファーそ
[Page 24] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
してmail dataバッファーをクリアーにします；そしてこの命令か
らのreverse-path情報をreverse-pathバッファーに挿入します。
再設定 RESET (RSET)
この命令は、当該のメール処理が中止されなければならないこ
と、を特定します。保存送信・受取人・メールデーターは如何な
るものでも捨てられ、全てのバッファーと状態表はクリアーにさ
れます。受信者は、OK応答を送らなければなりません。
確認 VERIFY (VRFY)
この命令は、引数が利用者を識別することを確認するために、受
信者に尋ねます。それが利用者名であれば、利用者と全部特定さ
れた郵便箱のフルネーム（分かれば）が返されます。
この命令は、reverse-pathバッファー・forward-pathバッファー
そしてmail dataバッファーには何ら影響を与えません。
展開 EXPAND (EXPN)
この命令は、引数がメーリングリストを識別することを確認する
ために受信者に尋ね、それならそのリストの会員を返します。利
用者と全て特定された郵便箱のフルネーム（それがわかれば）が
多行応答で返されます。
この命令は、reverse-pathバッファー・forward-pathバッファー
そしてmail dataバッファーには何ら影響を与えません。
助言 HELP (HELP)
この命令で、受信者がHELP命令の送信者に助言情報を送ります。
この命令は、引数（例えば、命令の名前）を取り、反応としてよ
り特別な情報を返します。
この命令は、reverse-pathバッファー・forward-pathバッファー
そしてmail dataバッファーには何ら影響を与えません。
Postel [Page 25]
August 1982 RFC 821
Simple Mail Transfer Protocol
中止便 NOOP (NOOP)
この命令は、パラメーターもしくは前に入力された命令に影響を
あたえません。これは、受信者がOK応答を送ること以外の行動を
なんら特定しません。
この命令は、reverse-pathバッファー・forward-pathバッファー
そしてmail dataバッファーには何ら影響を与えません。
終了 QUIT (QUIT)
この命令は、受信者がOK応答を送り、転送チャンネルを閉じるこ
とを特定します。
受信者は、 QUIT 命令（それがエラーであっても）を受け応答す
る迄、転送チャンネルを閉じるべきではありません。送信者は、
それがQUIT 命令を送信し応答（それが以前の命令へのエラー反応
であっても）を受け取る迄、転送チャンネルを閉じるべきではあ
りません。接続が早まって閉じられたら、受信者はRSET命令を受
け取った（転送をまつことを中止するが、以前に完成された転送
を元にもどさない）ように作動し、送信者は進行中のその命令も
しくは処理は一時的なエラー（4xx）を受け取ったように作動すべ
きです。
転換 TURN (TURN)
この命令は、 (1)受信者がOK応答をおくり次いで送信-SMTPの役割
を担うかもしくは(2)拒否応答を送りそして受信者-SMTPの役割を
保持する、を特定します。
プログラム-Aが現在送信者-SMTPでそれがTURN命令を送りOK応答
（250）を受け取ったら、プログラム-Aは受信者-SMTPになりま
す。次いで、プログラム-Aは、転送チャンネルが丁度開始しする
ように、初期状態になり、220サービス用意挨拶を送ります。
プログラム-Bが現在受信-SMTPでTURN命令を受けOK応答（250）を
送信すれば、プログラム-Bは送信者-SMTPになります。次いでプロ
グラム-Bは、転送チャンネルが丁度開始するように、初期状態に
なり、それは220サービス用意挨拶を受けることを期待していま
す。
役割変更を拒否するには、受信者-SMTPは502応答を送ります。
[Page 26] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
これらの命令は使用される順序に制限があります。
セッション（断片）での最初の命令は、HELO 命令でなければなり
ません。HELO 命令はセッションの後のほうでも同じように使用さ
れるかもしれません。HELO 命令引数が受け入れられない場合、
501失敗応答が返されなければならなく、受信者-SMTPは同じ状態
で留まらなければなりません。
NOOP・HELP・EXPNそしてVRFY 命令は、セッション中何時でも使用
できます。
MAIL・SEND・SOMLもしくはSAML 命令はメール転送を開始します。
一旦開始されたら、メール処理は、処理開始命令の一つ・一つ以
上のRCPT 命令とDATR 命令から、その順番で構成されます。メー
ル処理はRSET命令で中止されるかもしれません。セッションで、
これらはゼロもしくはより多い処理です。
処理開始命令引数が受け付けられない場合、501失敗応答が返さ
れ、受信者-SMTPは同じ状態のまま留まらなければなりません。処
理での命令が順序外の場合、503失敗応答が返され、受信者-SMTP
は同じ状態に留まらなければなりません。
セッションでの最後の命令はQUIT 命令でなければなりません。
QUIT 命令はセッセションでは何時でも使用されることはできませ
ん。
4.1.2. 命令構文
命令は、命令コードとそれに続く引数フィールドから構成されます。
命令コードは四文字のアルファベットです。大文字小文字は同じもの
として処理されます。かくて、以下のものがメール命令を表現してい
ます：
MAIL Mail mail MaIl mAIl
これはパラメーター値を表現する、forward-pathの"TO" もしくは
"to"のような、シンボルにも摘要されます。命令コードと引数は、一
つ以上のスペースで区切られます。しかし、reverse-path と
forward-path 引数内では、大文字小文字は重要です。特に、ホスト
によっては、利用者"smith"と利用者"Smith"を区別します。
Postel [Page 27]
August 1982 RFC 821
Simple Mail Transfer Protocol
引数フィールドは、文字列で終る色々な長さの文字列から構成
されています。受取人は、この文字列を受け取る迄、なんら行動を取
るべきではありません。
角（大）括弧は、選択的な（任意の）引数を示します。選択されない
場合、適当なデフォルトが当然のこととして含まれます。
[Page 28] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
以下は、SMTP命令です：
HELO
MAIL FROM:
RCPT TO:
DATA
RSET
SEND FROM:
SOML FROM:
SAML FROM:
VRFY
EXPN
HELP [ ]
NOOP
QUIT
TURN
Postel [Page 29]
August 1982 RFC 821
Simple Mail Transfer Protocol
上の引数フィールドの構文（ここで応用できるBNF命名法を使って）
以下に与えられます。命名"..."は、そのフィールドが一回以上繰り
返されるかもしれないことを示唆しています。
::=
::=
::= "<" [ ":" ] ">"
::= | ","
::= "@"
::= | "."
::= | "#" | "[" "]"
::= "@"
::= |
::=
::= |
::= |
::= | | "-"
::= | "."
::= |
::= """ """
::= "\" | "\" | |
::= | "\"
::= "." "." "."
::= |
::=
[Page 30] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
::= the carriage return character (ASCII code 13)
::= the line feed character (ASCII code 10)
::= the space character (ASCII code 32)
::= one, two, or three digits representing a decimal
integer value in the range 0 through 255
::= any one of the 52 alphabetic characters A through Z
in upper case and a through z in lower case
::= any one of the 128 ASCII characters, but not any
or
::= any one of the ten digits 0 through 9
::= any one of the 128 ASCII characters except ,
, quote ("), or backslash (\)
::= any one of the 128 ASCII characters (no exceptions)
::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
| "," | ";" | ":" | "@" """ | the control
characters (ASCII codes 0 through 31 inclusive and
127)
バックスラッシュ、"\"、は引用文字で、それは次の文字は文字通り
に（その普通の解釈ではなく）使用されていることに注意してくださ
い。例えば "Joe\,Smith"は、そのフィールドの四番目の文字である
コンマを伴った、単一の九つの文字の利用者フィールドを示唆するの
に、使用されます。
ホストは一般的には各ホストでアドレスに翻訳された名前で知られて
います。ドメインの名前要素は公式名です -- ニックネームもしくは
別名は許されないことに注意してください。
時には、ホストが翻訳機能に知られないで、交流が断絶させられるこ
とがあります。この障壁を回避するために、二つの数値書式もホスト
「名」に許されます。書式の一つは、ポンド記号"#"が前に付けられ
た十進整数値があり、これはその数値がそのホストの名前であること
を指しています。別の書式は、ドットで区切られ括弧で囲まれた四つ
の小文字十進整数値、例えば"[123.255.37.2]"、で、これは8ビット
フィールドの32ビットARPAインターネットアドレスを指しています。
Postel [Page 31]
August 1982 RFC 821
Simple Mail Transfer Protocol
時間刻印行と応答行は正式に以下のように定義されます：
::= "Return-Path:"
::= "Received:"
::= ";"
::= "FROM"
::= "BY"
::= [] [] [] []
::= "VIA"
::= "WITH"
::= "ID"
::= "FOR"
::= The standard names for links are registered with
the Network Information Center.
::= The standard names for protocols are
registered with the Network Information Center.
::=