ネットワーク・ワーキンググループJ.Klensin(Network Working Group J. Klensin)、コメントのエディター・リクエスト(Editor Request):2821のAT&T研究所Obsoletes(AT&T Laboratories Obsoletes):821,974のおよび1869 4月の2001年のアッデート:1123のカテゴリー:標準トラック(Standards Track) 単純メイル転送プロトコル このメモのステータス このドキュメントはインターネットを指定します、標準は、インターネットコミュニティーのためのプロトコルを追跡します、また改良のための議論および提案を要求します。 このプロトコルの標準化状態およびステータスに関しては「インターネットの公式プロトコル規格(Official Protocol Standards)」(STD 1)の現在の版を参照してください。 このメモの分配は無制限です。 著作権のある通知 著作権(C)、インターネット社会(2001)。 著作権保有。 アブストラクト このドキュメントはインターネット電子メール輸送のための基礎的なプロトコルの自給自足の明細です。 それは統合し、更新し明確にするが、下記の新しいかあるいは変更既存の機能性を加えません: - RFC 821[30]のオリジナルのSMTP(単純メイル転送プロトコル)明細、 - メイル用のドメインネームシステム必要条件および含意はRFC 1035[22]およびRFCから974の[27]を輸送します、 - RFC 1123[2]の解明と適用可能性のステートメント、そして―SMTPエクステンション(SMTP Extension)メカニズム[19]から取り出された資料。 それ、obsoletes RFC 821、RFC 974、またRFC 1123(メイルを交換する、RFC 1123の用品を輸送する)を更新します。 しかしながら、RFC 821は、1990年代および(付録中で)いくつかの追加の輸送モデル中頃までにインターネット中の重要な使用中でなかった、いくつかの特徴を指定します。 それらのセクションは、明瞭と簡潔さのためにここに省略されます; それらを必要とする読者はRFC 821を参照するべきです。 Klensin基準は[1ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、2001 さらに、それは、増幅を要求したRFC 1123からのある付加的な資料を含んでいます。 この材料はほとんど様々なリストおよびニュースグループ上で燃え立って、追跡することおよびSMTP拡張が展開したように、現われた異常な読書あるいは解釈の問題により、多数の方法で識別されました。 この明細が統合を越えて移動し、現実に初期のドキュメントと異なるところで、それはそれらに技術的に原文どおりに取って代わります。 SMTPはメイル輸送および配達プロトコルとして設計されましたが、POPに推薦されるように、この明細はさらに「メイル・サブミッション」プロトコルとしてその使用にとって重要な情報を含んでいます[3、26]またIMAP[6]. 追加のサブミッション問題はRFC 2476[15]で議論されます。 セクション2.3は、このドキュメントに特有の用語の定義を提供します。 以外は、歴史上の用語が明瞭に必要な場合、このドキュメントは送るSMTPプロセスおよび受信SMTPプロセスを識別するために電流「クライアント」および「サーバー」用語をそれぞれ使用します。 相手ドキュメント[32]はメッセージヘッダー、メッセージ身体、およびそれらおよびそれらの関係のためのフォーマットおよび構造について議論します。 目次1。 イントロダクション.......................................。 ........... 4 2. SMTPモデル(SMTP Model).......................................。 ......... 5 2.1の基礎的な構造(Basic Structure).......................................。 ....... 5 2.2、エクステンション・モデル(Extension Model).......................................... 7 2.2.1のバックグラウンド.......................................。 .......... 7 エクステンション..................の2.2.2の定義および登録。 8 2.3の用語.......................................。 ........... 9 2.3.1はオブジェクト.......................................を郵送します。 ........ 10 2.3.2のセンダおよびレシーバー......................................。 10 2.3.3のメイル・エージェント(Mail Agents)およびメッセージは.............................をストアします。 10 2.3.4人のホスト.......................................。 ................ 11 2.3.5のドメイン.......................................。 .............. 11 2.3.6のバッファーと州のテーブル.....................................。 11 .......................................行(2.3.7). ............... 12 2.3.8人の発明者、配達、リレーおよびゲートウェイ・システム(Gateway Systems)...........。 12 2.3.9のメッセージコンテンツ(Message Content)およびメイル・データ(Mail Data)..............................。 13 2.3.10の郵便箱とアドレスの........................................ 13 2.3.11は.......................................を返答します。 .............. 13 2.4の一般的なシンタックス法則(General Syntax Principles)およびトランザクション・モデル(Transaction Model)..............。 13 3. SMTP手続き(SMTP Procedures):概観..............................。 15 3.1のセッション・イニシエーション(Session Initiation)....................................... 15 3.2のクライアント・イニシエーション(Client Initiation).......................................。 ..... 16 3.3のメイル・トランザクション(Mail Transactions).......................................。 ..... 16 アドレス修正(Address Correction)用3.4のフォワーディングあるいは................をアップデートすること。 19 Klensin基準(Klensin Standards)は、デバッグのための2001年の3.5のコマンドが.............................をアドレスする[2ページ]RFC 2821単純メイル転送プロトコル4月を追跡します。 20 3.5.1の概観.......................................。 ............ 20 3.5.2のVRFYノーマルレスポンス(VRFY Normal Response).......................................。 22 VRFYまたはEXPNの成功レスポンス(Success Response)...................の3.5.3の意味。 22 EXPN.........................の3.5.4のセマンティックスおよびアプリケーション。 23 3.6のドメイン.......................................。 ............... 23 リレーする3.7........................................ .............. 24 .......................................をGatewayingする3.8のメイル。 ....... 25 ................................をGatewayingすることの中の3.8.1のヘッダー・フィールド(Header Fields)。 26 ...............................をGatewayingすることの中の3.8.2行の受信ライン(Received Lines)。 26 ....................................をGatewayingすることの中の3.8.3のアドレス。 26 ..........................をGatewayingすることの中の他の3.8.4のヘッダー・フィールド(Header Fields)。 27 ....................................をGatewayingすることの中の3.8.5枚の封筒。 27 3.9の終了セッション(Terminating Sessions)および接続.........................。 27 3.10のメーリング・リストおよび別名...................................。 28 3.10.1の別名.......................................。 .............. 28 3.10.2は.......................................をリストします。 ............... 28 4. SMTP仕様書(SMTP Specifications).......................................。 29 4.1のSMTPコマンド(SMTP Commands)........................................ ......... 29 4.1.1のコマンドセマンティックス(Command Semantics)およびシンタックス...............................。 29 4.1.1.1の拡張HELLO(Extended HELLO)(EHLO)あるいはHELLO(HELO)...................。 29 4.1.1.2のMAIL(MAIL)の........................................ ....... 31 4.1.1.3の受取人(RCPT)......................................... 31 4.1.1.4のデータ(データ)........................................ ....... 33 4.1.1.5のリセット(RSET)........................................ ...... 34 4.1.1.6は.......................................を確認します(VRFY)。 ..... 35 4.1.1.7は.......................................を拡張します(EXPN)。 ..... 35 4.1.1.8のヘルプ(ヘルプ)........................................ ....... 35 4.1.1.9のNOOP(NOOP)........................................ ....... 35 4.1.1.10は.......................................を中止します(中止する)。 ...... 36 4.1.2のコマンド引き数シンタックス(Command Argument Syntax)....................................。 36 4.1.3のアドレス・リテラル(Address Literals)....................................... 38 コマンド.......................................の4.1.4のオーダー 39 4.1.5の私的使用コマンド........................................ 40 4.2のSMTPは.......................................を返答します。 ......... 40 4.2.1の返答コード厳しさ(Reply Code Severities)および理論...........................。 42 4.2.2は、機能によるコードが.............................をグループ化すると返答します。 44 4.2.3の返答は数値のオーダー(Numeric Order)..............................にコード化します。 45 4.2.4の返答コード(Reply Code)502........................................ ...... 46 4.2.5はDATAおよび後のの後にコードを返答します。 46 コマンドおよび返答...........................の4.3の配列。 47 4.3.1の順番に並べる概観(Sequencing Overview).......................................。 47 4.3.2のコマンド返答シーケンス(Command-Reply Sequences)....................................。 48 4.4は情報.......................................をトレースします。 ..... 49 4.5の追加のインプリメンテーション(Additional Implementation)は.............................を出します。 53 4.5.1の最小のインプリメンテーション(Minimum Implementation).....................................。 53 4.5.2台のスライド.......................................。 ........ 53 4.5.3のサイズおよびタイムアウト......................................... 54 Klensin基準(Klensin Standards)は、2001年4.5.3.1が範囲および最小限.................................を分類する[3ページ]RFC 2821単純メイル転送プロトコル4月を追跡します。 54 4.5.3.2のタイムアウト.......................................。 .......... 56 4.5.4はストラテジー.......................................を再試行します.... 57 4.5.4.1の送るストラテジー(Sending Strategy)......................................... 58 4.5.4.2の受信ストラテジー(Receiving Strategy).......................................。 59 無効の逆のパス..........................を備えた4.5.5のメッセージ。 59 5. ..........................を扱うアドレス・リゾリューションおよびメイル。 60 6. 問題検知(Problem Detection)および................................を扱うこと。 62 電子メール.......................による、6.1の確実な配達(Reliable Delivery)および返答。 62 6.2のループ検知(Loop Detection).......................................。 ........ 63 6.3、不規則..............................を補うこと 63 7. セキュリティ考察(Security Considerations).......................................。 64 7.1のメイル・セキュリティ(Mail Security)および...................................をからかうこと。 64 7.2の「ブラインド」は.......................................をコピーします。 ........ 65 7.3のVRFY、EXPNおよびセキュリティ.....................................。 65 アナウンス......................中の7.4の情報デスクロージャー(Information Disclosure)。 66 トレース・フィールド(Trace Fields).......................での7.5の情報デスクロージャー(Information Disclosure)。 66 .................を進めるメッセージ中の7.6の情報デスクロージャー(Information Disclosure)。 67 SMTPサーバー...........................のオペレーションの7.7の範囲。 67 8. IANA考察(IANA Considerations)....................................... 67 9. 参照.......................................。 ............. 68 10. エディターアドレス(Editor's Address).......................................。 ...... 70 11. 認識.......................................。 ....... 70 付録.......................................。 ................ 71 A.TCP輸送サービス(A. TCP Transport Service)......................................... 71 B。 RFC 822ヘッダー.................からのSMTPコマンド(SMTP Commands)の生成。 71 C.ソース(C. Source)は.......................................を送ります。 .......... 72 D.シナリオ(D. Scenarios).......................................。 .............. 73 E。 他のゲートウェイは.......................................を出します... 76 F.は、RFC 821................................のフィーチュアを大いに非難しました。 76 十分な著作権のあるステートメント(Full Copyright Statement)......................................... 79 1. イントロダクション、単純メイル転送プロトコル(SMTP)の目的はメイルを頼もしく効率的に転送することです。 SMTPは特別の送信サブシステムに依存しなく、確実な順序づけられたデータ流れチャンネルだけを要求します。 このドキュメントが特にTCPに対する輸送について議論している一方、他の輸送は可能です。 RFC 821への付録は、それらのうちのいくつかについて記述します。 SMTPの重要な特徴は通常「中継しているSMTPメイル」と呼ばれて、ネットワークを介してメイルを輸送するその能力です(セクション3.8を参照)。 ネットワークは、公のインターネット上の相互にTCPアクセス可能なホスト、ファイアウォールに分離されたTCP/IPイントラネット上の相互にTCPアクセス可能なホストあるいは非TCP輸送レベルプロトコルを利用する、他のあるLANあるいはWAN環境の中のホストから成ります。 Klensin基準(Klensin Standards)の使用[4ページ]RFC 2821単純メイル転送プロトコル4月を追跡する、2001年のSMTP、プロセスは両方のネットワークにアクセス可能なリレーまたはゲートウエイのプロセスによって同じネットワーク上の別のプロセスあるいは他のあるネットワークにメイルを転送することができます。 この方法で、メイル・メッセージは送信器から最終の受取人に、そのパス上の多くの中間のリレーあるいはゲートウェイ・ホストによって相続されるかもしれません。 ドメインネームシステムのメイルeXchangerメカニズム[22、27](また(セクション、5、このドキュメントの))輸送されているメッセージのための適切な次のホップ目的地を識別するために使用されます。 2. SMTPモデル(SMTP Model)2.1、基礎的な構造(Basic Structure)SMTP設計は次のように描写することができます。 +----------++----------++------+|||||ユーザ|――||SMTP||+------+|クライアント(|コマンド/返答|サーバー)|+------+|SMTP|<-------------->|SMTP|+------+| SMTPクライアントが送信するメッセージを持っている場合、それ、establis hes、2-SMTPサーバーへの方法送信チャンネル。 SMTPクライアントの責任は、1つ以上のSMTPサーバーにメイル・メッセージを転送するか、その失敗がそうすることを報告することです。 メイル・メッセージがよる手段はSMTPクライアントに示しました。また、そのクライアントがメイル・メッセージが転送されることになっているドメインネーム(s)をどう決定するかはローカルの問題で、このドキュメントによってアドレスされません。 いくつかの場合に、ドメインネーム(s)移られかつ、決定されて、SMTPクライアントは、メイル・メッセージの最終目的地(s)を識別するでしょう。 他の場合に、POPのインプリメンテーションに関連した、SMTPクライアントで共通[3、26]あるいはIMAP[6]プロトコル、あるいは、SMTPクライアントが分離された輸送業務環境の内部であった場合、決定されたドメインネームはメイル・メッセージがすべて中継されることになっている中間の目的地を識別するでしょう。 個人メッセージに関連した目標ドメインネームにかかわらず、交通をすべて転送するか、最初に完成することができないメッセージ送信の再試行を待つ列を維持しないSMTPクライアントは、そうでなければこの明細に一致するかもしれないが、完全に有能であると考えられません。 これらのそれほど有能でないKlensin基準(Klensin Standards)によって使用されるリレーを含む完全に有能なSMTPインプリメンテーションは、[5ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、2001のいくつかのもの、また、それらの目的地がこの明細で議論された、キューにするアドレス機能、再試行するアドレス機能および交互のアドレス機能をすべて支援すると予想されます。 手段、どれによって、SMTPクライアント、一度それが目標ドメインネームを決定しており、1部のメッセージが転送されることになっているSMTPサーバーの同一性を決定し、次にそれを実行すれば、移る、このドキュメントによってカバーされます。 SMTPサーバーへのメール転送を達成するために、SMTPクライアントは、そのSMTPサーバーへの2ウェイの送信チャンネルを設立します。 SMTPクライアントは、中間のメイルeXchangerホストあるいは最終の目標ホストのいずれかへの目的地ドメインネームの解決によりSMTPサーバーを実行する、適切なホストのアドレスを決定します。 SMTPサーバーは最終の目的地あるいは中間の「リレー」(すなわち、それは、メッセージを受け取った後にSMTPクライアントの役割を引き受けるかもしれません)のいずれかかもしれないか、あるいは「ゲートウエイ」(すなわち、それはSMTP以外にさらにあるプロトコルを使用して、メッセージを輸送するかもしれません)。 SMTPコマンドはSMTPクライアントによって生成され、SMTPサーバーに送られます。 SMTP返答はコマンドに応じてSMTPサーバーからSMTPクライアントまで送られます。 言いかえれば、メッセージトランスファーは、オリジナルのSMTP送信器と最終のSMTP受取人の単一の関係で生じることができるか、あるいは中間のシステムによって一連のホップで生じることができます。 いずれの場合で、メッセージに対する責任の形式上のハンドオフは生じます:プロトコルは次のことを必要とします、メッセージを運ぶか失敗がそうすることを適切に報告することに対するサーバー受理責任。 一度送信チャンネルが設立され、頭文字握手が完成したならば、SMTPクライアントは通常メイル・トランザクションを始めます。 そのようなトランザクションは、メッセージ内容それ自身(任意のヘッダーあるいは他の構造を含んで)のメイルおよび送信の発明者および目的地を指定する一連のコマンドから成ります。 同じメッセージが多数の受取人のもとへ送られる場合、このプロトコルは、同じ目的地(あるいは中間のリレー)ホストですべての受取人のためのわずかに1部のデータの送信を促進します。 サーバーは返答を備えた各コマンドに応答します; 返答は、コマンドが受理されたことを示すかもしれません、追加のコマンドは期待されます、あるいは、一時的あるいは永久のエラー条件が存在する。 コマンドは、送信器あるいは受取人がサーバーを含むかもしれないことを明示しています。セクション2.2で議論されるように、可能になったSMTPサービス拡張は要求します。 [13]をパイプラインで送るコマンドのような相互に同意された拡張リクエストはこれを修正することができますが、対話は1-一度に故意に密集行進法です。 Klensin基準(Klensin Standards)は[6ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、一度与えられたメイル・メッセージが送信されたならば、2001年、クライアントは一方のするかもしれません、リクエスト、それ、接続、シャット・ダウンされるか、他のメイル・トランザクションを始めてもよい。 さらに、SMTPクライアントは、電子メールアドレスの立証あるいはメーリング・リスト加入者アドレスの検索のような付随的なサービスのためにSMTPサーバーへの接続を使用するかもしれません。 上に示唆されるように、このプロトコルはメイルの送信にメカニズムを供給します。 2人のホストが同じ輸送業務に接続される場合、この送信は、通常送るユーザのホストから受信ユーザのホストに直接思い浮かびます。 それらが同じ輸送業務に接続されない場合、送信は1つ以上のリレーSMTPサーバーによって生じます。 どちらかとしてSMTPリレーを演じる中間宿主、あるいは他のある送信環境の中へのゲートウエイがドメインネーム・サービス(DNS)メイルeXchangerメカニズムの使用によって通常選択されているとともに。 通常、中間宿主は、明示的な「出所」作業工程によってではなくDNS MXレコードによって決定されます(セクションおよび付録CおよびF.2 5を参照)。 2.2 RFC 821の10年(およそ)後に、1990年にスタートした努力中のエクステンション・モデル(Extension Model)2.2.1バックグラウンドは、完成しました、プロトコルは、オリジナルのSMTP必要条件の向こうの共有された機能性を利用することにクライアントおよびサーバーが合意することを可能にする「サービス拡張」モデルで修正されました。 SMTP拡張メカニズムは、それによって拡張SMTPクライアントおよびサーバーが互いを認識するかもしれない手段を定義します。また、サーバーは、それが支援するサービス拡張に関してクライアントに通知することができます。 同時代のSMTP(Contemporary SMTP)インプリメンテーション、MUST、基礎的な拡張メカニズムを支援します。 例えば、サーバー、MUST、それらが特定の拡張およびクライアントSHOULDをインプリメントしなくても、EHLOコマンドを支援する、優先的にHELOではなくEHLOを利用します。 (しかしながら、より古い一致するインプリメンテーションとの互換性については、SMTPクライアントおよびサーバーMUSTは蓄えとしてオリジナルのHELOメカニズムを支援します。) もし相互運用目的のためにHELOの異なる特性を識別してはならなければ、このドキュメントは単にEHLOについて議論します。 SMTPは広く展開します。また、高品質インプリメンテーションは、非常に強健であると分かりました。 しかしながら、インターネットコミュニティーは、プロトコルが最初に設計された時予想されなかったいくつかのサービスが重要であると今考えます。 それらのサービスの支援が加えられることになっている場合、それは、より古いインプリメンテーションが気に入られるように働き続けることを可能にする方法で行われるに違いありません。 拡張フレームワークは次のものから成ります、Klensin基準(Klensin Standards)は[7ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、2001-初期のHELOに取って代わるSMTPコマンドEHLO-SMTPサービス拡張のレジストリ、―SMTP MAILおよびRCPTコマンドへの追加のパラメーター、そして―非ASCII送信[33]中のDATAのためにのようにこのプロトコルの中で定義されたコマンドのためのオプションの置換。 SMTPの強度は第1にその単純性から来ます。 多くのプロトコルを備えた経験は、少数のオプションを備えたプロトコルが遍在に傾いている多くのオプションを備えたプロトコルが不明瞭に傾いていることを示しました。 全ての、拡張は、その利益にかかわらず、そのインプリメンテーション、配備および相互運用コストに関して注意深く吟味されるに違いありません。 多くの場合では、SMTPサービスを拡張するコストが恐らく利益より重要でしょう。 2.2.2 IANAが維持するエクステンションの定義、および登録、SMTPサービス拡張のレジストリ。 対応するEHLOキーワード価値は各拡張に関係しています。 IANAで登録された各サービス拡張は、形式上の標準トラックあるいはIESG承認された実験のプロトコル・ドキュメントの中で定義されるに違いありません。 定義は次のものを含んでいるに違いない:―SMTPサービス拡張の本文の名前; - 拡張に関連したEHLOキーワード価値; - EHLOキーワード価値に関連したパラメーターのシンタックスおよび可能な値; - 拡張(追加の動詞は通常あるだろうが、あるためには要求されません、EHLOキーワード価値と同じ)に関連した任意の追加のSMTP動詞; - MAILまたはRCPTの動詞に拡張が関連させる、すべての新しいパラメーター; - 拡張の支援がサーバーとクライアントのSMTPの振る舞いにどう影響するかの記述; そして、この標準中で指定されたその上に、拡張がコマンドMAILおよび(または)RCPTの最大の長さを増加させているインクリメント。 Klensin基準(Klensin Standards)は[8ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、2001年、さらに、任意のEHLOキーワード価値、から始めて、1つの、上部、あるいは、小文字「X」は、もっぱら双務協定によって使用されるローカルSMTPサービス拡張に言及します。 「X」MUST NOTで始まるキーワード、公認のサービス拡張の中で使用されます。 反対に、EHLOレスポンスで示されたキーワード価値、それは「X」MUSTから始まらない、標準、標準トラックあるいはIANAで登録されたIESGに良いとされた実験のSMTPサービス拡張に一致します。 一致するサーバーMUST NOT提示は、公認の拡張に記述されないキーワード価値の非"X"前に付けました。 追加の動詞およびパラメーター名はEHLOキーワードと同じ規則によって拘束されます; 特に、「X」で始まる動詞は登録されないか標準化されないかもしれないローカルの拡張です。 反対に、「X」で始まらない動詞は常に登録されるに違いありません。 2.3 用語、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、またこのドキュメント中の「OPTIONAL」解釈されるためにある、として、記述された、以下に。 1. MUST、この単語あるいは用語「REQUIRED」あるいは、「SHALL」は、定義が明細の絶対的な要求であることを意味します。 2. MUST NOT、この句あるいは句「SHALL NOT」、定義が明細の絶対的な禁止であることを意味します。 3. SHOULD、この単語あるいは形容詞「RECOMMENDED」、有効な理由が特別のアイテムを無視する特別の環境の中に存在するかもしれないことを意味する、しかし、十分な含意は異なるコースを選ぶ前に理解され注意深く量られるに違いない。 4. SHOULD NOT、この句あるいは句「NOT RECOMMENDED」は、特別の振る舞いが受理可能か、有用な場合、有効な理由が特別の環境の中に存在するかもしれないことを意味します、しかし、十分な含意は理解されるべきです、またこのラベルで記述された任意の振る舞いをインプリメントする前に注意深く量られたケース。 5. MAY、この単語あるいは形容詞「OPTIONAL」、アイテムが本当にオプションであることを意味します。 1社のベンダーは、特別の市場がそれを要求するのであるいはもう一人のベンダーが同じアイテムを省略しているかもしれない一方それが製品を増強するとベンダーが思うので、アイテムを含むことに決めてもよい。 特別のオプションMUSTを含んでいないインプリメンテーション、恐らく縮小された機能性でだがオプションを含んでいる別のインプリメンテーションと共同で作業するために準備されています。 同じ静脈中で、Klensin基準(Klensin Standards)が追跡するインプリメンテーション[9ページ]RFC 2821単純メイル転送プロトコル4月、2001は特別のオプションMUSTを含んでいます、オプション(以外の、もちろん、特徴については、オプションは提供します)2.3.1メイル・オブジェクトSMTP(Mail Objects SMTP)を含んでいない、別のインプリメンテーションと共同で作業するために準備されている、メイル・オブジェクトを輸送します。 メイル・オブジェクトは封筒および内容を含んでいます。 SMTP封筒は、一連のSMTPプロトコル・ユニット(セクション3に記述された)として送られます。 それは、発明者アドレス(エラー報告書はそれに向けられるべきである)から成ります; 1つ以上の受取人アドレス; またオプションのプロトコル拡張資料。 歴史上、即時のディスプレイのような交替配達モードを指定するために受取人アドレス明細コマンド(RCPT TO)上の変化を使用することができるかもしれません; それらの変化は今大いに非難されました(付録F、セクションF.6を参照)。 SMTP内容はSMTP DATAプロトコル・ユニット中で送られ、2部があります:ヘッダーおよび身体。 内容が他の同時代の標準に一致する場合、ヘッダーはメッセージフォーマット明細[32]でのように組み立てられた、フィールド/値ペアのコレクションを形成します; 身体は、もし組み立てられれば、MIME[12]に従って定義されます。 内容は、米国-ASCII(US-ASCII)レパートリー[1]を使用して表現された自然界において本文です。 SMTP拡張(「8BITMIME」[20]のような)は満足している身体のためのこの制限を緩めるかもしれませんが、満足しているヘッダーは米国-ASCII(US-ASCII)レパートリーを使用して、常にエンコードされます。 米国-ASCII(US-ASCII)レパートリーを使用して、まだそれらをエンコードしている間、MIME拡張[23]は、米国-ASCII(US-ASCII)レパートリーの外側のヘッダー価値を表わすためにアルゴリズムを定義します。 2.3.2 RFC 821の中のセンダ、およびレシーバー、SMTPトランザクションに参加する2人のホストは、「SMTP送信器」および「SMTPレシーバー」と評されました。 それぞれ、このドキュメントは現在の産業用語を反映するために変更されており、それらを「SMTPクライアント」(時々単なる「クライアント」)、および「SMTPサーバー」(あるいは単なる「サーバー」)と従って呼びます。 明瞭のために必要だった場合、リレー状況、「レシーバー」および「送信器」用語のサーバー、およびクライアントが、まだ使用されるとともに、与えられたホストが両方を演じてもよいので。 2.3.3 メイル・エージェント(Mail Agents)およびメッセージは付加的なメイル・システム用語をストアします、RFC 821が公表された後、共通になった、また便利なところで、この明細の中で使用されます。 SMTPサーバーとクライアントは特にメイル輸送業務を提供し、したがって「メール転送エージェント(Mail Transfer Agents)」(MTA)の役割をします。 出所とKlensinの基準が[10ページ]RFC 2821単純メイル転送プロトコル4月を追跡するとともに、「メイル・ユーザ・エージェント(Mail User Agents)」(MUAまたはUA)は通常考えられます、メイルの2001の目標。 出所では、MUAが、ユーザから送信され、かつMTAにそれにハンドオフするメイルを集めるかもしれません; MUA(あるいは、それに少なくとも責任を転送して、例えば、「メッセージ店」にメッセージを残すことによって)にメイルにハンドオフするように、決勝(「配達」)MTAは考えられるでしょう。 これらの用語が少なくとも他の環境中の大きな正確の外観、MUAの間の暗黙の境界およびMTAと共に使用されている一方、しかしながら、しばしば正確に共通と一致しない、そして一致すること、インターネットメールを備えた練習。 従って、リーダは、これらの用語が他のところに使用された場合、意味されるかもしれない強い関係、および責任の推論に用心深いに違いありません。 2.3.4 この明細のためのホスト、ホストはインターネット(あるいは、個人のTCP/IPネットワークへのいくつかの場合に)に付けられ、SMTPプロトコルを支援したコンピューター・システムです。 ホストは名前によって知られています(「領域」を参照); 数のアドレスによってそれらを識別することは落胆します。 2.3.5 ドメインA(Domain A)領域(あるいはドメインネーム)はドットに分離された1つ以上のコンポーネントから成ります。 これらのコンポーネント(DNS用語[22]の「ラベル」)は、文字、数字およびASCII文字セット[1]から取り出されたハイフンのシーケンスから成る、SMTP目的のために制限されます。 ドメインネームはドメインネーム階層の中で、ホストの、および他の実体の名前として使用されます。 例えば、領域は別名(CNAME RRのラベル)を参照するかもしれません。あるいは、メイルeXchangerのラベルはホスト名を表わす代わりにメイルを伝えるために使用されるために記録します。 この明細の[22]およびセクション5を参照してください。 ドメインネームは、このドキュメントおよび[22]に記述されたとともに、全、完全に資格のある名前です(しばしば「FQDN」と呼ばれた)。 FQDNの形でないドメインネームは単なるローカルの別名です。 ローカルの別名、MUST NOT、任意のSMTPトランザクションに現われます。 2.3.6 バッファーと州のテーブルSMTP(Table SMTP)セッションは、両方のパーティーが現在の状態の共通の視界を注意深く維持して、statefulです。 このドキュメント中で、私たちは、クライアントによって使用されるかもしれないサーバーに基づいて仮想の「バッファー」によるこの州、および「州テーブル」を作ります、に、例えば、「バッファーをクリアーします」あるいは、「州テーブルをリセットする」、ある前の州に廃棄されるバッファーおよび状態の情報に返させること Klensin基準(Klensin Standards)は[11ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、2001年の2.3.7のラインのSMTPのコマンド、もしまたサービス拡張(メッセージデータ)によって変更されなかったならば、「ライン」で送信されます。 ラインは、ASCII性格「LF」(魔力値0A)が直後に続く、シーケンスASCII文字「CR」(魔力値0D)によって終了した0あるいはより多くのデータ特徴から成ります。 この終了シーケンスはこのドキュメント中でとして表示されます。 インプリメンテーションを一致させること、MUST NOT、他の性格あるいは文字シーケンスをライン・ターミネーターと認めるか生成します。 範囲MAY(Limits MAY)オン・ラインで課される、サーバー(セクション4.5.3を参照)による長さ。 さらに、「露出した」「CR」の外観あるいはテキスト(つまり、どちらか、他方なしで)中の「LF」文字は、ツールとしてメイル・システムを使用するメイル・インプリメンテーションおよびアプリケーション中の問題を引き起こす長い歴史を持っています。 SMTPクライアント・インプリメンテーション、MUST NOT、これらの文字を送信する、以外は、上に示されるように、それらがライン・ターミネーターそして次にMUSTとして意図される場合、シーケンスとしてのみそれらを送信します。 2.3.8 この明細が4つのタイプのSMTPシステム中の区別を作る発明者、配達、リレーおよびゲートウェイ・システム(Gateway Systems)、役割上でそれらのシステムを基づかせる、電子メールを送信する際にプレーします。 「親」システム(時々SMTP発明者に電話した)は、インターネットへメイルを導入します、あるいは、輸送業務環境へ、より一般に。 「配達」SMTPシステムは輸送業務環境からメイルを受け取り、それをメイル・ユーザ代理人へ渡す一つか、あるいはメイル・ユーザ代理人が続いて期待されるメッセージ店にそれを残します、アクセスします。 「リレー」SMTPシステム(通常ちょうど「リレー」と呼ばれた)は、SMTPクライアントからメイルを受け取り、跡情報を加えること以外の、さらに中継するための別のSMTPサーバーへの、あるいは配達のためのメッセージデータへの修正なしで、それを送信します。 「ゲートウエイ」SMTPシステム(通常ちょうど「ゲートウエイ」と呼ばれた)は、dが送信する1つの輸送環境中のクライアント・システムからメイルを受け取ります、それ、別の輸送環境中のサーバー・システムに。 ゲートウエイの一方の横の輸送環境間のプロトコルあるいはメッセージ意味論の差は、ゲートウエイ・システムがSMTPリレー・システムに許されないメッセージへの変形を実行することを必要とするかもしれません。 この明細のために、SMTPがそれらの両側で使用されても、アドレスを書き直すファイアウォールはゲートウエイと見なされるべきです([11]を参照)。 Klensin基準(Klensin Standards)は[12ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、2001年の2.3.9のメッセージのコンテンツ、およびメイル・データ(Mail Data)DATAコマンドが受理され、データ表示の終了の前に送信される後、送信された資料について記述するために、用語「メッセージ内容」および「メイル・データ」は、このドキュメントの中で交換できて使用されます。 メッセージ内容はメッセージヘッダーおよび恐らく構造化したメッセージ身体を含んでいます。 MIME明細[12]は構造化したメッセージ身体のために標準のメカニズムを提供します。 2.3.10 郵便箱、およびこの明細の中で使用されるようなアドレス、「アドレス」はメイルがもとへ送られるユーザあるいはメイルが置かれる位置を識別する文字ストリングです。 その貯蔵場を指します(「郵便箱、すなわち」)。 もしメイルが置かれる(郵便箱)位置とそれ(アドレス)への言及の相違が、重要でなければ、2つの用語は典型的に交換できて使用されます。 アドレスは、通常ユーザと領域の仕様書から成ります。 協定を指定する標準の郵便箱はあると定義されます「ローカル( 部分@領域)」:同時代の使用法は、単純な「ユーザー名」よりアプリケーションのはるかに広いセットを許します。 従って、また問題の長い歴史により、中間宿主がそれらの修正により輸送を最適化することを試みた場合、ローカルの部分MUST、アドレスの領域部分で指定されたホストによってのみ意味論を解釈され割り当てられる。 2.3.11 SMTP返答がコマンドに応じて送信チャンネル経由でレシーバーから送信器まで送られた認識(肯定的か否定)であると返答します。 返答の一般的な形式はテキスト・ストリングが通常後続する数値の完成コード(示す失敗あるいは成功)です。 コードはプログラムによる使用のためにあります。また、テキストは人間のユーザのために通常意図されます。 最近の仕事[34]は、補足の完成コードおよびより特定の完成コードの使用を含む、返答ストリングをさらに組み立てて、指定しました。 2.4 一般的なシンタックス法則(General Syntax Principles)およびトランザクション・モデルSMTP(Transaction Model SMTP)コマンドおよび返答は厳しいシンタックスを持っています。 コマンドはすべてコマンド動詞から始まります。 返答はすべて3本の数字数値コードから始まります。 いくつかのコマンドおよび返答中で、引き数、MUST、動詞か返答コードに続きます。 時々、いくつかのコマンドは引き数(動詞の後の)を受理しません。また、自由形式テキストはいくつかの返答コードに自由に続きます。 両方の場合に、テキストが現われるところで、それはスペース文字によって動詞か返答コードから分けられます。 コマンドの定義を完成してください。そうすれば、返答はセクション4に現われます。 Klensin基準(Klensin Standards)は、2001の動詞、および引き数価値(例えば「TO」:「あるいはに:」RCPTコマンドおよび拡張名前キーワード中で)が、ケースでない[13ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、敏感、郵便箱のローカルの一部分(SMTPエクステンション(SMTP Extensions)は明示的にケース敏感な要素を指定するかもしれません)のこの明細中の単独の例外で、 すなわちコマンド動詞、郵便箱のローカルの一部分以外の引き数価値、そして自由形式テキストMAY、大文字中でエンコードされる、小文字、上部のことの任意の混合、およびその意味への衝撃のない小文字。 これは郵便箱のローカルの一部分に該当するNOTです。 微妙な場合として扱われた郵便箱MUST BEのローカルの部分。 したがって、郵便箱のローカルの部分の場合を保存する、SMTPインプリメンテーションMUST取り分注意。 郵便箱領域は微妙な場合ではありません。 何人かのホストにとって、ユーザ「鍛冶屋」は、特にユーザ「スミス」とは異なります。 しかしながら、郵便箱のローカルの部分のケース感度の開発は相互運用を妨害し落胆します。 少数のSMTPサーバー、この明細(またRFC 821)のバイオレーション中で、次のことを要求する、動詞が大文字中のクライアントによってエンコードされるように命じます。 それらのサーバーを提供するこの符号づけを使用する、インプリメンテーションMAY(Implementations MAY)希望。 引き数フィールドはラインの終了で終わる、可変長さ文字ストリングから成ります、つまり、文字シーケンスで、 このシーケンスが受け取られるまで、レシーバーは処置を講じないでしょう。 各コマンドのシンタックスはそのコマンドの議論で示されます。 共通の要素およびパラメーターはセクション4.1.2に示されます。 コマンドと返答は、ASCII文字セット[1]からの文字から構成されます。 輸送業務が8ビットのバイト(オクテット)送信チャンネルを提供する場合、各7ビットの性格は0にクリアーされた高いオーダービットを備えた1オクテットで送信された右揃えです。 より明確に、拡張されないSMTPサービスは7ビットの輸送のみを提供します。 していない親SMTPクライアントは、成功裡に特別のサーバーMUST NOTと適切な拡張を取り決めました、オクテットの高いオーダービット中の情報を備えたメッセージを送信します。 そのようなメッセージがこの規則に違反して送信される場合、SMTPサーバーを受け取ること、MAY、高いオーダービットをクリアーするか、無効のものとしてメッセージを拒絶する。 一般(リレーSMTP SHOULD)に、それが受け取ったメッセージ内容が有効であると仮定する、そして、封筒がそうすることを可能にすると仮定すること、その内容を検査せずに、それを中継します。 もちろん、間違ったレッテルが内容に貼られ、データ・パスが実際の内容を受理することができない場合、これは、受取人への厳しく改ざんされたメッセージの最終の配達に帰着するかもしれません。 配達SMTPシステム、MAY、それらを伝えるのではなくそのようなメッセージを拒絶する(「弾んでください」)。 SMTPシステムを送らないことは、Klensin基準(Klensin Standards)が追跡するすべての性格中の封筒コマンドを送ることを許されます[14ページ]RFC 2821単純メイル転送プロトコル4月、米国-ASCII(US-ASCII)以外の2001のセット; 受信システム、SHOULD「500のシンタックス・エラー(-無効の性格-)」返答を通常使用して、そのようなコマンドを拒絶します。 8ビットのメッセージ内容送信MAY、拡張SMTP設備、顕著に「8BITMIME」拡張[20]を使用して、クライアントによってサーバーに要請されます。 8BITMIME SHOULD、SMTPサーバーによって支援されます。 しかしながら、それ、MUST、ない、無制限の8ビットの資料を送信する認可として解釈されます。 8BITMIME MUST NOT、適切な満足しているトランスファー符号づけを備えたMIMEフォーマットの中にそれがないことの上の高いビットを備えた資料のための送信器によって要求される; サーバー、MAY、そのようなメッセージを拒絶します。 このドキュメントの中で使用されるメタ言語学の記法は、他のインターネットメール・システム・ドキュメントの中で使用される「増音したBNF(Augmented BNF)」に相当します。 そのシンタックスに精通していないリーダはABNF明細[8]を調べるべきです。 テキストを実行するのに使用されるメタ言語用語は、明瞭のためにとがっているブラケット(例えば)によって囲まれます。 3. SMTP手続き(SMTP Procedures):概観、このセクションは、SMTPの中で使用される手続きの記述を含んでいます:セッション開始、郵便箱名および拡大するメーリング・リストを確認するメイルを転送するメイル・トランザクション、および開始と閉鎖の交換。 中継、メイル領域に関する注釈および役割を変更する議論に関するコメントは、このセクションの終わりに含まれています。 いくつかの完全なシナリオは付録Dの中で示されます。 3.1 セッション・イニシエーション(Session Initiation)クライアントがサーバーに接続を開き、サーバーが開始メッセージとともに答える場合、SMTPセッションが始められます。 SMTPサーバーインプリメンテーション、MAY、接続挨拶にそれらのソフトウェアおよびバージョン情報の識別を含んでいる、220本のコード、より効率的な絶縁を許す練習および任意の問題の修理の後に返答します。 それがセキュリティ関係を引き起こすところで、SMTPサーバーがソフトウェアおよびバージョン発表を不能にするべき、インプリメンテーションMAY(Implementations MAY)形準備。 いくつかのシステムがさらにメイル問題のためのそれらの接触ポイントを識別している一方、これは必要な「郵便局長」アドレスの維持の代わりではありません(セクション4.5.1を参照)。 SMTPプロトコルは、まだ以下のように初期の接続を許可している間サーバーが形式的にトランザクションを拒絶することを可能にします:554のレスポンスMAY、220の代わりに初期の接続開始メッセージ中で与えられます。 このアプローチMUSTをとるサーバー、まだクライアントが接続およびSHOULDを閉じる前にQUIT(セクション4.1.1.10を参照)を送るのを待つ、Klensin基準(Klensin Standards)を備えた任意の介在するコマンドに応答する[15ページ]RFC 2821単純メイル転送プロトコル4月を追跡する、2001年の「コマンドの503の悪いシーケンス。」 そのようなシステムへのSMTP接続を行なう試みが恐らく誤っているので、接続開始SHOULDの上の554のレスポンスを返すサーバー、送るシステムのデバッグすることを促進するために返答テキスト中の十分な情報を提供します。 3.2 一度サーバーが歓迎するメッセージおよびクライアントを送信したならば、クライアント・イニシエーション(Client Initiation)は、それを受け取りました、クライアントは、クライアントの同一性を示して、サーバーへ通常EHLOコマンドを送ります。 セッションの開始に加えて、EHLOの使用は、クライアントがプロセス・サービス拡張に有能であることを示し、サーバーがそれが支援する拡張のリストを提供することを要求します。 始められているメイル・セッションのサービス拡張を要求しない支援活動拡張および同時代のクライアントにできないより古いSMTP(Older SMTP)システム、MAY、EHLOの代わりにHELOを使用します。 サーバー、MUST NOT、HELOコマンドに対する拡張EHLOスタイルレスポンスを返します。 サーバーがEHLOに対する「認識されないコマンド」レスポンスを返す場合、クライアントSHOULD、フォールバック機能に有能で、HELOを送る。(特別の接続試みのために、) EHLOコマンドでは、コマンドを送るホストがそれ自体を識別します; コマンドは「ハロー、私が<領域>です」と言うと解釈されるかもしれません。 3.3 メイル・トランザクション(Mail Transactions)はそこでSMTPメイル・トランザクションに対する3段階です。 トランザクションは、送信器識別を与えるMAILコマンドで始まります。 (一般に、メイル・トランザクションが進行中でない場合に限り、MAILコマンドは送られるかもしれません;セクション4.1.4を参照してください。) 一連の1つ以上のRCPTコマンドはレシーバー情報を与えて、続きます。 その後、DATAコマンドは、メイル・データの転送を始めて、「メイルの終了」データ指標(それはさらにトランザクションを確認する)によって終了します。 手続きの第一歩はMAILコマンドです。 MAIL FROM:[SP<メイルパラメーター>] このコマンドは、新しいメイル・トランザクションがスタートしているとSMTPレシーバーに伝えます、また、任意の受取人あるいはメイル・データを含むその州テーブル、およびバッファーをすべてリセットすること 1番目あるいはただ一つの引き数の<逆のパス>部分は出所郵便箱(の間で<"また「>」ブラケット)(それはエラー(エラーを報告する議論に関してはセクション4.2を参照)を報告するために使用することができる)を含んでいます。 もし受理されれば、SMTPサーバーは250のよろしい返答を返します。 郵便箱明細がある理由のために受理可能でない場合、サーバーMUST、Klensin基準(Klensin Standards)が2001年の失敗が永久か(つまりクライアントが同じアドレスを再び送ろうとする場合に、再び生じるだろう)、一時的である(つまり、クライアントが再びその後試みる場合にアドレスが受理されるかもしれません)[16ページ]RFC 2821単純メイル転送プロトコル4月を追跡するかどうか示す返答を返します。 この要求の明白な範囲にもかかわらず、1つ以上の前方のパス(RCPTコマンド中の)を検査することができるまで、逆のパスの受容性が決定されないかもしれない環境があります。 それらの場合に、サーバーMAY、前方のパスが受け取られ検査される後、合理的に逆のパス(250の返答を備えた)、そして次に報告書問題を受理します。 通常は、失敗は550あるいは553の返答を生産します。 しかしながら、歴史上、<逆のパス>は単なる郵便箱を越えるものを含むことができます、同時代のシステムSHOULD NOT使用出所作業工程(付録Cを参照)。 オプションの<メイルパラメーター>は協定されたSMTPサービス拡張に関係しています(セクション2.2を参照)。 手続きの第2のステップはRCPTコマンドです。 RCPT TO:[SP] 1番目あるいはこのコマンドへの単に引き数は前方のパスの(通常郵便箱および領域、常にそばに囲まれた<"また「>」ブラケット)識別する1受取人を含んでいます。 もし受理されれば、SMTPサーバーは250のよろしい返答を返し、前方のパスを格納します。 受取人が引き渡せるアドレスでないと知られていれば、SMTPサーバーは典型的にストリングと共に、550の返答を返します、のように「そのようなユーザはない"また郵便箱名(他の環境、またコードが可能であると返答する)。 手続きのこのステップは何回も繰り返すことができます。 <前方のパス>は単なる郵便箱を越えるものを含むことができます。 歴史上、その<パスを進める>しかしながら、ホストおよび目的地郵便箱のリストを敗走させる出所でありうる、同時代のSMTPクライアント、SHOULD NOT、出所ルート(付録Cを参照)を利用します。 サーバーMUST(Servers MUST)前方のパス中の出所ルートのリストに遭遇するために準備されている、しかしSHOULD、支援するためにルートかMAY下落を無視する、その、中継、それらは意味します。 同様に、他のホストあるいはシステムのために予定されるメイルを受理する、サーバーMAY下落。 これらの制限は、十分なSMTP機能性を支援しないクライアントのためにサーバーをリレーのように役立たなくします。 従って、能力を制限した、クライアント、MUST NOT、それらのメイル処理(中継)サイトとしてインターネット上のいかなるSMTPサーバーも使用することができると仮定します。 RCPTコマンドが前のMAILコマンドなしで現われる場合、サーバーMUST、503の「コマンドの悪いシーケンス」レスポンスを返します。 オプションのは協定されたSMTPサービス拡張に関係しています(セクション2.2を参照)。 手続きの第3のステップはDATAコマンド(あるいは、ある選択肢はサービス拡張中で指定されました)です。 Klensin基準は[17ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、2001年のデータ もし受理されれば、SMTPサーバーは354の中間の返答を返し、結果がすべて並ぶと思います、まで、しかしメッセージテキストであるためにはメイル・データ指標の終了を含んでいないこと テキストの終了がいつ成功裡に受け取られるか、SMTPレシーバーを格納したかは、250のよろしい返答を送ります。 メイル・データが送信チャンネル上で送信されるので、コマンドおよび返答対話を再開することができるように、メイル・データの終了が示されるに違いありません。 SMTPは、ラインを送ることによりメイル・データの終了を示します、含んでいること、1つの(単に)""。 (期間または終止符)。 透明手続きはこれがユーザのテキストに邪魔をするのを妨げるために使用されます(セクション4.5.2を参照)。 メイル・データ指標の終了はさらにメイル・トランザクションを確認し、SMTPサーバーを伝えます、に、今格納された受取人およびメイル・データを処理します。 もし受理されれば、SMTPサーバーは250のよろしい返答を返します。 DATAコマンドはプロトコル交換に2ポイントだけで失敗することができます:―MAILがなかった場合、あるいは、RCPT、コマンドあるいはすべてのそのようなコマンドは拒絶されませんでした、サーバーMAY、DATAコマンドに応じて「シーケンスからのコマンド」(503)あるいは「有効な受取人がない」(554)返答を返します。 それらの返答(あるいは他の5yz返答)のうちの1つが受け取られる場合、クライアントMUST NOT、メッセージデータを送信する; 一般に、メッセージデータMUST NOT、もし354の返答が受け取られなければ、送られます。 - 動詞が最初に受理され、354の返答が出た場合、もしただメイル・トランザクションが不完全ならば(例えば受取人はない)、あるいは資源が利用不可能だった(不意に利用不可能になるサーバーを含んで(もちろん))場合、DATAコマンドは失敗するでしょう。あるいは、サーバーがそれを決定する場合、メッセージは政策あるいは他の理由のために拒絶されるべきです。 しかしながら、実際上、メッセージテキストが受け取られた後まで、いくつかのサーバーは受取人立証を実行しません。 これらのサーバー、SHOULD、1人以上の受取人のために「後の失敗」として失敗を扱い、セクション6で議論されるようなメイル・メッセージを返す。 データが受理された後、「見つからない550箱の郵便箱」(あるいは等価物)返答コードを使用することは、クライアントがどの受取人が失敗したか断定することを困難か不可能にします。 いつ、RFC 822フォーマット[7、32]使用されている、メイル・データは、デート、モルモットのようなメモ・ヘッダー・アイテムを含んでいます、に、Cc、から。 サーバーSMTP(Server SMTP)システム、SHOULD NOT、RFC 822あるいはMIME[12]メッセージヘッダーの知覚された欠陥あるいはメッセージ身体に基づいたメッセージを拒絶します。 Klensin基準(Klensin Standards)は特に[18ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、2001年、それら、MUST NOT、メッセージを拒絶する、どれの中で、数、フィールドに憤慨する、一致しない、あるいは憤慨するに、現われる、なしで、憤慨するから、または憤慨する―日付。 メイル・トランザクションは、MUSTが上に議論された順に使用されるように命じます。 3.4 アドレス修正(Address Correction)用フォワーディングあるいはアップデートする進める(Updating Forwarding)支援はアドレスを内側は統合し単純化するために最もしばしば要求されます、あるいはに比べて、ある企業、そして現在のものと人の先のアドレスをリンクするアドレスを設立するためにより頻繁でない。 メッセージ(送信器へのサーバー通知のない)の暗黙のフォワーディングはセキュリティか非開示目的のために、同時代のインターネットにおいて一般的です。 企業および「新しいアドレス」場合の両方では、情報を隠す(時々セキュリティ)考察が、フォワーディング活動の副作用としてSMTPプロトコルを通って「最終の」アドレスの発見に反対します。 最終アドレスが送信器によってさらに到達可能でないかもしれない場合、これは特に重要かもしれません。 従って、RFC 821のセクション3.2に記述された「フォワーディング」メカニズム、特に251(訂正された目的地)および551は、implementersによって、および形成するシステムによって(それらが利用可能な場合)RCPTからのコードが注意深く評価されるに違いないと返答します。 項目中で:それらがアドレス変更に気づいている場合、MAYが前にメッセージとして送る*サーバー。 それらがそうする場合、それら、MAY、アドレスを更新する情報に251本のコードを供給するか発送してもよい「暗黙に」また250本のコードを返します。 しかし251本のコードが使用される場合、それら、MUST NOT、クライアントが現実にアドレス情報あるいはリターンさえを更新するだろうと仮定する、ユーザへのその情報。 交互に、*サーバー、MAY、アドレスされた時、それらが引き渡せない場合、メッセージを拒絶するか弾ませます。 それらがそうする場合、それら、MAY、アドレスを更新する情報に551本のコードを供給するか、550本のコードで配達できないものとしてメッセージを拒絶してもよい、またアドレス特定の情報はない。 しかし551本のコードが使用される場合、それら、MUST NOT、クライアントが現実にアドレス情報あるいはリターンさえを更新するだろうと仮定する、ユーザへのその情報。 251および(または)551を支援するSMTPサーバーインプリメンテーションは、コードがそれらが生憎情報を示すだろうと結論を下すサイトがそれらの使用を不能にするか制限することができるように構成メカニズムを提供するように強く促進されると返答します。 Klensin基準(Klensin Standards)は、アドレス3.5.1概観SMTP(Overview SMTP)をデバッグするための2001年の3.5のコマンドがユーザー名を確認するかあるいはメーリング・リストの内容を得るコマンドを提供する[19ページ]RFC 2821単純メイル転送プロトコル4月を追跡します。 これはVRFYとEXPNのコマンドをやめます。それは文字ストリング引き数を行っています。 インプリメンテーションSHOULD(Implementations SHOULD)支援VRFY、およびEXPN(しかしながら、セクション3.5.2および7.3を参照)。 VRFYコマンドについては、ストリングがユーザー名あるいはユーザー名および領域です(以下を参照)。 正常な(つまり250)レスポンスが返される場合、レスポンスMAY、ユーザおよびMUSTの姓名を含んでいる、ユーザの郵便箱を含んでいます。 それ、MUST、次の形式のどちらかの中に次のとおりである:VRFYへの引き数である名前が1箱を越える郵便箱を識別することができた場合、ユーザー・ネーム<ローカルの部分@領域>ローカルの部分@領域、サーバーMAY、曖昧さに注意するか、代案を識別する。 言いかえれば、下記のうちのいかなるものでもVRFYに対する正当なレスポンスです:553人の曖昧なユーザあるいは553-、曖昧; 可能性は553-ジョー・スミス553-ハリー・スミス553メルビンです、あるいは553-曖昧; 可能性553-553-553 正常な環境の下では、553の返答を受け取るクライアントがユーザに結果を暴露すると予想されるでしょう。 使用、正確に与えられた形式および「曖昧なユーザ」あるいは「曖昧な」キーワード、恐らくそれらのような拡張返答コードで補われた[34]に記述した、求められるような他の言語の中への自動翻訳を促進するでしょう。 もちろん、クライアント、それ、高度に自動化された、あるいはそれ、英語より別の言語で作動していた、レスポンスを翻訳しようとすることに決めてもよい、Klensin基準(Klensin Standards)よりユーザへの他のある表示を返すために[20ページ]RFC 2821単純メイル転送プロトコル4月を追跡する、返答の2001年のリテラル・テキスト、あるいはユーザに報告する前の補足情報のためのディレクトリー・サービスを調べるようなある自動処置を講ずるために EXPNコマンドについては、ストリングがメーリング・リスト、および成功した(つまり250)マルチラインレスポンスMAYを識別します、ユーザおよびMUSTの姓名を含んでいる、メーリング・リスト上の郵便箱を与えます。 何人かのホストでは、共通のデータ構造が両方のタイプのエントリーを保持してもよいので、単一の郵便箱用のメーリング・リストと別名の相違が、少し曖昧です。また、単に1箱の郵便箱を含んでいるメーリング・リストを持っていることは可能です。 リクエストがメーリング・リストにVRFYを適用するためになされる場合、肯定的なレスポンスMAY、メッセージがそのようにアドレスした場合、与えられる、リスト上の皆にそうでなければ配達されるだろう、エラーSHOULD、報告される(例えば、「550、それはメーリング・リストである、ない、ユーザ」「あるいは252、メーリング・リストのメンバーを確認するのにできない」)。 リクエストがユーザー名を拡張するためになされる場合、サーバーMAY、1つの名前を含んでいるリストから成る肯定的なレスポンスあるいはエラーMAYを返す、報告される(例えば、「550、それはユーザー名である、ない、メーリング・リスト」)。 成功したマルチライン返答(EXPNには正常)の場合には、ちょうど1箱の郵便箱が返答の各ライン上で指定されることになっています。 曖昧なリクエストの場合は上に議論されます。 「ユーザー・ネーム」は曖昧な用語で、慎重に使用されました。 VRFYのインプリメンテーションまたはEXPNのコマンドMUSTは、「ユーザー名」として少なくともローカルの郵便箱の認識を含んでいます。 しかしながら、現在のインターネット以来、練習は、しばしば多数の領域のための単一のホスト取り扱いメイルに帰着します、ホスト(特にこの機能性を提供するホスト)、SHOULD「ユーザー名」として「ローカルの部分@領域」形式を認める; ホスト、MAY、さらに他のストリングを「ユーザー名」と認めることに決めます。 郵便箱リストを拡張する場合は、次のもののように、マルチライン返答を要求します:C:EXPN例人々S(EXPN Example-People S):250-ジョンPostelS:250-フレッドFoneboneS:250のサムQ.スミスあるいはC:EXPN実行の洗面所リストS(EXPN Executive-Washroom-List S):あなたに与えられなかった550のアクセス。 Klensin基準(Klensin Standards)は[21ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、2001年、VRFYとEXPNのコマンドの文字ストリング引き数はさらにありえません、制限した、ユーザー名および郵便箱リスト概念のインプリメンテーションの種類により。 いくつかのシステム上に、それは、メーリング・リストを含んでいるファイルのファイル名である、EXPNコマンドの引き数に適切かもしれません。しかし、再び、様々なファイルはインターネット中で協定を指定しています。 同様に、これらのコマンドによって返されるものにおける歴史上の変化はそのようなものです、それ、レスポンスSHOULD、非常に注意深く解釈される、場合、いずれにしても、そしてSHOULD、一般に診断の目的のために単に使用されます。 3.5.2 正常な(2yzまたは551)レスポンスがVRFYまたはEXPNのリクエストから返される場合、VRFYノーマルレスポンス(VRFY Normal Response)、「領域」が完全に資格のあるドメインネームである場合、返答は通常郵便箱名(つまり<「ローカルの部分@領域」>)を含んでいます、MUST、シンタックスに現われます。 この明細の意図を破ることを正当化するために十分に例外的な環境中で、自由形式のテキストMAY、返されます。 コンピューターおよび人々の両方によって解析を促進するために、アドレス、SHOULD、とがっているブラケットに現われます。 アドレスが自由形式のデバッギング情報ではなく、返される場合、EXPNおよびVRFY MUSTはSMTP RCPTコマンドにおいて使用可能な有効な領域アドレスだけを返します。 従って、アドレスがプログラムあるいは他のシステムへの配達を意味する場合、郵便箱名はいつもその目標MUSTに達しました、与えられます。 パス(明示的な出所ルート)MUST NOT、VRFYまたはEXPNによって返されます。 サーバー・インプリメンテーションSHOULD支援、VRFYおよびEXPNの両方。 セキュリティ理由のために、インプリメンテーション、MAY、ローカルの装置に構成オプションあるいは等価物によってこれらのコマンドのどちらかあるいは両方を不能にする方法を供給します。 それらが両方ともRFC 821においてオプションだったので、それら、MUST、それらが支援される場合、EHLOレスポンスでサービス拡張としてリストされます。 3.5.3 VRFYの意味あるいはEXPN成功レスポンスA(EXPN Success Response A)サーバーMUST NOTは、250を返します、もしそれが現実にアドレスを確認していなければ、VRFYまたはEXPNのコマンドに応じてコード化します。 項目(サーバーMUST NOTリターン(それがやったのが与えられたシンタックスが有効であることを確認することである場合、)250)中で。 その場合に、502(インプリメントされないコマンド)あるいは500の(シンタックス・エラー、命令する、未承認)SHOULD、返されます。 他のところに述べられるように、VRFYのインプリメンテーション(現実にアドレスを有効にし、情報を返す感覚中の)、およびEXPNは、強く勧められます。 従って、VRFYのために500または502を返すインプリメンテーションはこの明細への十分な従順の中にありません。 Klensin基準(Klensin Standards)は[17ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、2001年のDATA もし受理されれば、SMTPサーバーは354の中間の返答を返し、結果がすべて並ぶと思います、まで、しかしメッセージテキストであるためにはメイル・データ指標の終了を含んでいないこと テキストの終了がいつ成功裡に受け取られるか、SMTPレシーバーを格納したかは、250のよろしい返答を送ります。 メイル・データが送信チャンネル上で送信されるので、コマンドおよび返答対話を再開することができるように、メイル・データの終了が示されるに違いありません。 SMTPは、ラインを送ることによりメイル・データの終了を示します、含んでいること、1つの(単に)""。 (期間または終止符)。 透明手続きはこれがユーザのテキストに邪魔をするのを妨げるために使用されます(セクション4.5.2を参照)。 メイル・データ指標の終了はさらにメイル・トランザクションを確認し、SMTPサーバーを伝えます、に、今格納された受取人およびメイル・データを処理します。 もし受理されれば、SMTPサーバーは250のよろしい返答を返します。 DATAコマンドはプロトコル交換に2ポイントだけで失敗することができます:―MAILがなかった場合、あるいは、RCPT、コマンドあるいはすべてのそのようなコマンドは拒絶されませんでした、サーバーMAY、DATAコマンドに応じて「シーケンスからのコマンド」(503)あるいは「有効な受取人がない」(554)返答を返します。 それらの返答(あるいは他の5yz返答)のうちの1つが受け取られる場合、クライアントMUST NOT、メッセージデータを送信する; 一般に、メッセージデータMUST NOT、もし354の返答が受け取られなければ、送られます。 ― 動詞が最初に受理され、354の返答が出た場合、もしただメイル・トランザクションが不完全ならば(例えば受取人はない)、あるいは資源が利用不可能だった(不意に利用不可能になるサーバーを含んで(もちろん))場合、DATAコマンドは失敗するでしょう。あるいは、サーバーがそれを決定する場合、メッセージは政策あるいは他の理由のために拒絶されるべきです。 しかしながら、実際上、メッセージテキストが受け取られた後まで、いくつかのサーバーは受取人立証を実行しません。 これらのサーバー、SHOULD、1人以上の受取人のために「後の失敗」として失敗を扱い、セクション6で議論されるようなメイル・メッセージを返す。 データが受理された後、「見つからない550箱の郵便箱」(あるいは等価物)返答コードを使用することは、クライアントがどの受取人が失敗したか断定することを困難か不可能にします。 いつ、RFC 822フォーマット[7、32]使用されている、メイル・データは、デート、モルモットのようなメモ・ヘッダー・アイテムを含んでいます、に、Cc、から。 サーバーSMTP(Server SMTP)システム、SHOULD NOT、RFC 822あるいはMIME[12]メッセージヘッダーの知覚された欠陥あるいはメッセージ身体に基づいたメッセージを拒絶します。 Klensin基準(Klensin Standards)は特に[18ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、2001年、それら、MUST NOT、メッセージを拒絶する、どれの中で、数、フィールドに憤慨する、一致しない、あるいは憤慨するに、現われる、なしで、憤慨するから、または憤慨する―日付。 メイル・トランザクションは、MUSTが上に議論された順に使用されるように命じます。 3.4 アドレス修正(Address Correction)用フォワーディングあるいはアップデートする進める(Updating Forwarding)支援はアドレスを内側は統合し単純化するために最もしばしば要求されます、あるいはに比べて、ある企業、そして現在のものと人の先のアドレスをリンクするアドレスを設立するためにより頻繁でない。 メッセージ(送信器へのサーバー通知のない)の暗黙のフォワーディングはセキュリティか非開示目的のために、同時代のインターネットにおいて一般的です。 企業および「新しいアドレス」場合の両方では、情報を隠す(時々セキュリティ)考察が、フォワーディング活動の副作用としてSMTPプロトコルを通って「最終の」アドレスの発見に反対します。 最終アドレスが送信器によってさらに到達可能でないかもしれない場合、これは特に重要かもしれません。 従って、RFC 821のセクション3.2に記述された「フォワーディング」メカニズム、特に251(訂正された目的地)および551は、implementersによって、および形成するシステムによって(それらが利用可能な場合)RCPTからのコードが注意深く評価されるに違いないと返答します。 項目中で:それらがアドレス変更に気づいている場合、MAYが前にメッセージとして送る*サーバー。 それらがそうする場合、それら、MAY、アドレスを更新する情報に251本のコードを供給するか発送してもよい「暗黙に」また250本のコードを返します。 しかし251本のコードが使用される場合、それら、MUST NOT、クライアントが現実にアドレス情報あるいはリターンさえを更新するだろうと仮定する、ユーザへのその情報。 交互に、*サーバー、MAY、アドレスされた時、それらが引き渡せない場合、メッセージを拒絶するか弾ませます。 それらがそうする場合、それら、MAY、アドレスを更新する情報に551本のコードを供給するか、550本のコードで配達できないものとしてメッセージを拒絶してもよい、またアドレス特定の情報はない。 しかし551本のコードが使用される場合、それら、MUST NOT、クライアントが現実にアドレス情報あるいはリターンさえを更新するだろうと仮定する、ユーザへのその情報。 251および(または)551を支援するSMTPサーバーインプリメンテーションは、コードがそれらが生憎情報を示すだろうと結論を下すサイトがそれらの使用を不能にするか制限することができるように構成メカニズムを提供するように強く促進されると返答します。 Klensin基準(Klensin Standards)は、アドレス3.5.1概観SMTP(Overview SMTP)をデバッグするための2001年の3.5のコマンドがユーザー名を確認するかあるいはメーリング・リストの内容を得るコマンドを提供する[19ページ]RFC 2821単純メイル転送プロトコル4月を追跡します。 これはVRFYとEXPNのコマンドをやめます。それは文字ストリング引き数を行っています。 インプリメンテーションSHOULD(Implementations SHOULD)支援VRFY、およびEXPN(しかしながら、セクション3.5.2および7.3を参照)。 VRFYコマンドについては、ストリングがユーザー名あるいはユーザー名および領域です(以下を参照)。 正常な(つまり250)レスポンスが返される場合、レスポンスMAY、ユーザおよびMUSTの姓名を含んでいる、ユーザの郵便箱を含んでいます。 それ、MUST、次の形式のどちらかの中に次のとおりである:VRFYへの引き数である名前が1箱を越える郵便箱を識別することができた場合、ユーザー・ネーム<ローカルの部分@領域>ローカルの部分@領域、サーバーMAY、曖昧さに注意するか、代案を識別する。 言いかえれば、下記のうちのいかなるものでもVRFYに対する正当なレスポンスです:553人の曖昧なユーザあるいは553-、曖昧; 可能性は553-ジョー・スミス553-ハリー・スミス553メルビンです、あるいは553-曖昧; 可能性553-553-553 正常な環境の下では、553の返答を受け取るクライアントがユーザに結果を暴露すると予想されるでしょう。 使用、正確に与えられた形式および「曖昧なユーザ」あるいは「曖昧な」キーワード、恐らくそれらのような拡張返答コードで補われた[34]に記述した、求められるような他の言語の中への自動翻訳を促進するでしょう。 もちろん、クライアント、それ、高度に自動化された、あるいはそれ、英語より別の言語で作動していた、レスポンスを翻訳しようとすることに決めてもよい、Klensin基準(Klensin Standards)よりユーザへの他のある表示を返すために[20ページ]RFC 2821単純メイル転送プロトコル4月を追跡する、返答の2001年のリテラル・テキスト、あるいはユーザに報告する前の補足情報のためのディレクトリー・サービスを調べるようなある自動処置を講ずるために EXPNコマンドについては、ストリングがメーリング・リスト、および成功した(つまり250)マルチラインレスポンスMAYを識別します、ユーザおよびMUSTの姓名を含んでいる、メーリング・リスト上の郵便箱を与えます。 何人かのホストでは、共通のデータ構造が両方のタイプのエントリーを保持してもよいので、単一の郵便箱用のメーリング・リストと別名の相違が、少し曖昧です。また、単に1箱の郵便箱を含んでいるメーリング・リストを持っていることは可能です。 リクエストがメーリング・リストにVRFYを適用するためになされる場合、肯定的なレスポンスMAY、メッセージがそのようにアドレスした場合、与えられる、リスト上の皆にそうでなければ配達されるだろう、エラーSHOULD、報告される(例えば、「550、それはメーリング・リストである、ない、ユーザ」「あるいは252、メーリング・リストのメンバーを確認するのにできない」)。 リクエストがユーザー名を拡張するためになされる場合、サーバーMAY、1つの名前を含んでいるリストから成る肯定的なレスポンスあるいはエラーMAYを返す、報告される(例えば、「550、それはユーザー名である、ない、メーリング・リスト」)。 成功したマルチライン返答(EXPNには正常)の場合には、ちょうど1箱の郵便箱が返答の各ライン上で指定されることになっています。 曖昧なリクエストの場合は上に議論されます。 「ユーザー・ネーム」は曖昧な用語で、慎重に使用されました。 VRFYのインプリメンテーションまたはEXPNのコマンドMUSTは、「ユーザー名」として少なくともローカルの郵便箱の認識を含んでいます。 しかしながら、現在のインターネット以来、練習は、しばしば多数の領域のための単一のホスト取り扱いメイルに帰着します、ホスト(特にこの機能性を提供するホスト)、SHOULD「ユーザー名」として「ローカルの部分@領域」形式を認める; ホスト、MAY、さらに他のストリングを「ユーザー名」と認めることに決めます。 郵便箱リストを拡張する場合は、次のもののように、マルチライン返答を要求します:C:EXPN例人々S(EXPN Example-People S):250-ジョンPostelS:250-フレッドFoneboneS:250のサムQ.スミスあるいはC:EXPN実行の洗面所リストS(EXPN Executive-Washroom-List S):あなたに与えられなかった550のアクセス。 Klensin基準(Klensin Standards)は[21ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、2001年、VRFYとEXPNのコマンドの文字ストリング引き数はさらにありえません、制限した、ユーザー名および郵便箱リスト概念のインプリメンテーションの種類により。 いくつかのシステム上に、それは、メーリング・リストを含んでいるファイルのファイル名である、EXPNコマンドの引き数に適切かもしれません。しかし、再び、様々なファイルはインターネット中で協定を指定しています。 同様に、これらのコマンドによって返されるものにおける歴史上の変化はそのようなものです、それ、レスポンスSHOULD、非常に注意深く解釈される、場合、いずれにしても、そしてSHOULD、一般に診断の目的のために単に使用されます。 正常な(2yzまたは551)レスポンスがVRFYまたはEXPNのリクエストから返される場合、3.5.2のVRFYノーマルレスポンス(VRFY Normal Response)、「領域」が完全に資格のあるドメインネームである場合、返答は通常郵便箱名(つまり<「ローカルの部分@領域」>)を含んでいます、MUST、シンタックスに現われます。 この明細の意図を破ることを正当化するために十分に例外的な環境中で、自由形式のテキストMAY、返されます。 コンピューターおよび人々の両方によって解析を促進するために、アドレス、SHOULD、とがっているブラケットに現われます。 アドレスが自由形式のデバッギング情報ではなく、返される場合、EXPNおよびVRFY MUSTはSMTP RCPTコマンドにおいて使用可能な有効な領域アドレスだけを返します。 従って、アドレスがプログラムあるいは他のシステムへの配達を意味する場合、郵便箱名はいつもその目標MUSTに達しました、与えられます。 パス(明示的な出所ルート)MUST NOT、VRFYまたはEXPNによって返されます。 サーバー・インプリメンテーションSHOULD支援、VRFYおよびEXPNの両方。 セキュリティ理由のために、インプリメンテーション、MAY、ローカルの装置に構成オプションあるいは等価物によってこれらのコマンドのどちらかあるいは両方を不能にする方法を供給します。 これらのコマンドが支援される場合、それらは中継が支援される場合に、リレーを横切って働くためには要求されません。 それらが両方ともRFC 821においてオプションだったので、それら、MUST、それらが支援される場合、EHLOレスポンスでサービス拡張としてリストされます。 VRFYの3.5.3の意味あるいはEXPN成功レスポンスA(EXPN Success Response A)サーバーMUST NOTは、250を返します、もしそれが現実にアドレスを確認していなければ、VRFYまたはEXPNのコマンドに応じてコード化します。 項目(サーバーMUST NOTリターン(それがやったのが与えられたシンタックスが有効であることを確認することである場合、)250)中で。 その場合に、502(インプリメントされないコマンド)あるいは500の(シンタックス・エラー、命令する、未承認)SHOULD、返されます。 他のところに述べられるように、VRFYのインプリメンテーション(現実にアドレスを有効にし、情報を返す感覚中の)、およびEXPNは、強く勧められます。 従って、VRFYのために500または502を返すインプリメンテーションはこの明細への十分な従順の中にありません。 Klensin基準(Klensin Standards)は[22ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、特にサーバーが別のサーバーあるいは領域のためのメイル交換器の役割をしている場合、2001はそこでアドレスが有効に見えますが、リアル・タイムにおいて合理的に確認することができない環境かもしれません。 「明白な有効性」は通常この場合シンタックスを少なくともチェックすることを含み、立証を含んでいるかもしれません、指定されたいかなる領域もホストがメイルを中継したつもりだったことができるいくつかのものでした。 これらの状況で、コード252 SHOULDを返答する、返されます。 これらの場合は、セクション2.1で議論されたRCPT立証の議論に平行します。 同様に、認識されますが、転送されるか、弾むアドレスがそれらのために受け取られたメイルだったことを示すために、セクション3.4の議論は、VRFY(またEXPN)を備えた、返答コード251および551の使用に当てはまります。 インプリメンテーション、一般にSHOULD、そうするのにもう少し長くかかってもRCPTよりVRFYの場合のアドレス立証に関してより積極的です。 EXPN EXPNの3.5.4のセマンティックスおよびアプリケーションは、メーリング・リストおよび複合の目標アドレス別名に関する問題のデバッグおよび理解において多くの場合非常に有用です。 いくつかのシステムは、複写を除去する手段としてメーリング・リストの出所拡張を使用することを試みました。 インターネット上の、ホスト(典型的にMXとCNAMEのDNSレコードを備えた)のための、郵便箱(様々なタイプのローカルのホスト別名)のための、および様々なproxyingする準備中のメイルを備えたaliasingシステムの宣伝、それを一貫して働くこれらの戦略およびメイル・システムSHOULD NOTには、ほとんど不可能にした、それらを試みます。 3.6 ドメインだけ、溶解性、完全に資格のある、ドメインネームがSMTPの中で使用される場合、ドメインネーム(FQDN)が許されます。 言いかえれば、MXまたはAのRRに、順番に目標が解決することができるCNAME RRであるとともに、MX RRあるいはA RR(セクション5で議論されたとともに)に解決することができる名前は、許されます。 ローカルの愛称あるいは無条件の名前MUST NOT、使用されています。 FQDNを要求する支配の2つの例外は次のとおりです:―EHLOコマンドMUST BEの中で与えられたドメインネーム、主要なホスト名(A RRになるドメインネーム)あるいはホストが名(セクション4.1.1.1に記述されるようなアドレス・リテラル)を持っていない場合。 ―予約の郵便箱名「郵便局長」は、領域資格(セクション4.1.1.3を参照)およびMUSTのないRCPTコマンドの中で使用されてもよい、使用されて、そうならば受理されます。 Klensin基準(Klensin Standards)は[23ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、一般にリレーする2001年3.7、ドメインネームシステム中のメイルeXchangerレコードの有効性[22、27]不必要なインターネットメール・システム中で明示的な出所ルートの使用を行ないます。 それらの解釈に関する多くの歴史上の問題はそれらの使用を不適当にしました。 SMTPクライアント、SHOULD NOT、異常な環境の下の場合以外は明示的な出所ルートを生成します。 メイル・リレーの役割をするかあるいは出所ルートを指定するアドレスを受理する、SMTPサーバーMAY下落。 ルート情報に遭遇する場合、SMTPサーバーはさらにルート情報を無視し、かつ単にルートの最後の要素およびSHOULDがそうするとともに指定された、最終目的地へ送ることを許されます。 任意の問題を解決するために敗走させる出所中で指定された中間宿主を当てにする送信器と共に、目的地名としてDNSに現われない名を使用する無効の練習がありました。 出所ルートが裸にされる場合、この練習は失敗を引き起こすでしょう。 これはいくつかの理由のうちの1つです、なぜSMTPクライアント、MUST NOT、無効の出所ルートを生成するか、名前の連続する解決に依存する。 出所ルートが使用されない場合、前方のパスから逆のパスを構築するためにRFC 821に記述されたプロセスは、適用可能ではありません。また、配達の時の逆のパスは単にMAILコマンドに現われたアドレスになるでしょう。 リレーSMTPサーバーは、最終の配達システムではなく、通常それを指定するDNS MXレコードの目標です。 リレー・サーバーは、それが地方のユーザのためのメイルを受理するか拒絶するのと同じ方法でメイルを中継するタスクを受理するか拒絶するかもしれません。 それは、それがタスクを受理する場合、SMTPクライアントになり、DNS(セクション5の規則による)の中で指定された、次のSMTPサーバーへの送信チャンネルを設立し、それにメイルを送ります。 それが政策理由のための特別のアドレスへのメイルを中継することを断わる場合、550のレスポンスSHOULD、返されます。 多くのメイルを送るクライアントは、特にPOP3あるいはIMAP(それは後の配達試みのためのメッセージをキューにする能力のようなこの明細の必要条件のうちのいくつかを支援する能力を制限した)によってメイルを受け取る設備と共に、存在します。 これらのクライアントについては、それが、処理および後の分配用の単一のサーバーへメッセージをすべて送る、個人の準備を行なう、共通の練習です。 SMTPは、理想的に、ここに指定されたとともに、この役割に適していません。また、仕事は、結局現在の練習に取って代わる標準化されたメイル・サブミッション・プロトコル上で進行中です。 どんな場合も、これらの準備が個人で、この明細の範囲の外部で落ちるので、それらはここに記述されません。 Klensin基準(Klensin Standards)は[24ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、2001年、MXが記録することに注目することは重要です、単なるSMTPリレーおよび最終の配達システムではなく他の環境へゲートウエイの役割をするSMTPサーバーを指すことができる; セクション3.8および5を参照してください。 SMTPサーバーがメイルおよび後の発見を中継するタスクを受理した場合、目的地は正しくないか、あるいは他のある理由、次にそのためにメイルを伝えることができません、MUST「配達できないメイル」通知メッセージを構築し、配達できないメイル(逆-パス-によって示されたとともに)の発明者のもとへそれを送る。 他の標準(例えば参照、[24、25])SHOULDによって非配達報告書のために指定されたフォーマット、可能な場合、使用されます。 この通知メッセージはリレー・ホストあるいはホストのSMTPサーバーからであるに違いありません、1位は、配達を遂行することができないことを決めます。 もちろん、SMTPサーバー、MUST NOT、通知メッセージを輸送する問題に関する通知メッセージを送信します。 エラー報告際にループを防ぐのに単向、通知メッセージのMAILコマンド中で無効の逆のパスを指定することです。 そのようなメッセージが送信される場合、逆のパスMUST、空(補足議論に関してはセクション4.5.5を参照)にセットされます。 無効の逆のパスを備えたMAILコマンドは以下のように現われます:MAIL FROM:<> セクション2.4.1で議論されるように、リレーSMTPはヘッダーで検査しないか作用する必要がない。あるいは、メッセージデータの身体およびMUST NOTはそれ自身のものが次のものを「受け取った」と付け加えること以外はそうします: ヘッダー(セクション4.4)そして、メイル・システム(セクション6.2を参照)中でループすることを検知することを試みるために自由に。 3.8 リレー機能が上に議論した間にGatewayingするメイルは、インターネットSMTP輸送業務環境内に作動します。あるいは、MXは記録します。あるいは、明示的な作業工程の様々な形式は、中間のSMTPサーバーが1つの輸送業務と別の輸送業務の間の翻訳機能を実行することを必要とするかもしれません。 そのようなシステムが2つの輸送業務環境間の境界にあるとき、セクション2.3.8で議論されるように、私たちはそれを「ゲートウエイ」あるいは「ゲートウエイSMTP」と呼びます。 異なるメイル・フォーマットのような異なるメイル環境とプロトコルの間のメイルをGatewayingすることは、複雑で、標準化に容易に産出しません。 しかしながら、いくつかの一般的な必要条件は、インターネットと別のメイル環境の間のゲートウエイのために与えられるかもしれません。 Klensin基準(Klensin Standards)は[25ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、ヘッダー・フィールドMAYをGatewayingすることの中の2001年の3.8.1のヘッダーのフィールド、必要な場合、書き直される、メッセージがメイル環境境界を横切ってgatewayedされるとともに。 これはメッセージ身体を検査するかセクション2.4.1の禁止にもかかわらず終点アドレスのローカルの部分を解釈することを含んでいるかもしれません。 インターネットにgatewayedされた他のメイル・システムは、しばしばRFC 822ヘッダーの部分集合を使用するか類似した機能性に異なるシンタックスを供給します。しかし、これらのメイル・システムのうちのいくつかはSMTP封筒に対して等価物を持っていません。 したがって、メッセージがインターネット環境を残す場合、SMTP封筒情報をメッセージヘッダーに混ぜ込むことは必要かもしれません。 可能なソルーションは封筒情報(例えば「X-SMTP-MAIL」:そして「X-SMTP-RCPT」)を伝えるために新しいヘッダー・フィールドを作ることでしょう; しかしながら、これは、外国の環境中のメイル・プログラムの変化を要求し、個人の情報の開示を危くしてもよい(セクション7.2を参照)。 インターネット環境へ、あるいはその環境からメッセージを転送する場合にGatewayingすることの中の3.8.2行の受信ライン(Received Lines)、ゲートウエイMUST prepend、1つの、受け取られた:ライン、しかしそれ、MUST NOT、任意の方法で変わる、1つの、受け取られた:既にヘッダーの中にあるライン。 「受け取った:」 他の環境から起こるメッセージのフィールドは、この明細に正確に一致しないかもしれません。 しかしながら、最も重要な使用、受け取られた:ライン、メイル欠点のデバッグおよびこのデバッギングのためにある、厳しく「固定しよう」とする善意のゲートウエイによって妨げることができる、1つの、受け取られた:ライン。 跡フィールドの別の結果として、非SMTP環境中で発生すること、受信システム、MUST NOT、跡フィールドおよびSHOULDのフォーマットに基づいたメイルを拒絶する、それらの分野での予期しない情報あるいはフォーマットに照らして非常に強健です。 ゲートウエイSHOULD、環境およびプロトコルを示す、の中で、その「によって」それが供給する受信フィールド(s)の節。 インターネットサイドからGatewayingすることの中の3.8.3のアドレス、ゲートウエイSHOULD受理すべて、SMTPコマンド中の、およびRFC 822ヘッダーおよびすべての有効なRFC 822メッセージ中の有効なアドレス・フォーマット。 アドレスおよびゲートウエイMUSTによって生成されたヘッダーは、適用可能なインターネット基準(このおよびRFC 822を含んで)に一致します。 ゲートウェイは、それらがセクション3.3に他のSMTPシステムのために記述するとともに、出所ルートを扱うための同じ規則にもちろん従います。 Klensin基準(Klensin Standards)は[26ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、ゲートウエイMUSTをGatewayingすることの中の他のヘッダー・フィールド(Header Fields)が保証する2001年3.8.4、それ、メッセージのすべてのヘッダー・フィールド、それ、それ、インターネットメール環境へ前方へ、インターネットメール用の必要条件を満たします。 項目中で、すべてのアドレス、の中で「次のものから」「次のものに」、「Cc。」など、フィールドMUST、RFC 822シンタックスを満たすために変形される(必要ならば)、MUST参照のみ、完全に資格のあるドメインネーム、そしてMUST、返答を送ることには有効で有用です。 翻訳アルゴリズムはいつもメイルをインターネットプロトコルから別の環境のプロトコルSHOULDに変換しました、外国郵便環境からのエラー・メッセージがSMTP封筒からリターン・パスにリストされた送信器に、送られないことを保証する、その「から」: RFC 822メッセージのフィールド(あるいは他のフィールド)。 同様にGatewayingすることの中の3.8.5枚の封筒、インターネット(ゲートウエイSHOULD)へ別の環境からのメッセージを転送する場合、もし外国の環境によって供給されればエラー・メッセージ戻りアドレスに従って封筒リターン・パスをセットします。 外国の環境が等価な概念を持っていない場合、ゲートウエイは、最後の手段のデフォルトとしてのメッセージ発明者のアドレスと共に、最良の近似を選択し使用するに違いない。 3.9 セッションと接続の終了、クライアントがQUITコマンドを送る場合、SMTP接続は終了します。 サーバーは、肯定的な返答コード(それはそれの後に接続を閉じる)で答えます。 SMTPサーバーMUST NOT、故意に次のもの以外の接続を閉じる―QUITコマンドを受け取り、221の返答で答える後。 ― SMTPサービスをシャット・ダウンする必要を検知し、421本のレスポンス・コードを返した後に。 サーバーが任意のコマンドを受け取った後、このレスポンス・コードは出すことができます、あるいは必要ならば、コマンド受取(クライアントが後にそれを受け取るだろうという仮定上で、次のコマンドは出されます)から非同期に。 理解されないコマンドに応じて接続を閉じるサーバーは、特にこの明細に違反してあります。 サーバーが、500の返答を出しかつ、クライアントからの一層の指示を待って、未知のコマンドに寛容であると予想されます。 Klensin基準(Klensin Standards)は[27ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、2001年、出る前にSMTPクライアントにラインに421本のレスポンス・コードを含ませている、外部手段SHOULD試みによって、強制的にシャット・ダウンされるSMTPサーバー。 SMTPクライアントは、その次のコマンドを送った後に通常421本のレスポンス・コードを読むでしょう。 接続を接近して経験するSMTPクライアントはリセットします、あるいは他のコミュニケーション、それらのコントロール(この明細の意図のバイオレーション中の、だが時々、避けられない)SHOULDの下のではない環境による失敗、メイル・システムの強健さを維持し、あたかも451のレスポンスが受け取られたかのように、メイル・トランザクションを扱い、かつ従って作用するために。 3.10 メーリング・リスト、および別名、SMTP対応のホストSHOULD、別名、および複合の配達用のアドレス拡張のリスト・モデルの両方を支援します。 メッセージが拡張したリスト形式の各アドレスに配達されるか転送される場合、封筒(「MAIL FROM」:)MUSTの中の戻りアドレス、リストを処理する人あるいは他の実体のアドレスであるために変更されます。 しかしながら、この場合、メッセージヘッダー[32]MUST、変更されない; 項目中で、その「から」メッセージヘッダーのフィールドは影響されません。 重要なメイル設備は、偽りの郵便箱アドレスを目的地郵便箱アドレスのリストに変形すること(あるいは、「拡大する」こと、「爆発する」)により、単一のメッセージのマルチ目的地配達用のメカニズムです。 メッセージが、そのような偽りの郵便箱(時々「起爆装置」と呼んだ)に送信される場合、コピーは拡張したリスト中の各郵便箱へ転送されるか再分配されます。 サーバー、SHOULD、単にリスト上のアドレスを利用する; ヒューリスティックスあるいは発明者のそのようないくつかのアドレスを除去する、他の一致する規則のアプリケーションは、強く落胆します。 私たちは分類します、そのような、1つの、偽り-郵便箱、として、1つの「別名」あるいは拡張規則に依存する「リスト。」 別名を拡張する3.10.1の別名、受取人差し出し人は単に交換します、その、偽り-拡張したアドレスの各々を備えた封筒中の郵便箱アドレス、順番に; 封筒およびメッセージ身体の残りは変更されません。 その後、メッセージは各拡張したアドレスに配達されるか転送されます。 3.10.2はAメーリング・リストをリストします「フォワーディング」によってではなく「再配送」によって作動すると言えてもよい。 リストを拡張するために、受取人差し出し人は、拡張したKlensin基準(Klensin Standards)のすべてに封筒中の偽りの郵便箱アドレスを取り替えます[28ページ]RFC 2821単純メイル転送プロトコル4月を追跡する、2001のアドレス。 最終配達によって生成されたエラー・メッセージがすべて、メッセージ発明者(この人はリストの内容に対する管理を一般に行っておらず、典型的にエラー・メッセージをうるさく感じる)にではなくリスト管理者に返されるように、封筒中の戻りアドレスが変更されます。 4. SMTP仕様書(SMTP Specifications)4.1 SMTPコマンド(SMTP Commands)SMTPコマンドが定義する4.1.1のコマンドセマンティックス(Command Semantics)、およびシンタックス、ユーザによって要求されたメール転送あるいはメイル・システム機能。 SMTPコマンドはによって終了した文字ストリングです。 コマンドはそれら自身そうでなければパラメーターが続く場合にによって終了したアルファベットの特徴およびです。 (改善された相互運用のために、SMTPレシーバーは終了するの前に余白を引きずることを許容するように激励されます。) 郵便箱のローカルの部分のシンタックスは、レシーバー・サイト協定およびセクション4.1.2に指定されたシンタックスに順応するに違いありません。 SMTPコマンドは下に議論されます。 SMTP返答はセクション4.2で議論されます。 メイル・トランザクションは、引き数として異なるコマンドに伝えられるいくつかのデータ・オブジェクトを含んでいます。 逆のパスはMAILコマンドの引き数です。前方のパスはRCPTコマンドの引き数です。また、メイル・データはDATAコマンドの引き数です。 これらの引き数またはデータのオブジェクトは、トランザクションを終了させるメイル・データ表示の終了までに通信された確認を保留にして送信され保持されるに違いない。 このためのモデルは、データ・オブジェクトのタイプを保持するために、別個のバッファーが提供されるということです、すなわち、逆のパスバッファーがあります、前方のパスバッファー、またメイル・データ・バッファー。 情報は特定のバッファーに特定のコマンドによってアペンドされるか、あるいは1つ以上のバッファーにクリアーさせます。 いくつかのコマンド(RSET、DATA、QUIT)はパラメーターを許さないこととして指定されます。 特定の拡張の欠如中で、サーバーによって提示された、またクライアントによって受理された、クライアント、MUST NOT、そのようなパラメーターおよびサーバーを送る、SHOULD、コマンドを拒絶する、無効のシンタックスを持っていることとしてそれらを含んでいること 4.1.1.1の拡張HELLO(Extended HELLO)(EHLO)あるいはHELLO(HELO)これらのコマンドはSMTPサーバーへのSMTPクライアントを識別するために使用されます。 1つが利用可能な場合、引き数フィールドは、SMTPクライアントの完全に資格を与えられたドメインネームを含んでいます。 状況で、その中でSMTPクライアント・システムは意味のあるドメインネーム(例えば、そのアドレスがダイナミックに割り付けられ、逆写像レコードがKlensinでない場合、標準は[29ページ]RFC 2821単純メイル転送プロトコル4月を追跡します、2001年、利用可能)を持っていません、クライアントSHOULD、クライアント・システムを識別することを支援する情報を自由に後に続けて、アドレス・リテラル(セクション4.1.3を参照)を送ります。 接続挨拶返答中の、およびこのコマンドに対するレスポンス中のSMTPクライアントにSMTPサーバーがそれ自体識別するy。 クライアントSMTP SHOULD、EHLOコマンドを出すことによりSMTPセッションを始めます。 SMTPサーバーがSMTPサービス拡張を支援する場合、それは成功したレスポンス、失敗レスポンスあるいはエラー・レスポンスを与えるでしょう。 SMTPサーバーがこの明細のバイオレーション中で、SMTPサービス拡張を支援しない場合、それはエラー・レスポンスを生成するでしょう。 より古いクライアントSMTPシステムMAY、上に議論されたとともに、EHLOの代わりにHELO(RFC 821の中で指定されたとともに)、およびサーバーMUSTを使用する、HELOコマンドを支援し、それに適切に答える。 どんな場合も、クライアントMUST問題HELOあるいはメイル・トランザクションを始める前のEHLO。 これらのコマンド、そして1つの「250、よろしい」それらのうちの1つに答える、SMTPクライアントおよびSMTPサーバーの両方が初期の状態であると確認する、すなわち、進行およびすべての州テーブル中のトランザクションおよびバッファーはありません、クリアーされます。 シンタックス:ehlo=「EHLO」SPドメインCRLF(SP Domain CRLF)helo=「HELO」SPドメインCRLF(SP Domain CRLF)通常は、EHLOに対するレスポンスはマルチライン返答になるでしょう。 レスポンスの各ラインはキーワードおよび自由に1つ以上のパラメーターを含んでいます。 マルチライン返答用の正常なシンタックスに続いて、これらのkeyworksは、最後のラインおよびコード以外用のコード(250)、およびハイフンに続きます、また最後のラインのためのスペース。 肯定的なレスポンス用のシンタックス、ABNF記法およびターミナルのシンボルの使用、の[8]、次のとおりである:ehlo-ok-rsp=(「250」領域[SP、ehlo-挨拶する]CRLF)/(""領域[SP、ehlo-挨拶する]CRLF*(""ehlo-ラインCRLF)「250」SP ehlo-ラインCRLF)=1*(%d0-9/%d11-12/%d14 CRあるいはLF ehlo-ライン=ehlo-キーワード*(SP ehlo-param)ehlo-キーワード=(ALPHA/DIGIT)*(ALPHA、/DIGIT、/」)以外の任意の特徴のストリング;(") ehlo-paramsの補足シンタックスは依存し続けます; ehlo-キーワードKlensin基準(Klensin Standards)は追跡します[30ページ]RFC 2821単純メイル転送プロトコル4月の2001 ehlo-param=1*(%d33-127); およびすべて以外の任意のCHAR; コントロール文字(米国-ASCII(US-ASCII)0-31、包括的) EHLOキーワードは指定されるかもしれませんが、上部、低く、あるいはケースを混合した、それら、MUST、常にケース-無感覚な方法-に認識され処理される。 これは単にRFC 821およびセクション2.4.1の中で指定された練習の拡張です。 4.1.1.2のMAIL(MAIL) このコマンドは1箱以上の郵便箱にそれを配達するかもしれないか(順番に)、別のシステム(恐らくSMTPを使用して)へそれを通過するかもしれないSMTPサーバーにメイル・データが配達されるメイル・トランザクションを始めるために使用されます。 引き数フィールドは逆のパスを含んでおり、オプションのパラメーターを含んでいるかもしれません。 一般に、メイル・トランザクションが進行中でない場合に限り、MAILコマンドは送られるかもしれません、セクション4.1.4を見ます。 逆のパスは送信器郵便箱から成ります。 歴史上、ホストのリストは自由にその郵便箱に先行したかもしれません。しかし、その振る舞いは今大いに非難されます(付録Cを参照)。 返答がメイル・ループ(例えば、配達と不配の通知を郵送する)を引き起こす、いくつかのタイプの報告するメッセージでは、逆のパスが無効かもしれません(セクション3.7を参照)。 このコマンドは逆のパスバッファー、前方のパスバッファーおよびメイル・データ・バッファーをクリアーします; そして、逆のパスバッファーにこのコマンドからの逆のパス情報を挿入します。 サービス拡張が協定された場合、MAILコマンドはさらに特別のサービス拡張に関連したパラメーターを運ぶかもしれません。 シンタックス:「MAIL FROM」: [メイル(SP)パラメーター] (「<>」/逆パス(Reverse-Path))CRLF 4.1.1.3 RECIPIENT(RCPT) このコマンドはメイル・データの個々の受取人を識別するために使用されます; 多数の受取人はこのコマンドの複合の使用によって指定されます。 引き数フィールドは前方のパスを含んでおり、オプションのパラメーターを含んでいるかもしれません。 前方のパスは、通常要求された目的地郵便箱から成ります。 送るシステムSHOULD、ない、出所ルートとして知られているホストのオプションのリストを生成します。 システムMUSTを受け取って、Klensin基準(Klensin Standards)が2001年の出所ルート・シンタックスだがSHOULDが出所ルート明細をとり、あたかも出所ルートが提供されなかったかのように郵便箱に関連したドメインネームを利用する[31ページ]RFC 2821単純メイル転送プロトコル4月を追跡することを認識してください。 同様に、リレー・ホストSHOULD一片、あるいは出所ルートおよび名前MUST NOTを無視する、逆のパスにコピーされます。 メイルがその最終の目的地(前方のパスは目的地郵便箱だけを含んでいます)に到着する場合、SMTPサーバーがそのホスト・メイル協定に従って目的地郵便箱にそれを挿入します。 例えば、封筒を備えたリレー・ホストxyz.comで受け取られたメイルはMAIL FROM:RCPT TO:<@hosta.int、および@jkl.org:userc@d.bar.org>通常封筒を備えたホストd.bar.orgの上へ直接送られるだろう、MAIL FROM:RCPT TO: 付録Cの中で提供されたとともに、xyz.com MAY、さらにhosta.intへのメッセージを中継することに決める、封筒の使用はMAIL FROM:RCPT TO:<@hosta.int(@jkl.org):userc@d.bar.org>あるいは、jkl.orgに、封筒の使用はMAIL FROM:RCPT TO:<@jkl.org:userc@d.bar.org> もちろん、ホストがいずれにしてもメイルを中継することは要求されないので、完全に、550本のコード(これ以来、「政策理由」があります)を使用して、RCPTコマンドが受け取られる場合、xyz.comがさらにメッセージを拒絶するかもしれません。 サービス拡張が協定された場合、RCPTコマンドはさらに、サーバーによって提示された特別のサービス拡張に関連したパラメーターを運ぶかもしれません。 それら以外のクライアントMUST NOT送信パラメーターはそのEHLOレスポンスで、サーバーによって提示されたサービス拡張と提携しました。