RFC2821 日本語訳
2821 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001. (Format: TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869, STD0010) (Obsoleted by RFC5321) (Updated by RFC5336) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Klensin, Editor Request for Comments: 2821 AT&T Laboratories Obsoletes: 821, 974, 1869 April 2001 Updates: 1123 Category: Standards Track
ワーキンググループJ.Klensin、コメントを求めるエディタ要求をネットワークでつないでください: 2821のAT&T研究所が以下を時代遅れにします。 821、974、1869 2001年4月は以下をアップデートします。 1123年のカテゴリ: 標準化過程
Simple Mail Transfer Protocol
シンプルメールトランスファプロトコル
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates and clarifies, but doesn't add new or change existing functionality of the following:
このドキュメントはインターネット電子メール輸送のための基本プロトコルの自己充足的な仕様です。 それは、以下の既存の機能性を統合するか、アップデートして、はっきりさせますが、新しく加えるか、または変えません:
- the original SMTP (Simple Mail Transfer Protocol) specification of
RFC 821 [30],
- RFC821[30]の当初のSMTP(シンプルメールトランスファプロトコル)仕様
- domain name system requirements and implications for mail
transport from RFC 1035 [22] and RFC 974 [27],
- メールのためのドメイン名システム要求と含意はRFCから1035[22]とRFC974[27]を輸送します。
- the clarifications and applicability statements in RFC 1123 [2],
and
- そしてRFC1123[2]の明確化と適用性証明。
- material drawn from the SMTP Extension mechanisms [19].
- SMTP Extensionメカニズム[19]から得られた材料。
It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the mail transport materials of RFC 1123). However, RFC 821 specifies some features that were not in significant use in the Internet by the mid-1990s and (in appendices) some additional transport models. Those sections are omitted here in the interest of clarity and brevity; readers needing them should refer to RFC 821.
それは、RFC821、RFC974を時代遅れにして、RFC1123(RFC1123のメール輸送の材料を取り替えます)をアップデートします。 しかしながら、RFC821は1990年代の半ばまでにインターネットで重要に使用中でなかったいくつかの特徴と何人かの(付録の)追加輸送モデルを指定します。 それらのセクションは明快と簡潔さのためにここで省略されます。 彼らを必要とする読者はRFC821を参照するべきです。
Klensin Standards Track [Page 1] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[1ページ]RFC2821
It also includes some additional material from RFC 1123 that required amplification. This material has been identified in multiple ways, mostly by tracking flaming on various lists and newsgroups and problems of unusual readings or interpretations that have appeared as the SMTP extensions have been deployed. Where this specification moves beyond consolidation and actually differs from earlier documents, it supersedes them technically as well as textually.
また、それは増幅を必要としたRFC1123からの何らかの追加材料を含んでいます。 この材料は複数の方法で特定されました、ほとんど様々なリスト、ニュースグループ、および珍しい読書の問題で燃えるような追跡かSMTP拡張子が配布されたとき現れた解釈で。 この仕様が強化を超えて移行して、実際に以前のドキュメントと異なっているところでは、それは技術的に原文にそれらに取って代わります。
Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a 'mail submission' protocol, as recommended for POP [3, 26] and IMAP [6]. Additional submission issues are discussed in RFC 2476 [15].
メール輸送と配送が議定書を作るとき、SMTPは設計されましたが、また、この仕様は'メール提案'プロトコルとして使用に重要な情報を含んでいます、POP[3、26]とIMAP[6]のために推薦されるように。 RFC2476[15]で追加服従問題について議論します。
Section 2.3 provides definitions of terms specific to this document. Except when the historical terminology is necessary for clarity, this document uses the current 'client' and 'server' terminology to identify the sending and receiving SMTP processes, respectively.
セクション2.3はこのドキュメントに特定の用語の定義を提供します。 歴史的な用語が明快に必要である時を除いて、このドキュメントは発信を特定するのに現在の'クライアント'と'サーバ'用語を使用します、そして、SMTPを受けるのはそれぞれ処理されます。
A companion document [32] discusses message headers, message bodies and formats and structures for them, and their relationship.
仲間ドキュメント[32]はメッセージヘッダー、それらのためのメッセージ本体と、形式と構造、およびそれらの関係について議論します。
Table of Contents
目次
1. Introduction .................................................. 4 2. The SMTP Model ................................................ 5 2.1 Basic Structure .............................................. 5 2.2 The Extension Model .......................................... 7 2.2.1 Background ................................................. 7 2.2.2 Definition and Registration of Extensions .................. 8 2.3 Terminology .................................................. 9 2.3.1 Mail Objects ............................................... 10 2.3.2 Senders and Receivers ...................................... 10 2.3.3 Mail Agents and Message Stores ............................. 10 2.3.4 Host ....................................................... 11 2.3.5 Domain ..................................................... 11 2.3.6 Buffer and State Table ..................................... 11 2.3.7 Lines ...................................................... 12 2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12 2.3.9 Message Content and Mail Data .............................. 13 2.3.10 Mailbox and Address ....................................... 13 2.3.11 Reply ..................................................... 13 2.4 General Syntax Principles and Transaction Model .............. 13 3. The SMTP Procedures: An Overview .............................. 15 3.1 Session Initiation ........................................... 15 3.2 Client Initiation ............................................ 16 3.3 Mail Transactions ............................................ 16 3.4 Forwarding for Address Correction or Updating ................ 19
1. 序論… 4 2. SMTPはモデル化します… 5 2.1 基本的な構造… 5 2.2 拡大モデル… 7 2.2 .1バックグラウンド… 7 2.2 .2 拡大の定義と登録… 8 2.3用語… 9 2.3 .1 オブジェクトを郵送してください… 10 2.3 .2台の送付者と受信機… 10 2.3 .3 エージェントとメッセージにストアを郵送してください… 10 2.3 .4 接待します。 11 2.3 .5ドメイン… 11 2.3 .6 テーブルをバッファリングして、述べてください… 11 2.3 .7 立ち並んでいます… 12 2.3 .8台の創始者、配送、リレー、およびゲートウェイシステム… 12 2.3 .9 メッセージ内容とメールデータ… 13 2.3 .10のメールボックスとアドレス… 13 2.3 .11 返答してください… 13 2.4の一般構文プリンシプルズとトランザクションはモデル化されます… 13 3. SMTP手順: 概要… 15 3.1 セッション開始… 15 3.2 クライアント開始… 16 3.3 トランザクションを郵送してください… 16 3.4 住所変更かアップデートのための推進… 19
Klensin Standards Track [Page 2] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[2ページ]RFC2821
3.5 Commands for Debugging Addresses ............................. 20 3.5.1 Overview ................................................... 20 3.5.2 VRFY Normal Response ....................................... 22 3.5.3 Meaning of VRFY or EXPN Success Response ................... 22 3.5.4 Semantics and Applications of EXPN ......................... 23 3.6 Domains ...................................................... 23 3.7 Relaying ..................................................... 24 3.8 Mail Gatewaying .............................................. 25 3.8.1 Header Fields in Gatewaying ................................ 26 3.8.2 Received Lines in Gatewaying ............................... 26 3.8.3 Addresses in Gatewaying .................................... 26 3.8.4 Other Header Fields in Gatewaying .......................... 27 3.8.5 Envelopes in Gatewaying .................................... 27 3.9 Terminating Sessions and Connections ......................... 27 3.10 Mailing Lists and Aliases ................................... 28 3.10.1 Alias ..................................................... 28 3.10.2 List ...................................................... 28 4. The SMTP Specifications ....................................... 29 4.1 SMTP Commands ................................................ 29 4.1.1 Command Semantics and Syntax ............................... 29 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) ................... 29 4.1.1.2 MAIL (MAIL) .............................................. 31 4.1.1.3 RECIPIENT (RCPT) ......................................... 31 4.1.1.4 DATA (DATA) .............................................. 33 4.1.1.5 RESET (RSET) ............................................. 34 4.1.1.6 VERIFY (VRFY) ............................................ 35 4.1.1.7 EXPAND (EXPN) ............................................ 35 4.1.1.8 HELP (HELP) .............................................. 35 4.1.1.9 NOOP (NOOP) .............................................. 35 4.1.1.10 QUIT (QUIT) ............................................. 36 4.1.2 Command Argument Syntax .................................... 36 4.1.3 Address Literals ........................................... 38 4.1.4 Order of Commands .......................................... 39 4.1.5 Private-use Commands ....................................... 40 4.2 SMTP Replies ................................................ 40 4.2.1 Reply Code Severities and Theory ........................... 42 4.2.2 Reply Codes by Function Groups ............................. 44 4.2.3 Reply Codes in Numeric Order .............................. 45 4.2.4 Reply Code 502 ............................................. 46 4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... 46 4.3 Sequencing of Commands and Replies ........................... 47 4.3.1 Sequencing Overview ........................................ 47 4.3.2 Command-Reply Sequences .................................... 48 4.4 Trace Information ............................................ 49 4.5 Additional Implementation Issues ............................. 53 4.5.1 Minimum Implementation ..................................... 53 4.5.2 Transparency ............................................... 53 4.5.3 Sizes and Timeouts ......................................... 54
3.5 デバッグアドレスのために、命令します… 20 3.5 .1概要… 20 3.5 .2 VRFYの通常の応答… 22 3.5 .3 VRFYかEXPN成功応答の意味… 22 3.5 .4 EXPNの意味論とアプリケーション… 23 3.6のドメイン… 23 3.7 リレーします。 24 3.8 Gatewayingに郵送してください… 25 3.8 .1 Gatewayingのヘッダー分野… 26 3.8 .2 Gatewayingの台詞を受けます… 26 3.8 .3 Gatewayingでは、扱います。 26 3.8 .4 Gatewayingの他のヘッダー分野… 27 3.8 Gatewayingの.5個の封筒… 27 3.9 セッションとコネクションズを終えます… 27 3.10のメーリングリストと別名… 28 3.10.1 アリア… 28 3.10.2 記載してください… 28 4. SMTP仕様… 29 4.1 SMTPは命令します… 29 4.1 .1 意味論と構文を命令してください… 29 4.1 .1 .1 こんにちは、(EHLO)か広げられて、こんにちは(HELO)… 29 4.1 .1 .2は(メール)を郵送します… 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 議論構文を命令してください… 36 4.1 .3 リテラルを扱ってください… 38 4.1 .4 コマンドの注文… 39 4.1 .5 私用は命令します… 40 4.2 SMTPは返答します… 40 4.2は厳しさと理論をコード化します.1が、返答する… 42 4.2 .2回答は機能でグループをコード化します… 44 4.2 .3 数値の回答コードは注文されます… 45 4.2 .4 回答コード502… 46 4.2 .5回答はデータとその後の<CRLFの後に><CRLF>をコード化します… 46 4.3 コマンドと回答の配列… 47 4.3 .1配列概要… 47 4.3 .2 コマンド回答系列… 48 4.4 情報をたどってください… 49 4.5 追加導入問題… 53 4.5 .1の最小の実装… 53 4.5 .2透明… 53 4.5 .3回のサイズとタイムアウト… 54
Klensin Standards Track [Page 3] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[3ページ]RFC2821
4.5.3.1 Size limits and minimums ................................. 54 4.5.3.2 Timeouts ................................................. 56 4.5.4 Retry Strategies ........................................... 57 4.5.4.1 Sending Strategy ......................................... 58 4.5.4.2 Receiving Strategy ....................................... 59 4.5.5 Messages with a null reverse-path .......................... 59 5. Address Resolution and Mail Handling .......................... 60 6. Problem Detection and Handling ................................ 62 6.1 Reliable Delivery and Replies by Email ....................... 62 6.2 Loop Detection ............................................... 63 6.3 Compensating for Irregularities .............................. 63 7. Security Considerations ....................................... 64 7.1 Mail Security and Spoofing ................................... 64 7.2 "Blind" Copies ............................................... 65 7.3 VRFY, EXPN, and Security ..................................... 65 7.4 Information Disclosure in Announcements ...................... 66 7.5 Information Disclosure in Trace Fields ....................... 66 7.6 Information Disclosure in Message Forwarding ................. 67 7.7 Scope of Operation of SMTP Servers ........................... 67 8. IANA Considerations ........................................... 67 9. References .................................................... 68 10. Editor's Address ............................................. 70 11. Acknowledgments .............................................. 70 Appendices ....................................................... 71 A. TCP Transport Service ......................................... 71 B. Generating SMTP Commands from RFC 822 Headers ................. 71 C. Source Routes ................................................. 72 D. Scenarios ..................................................... 73 E. Other Gateway Issues .......................................... 76 F. Deprecated Features of RFC 821 ................................ 76 Full Copyright Statement ......................................... 79
4.5.3.1 サイズ限界と最小限… 54 4.5 .3 .2回のタイムアウト… 56 4.5 .4 戦略を再試行してください… 57 4.5 .4 .1 戦略を送ります… 58 4.5 .4 .2 戦略を受けます… 59 4.5 逆経路であることでのヌル.5のメッセージ… 59 5. 解決を扱ってください、そして、取り扱いを郵送してください… 60 6. 問題検出と取り扱い… 62 6.1 メールによる信頼できる配信と回答… 62 6.2 検出を輪にしてください… 63 6.3 不規則を補います… 63 7. セキュリティ問題… 64 7.1 セキュリティとスプーフィングを郵送してください… 64 7.2「ブラインド」はコピーします… 65 7.3のVRFY、EXPN、およびセキュリティ… 65 7.4 発表における情報公開… 66 7.5 跡の分野での情報公開… 66 7.6 メッセージ推進における情報公開… 67 7.7 SMTPサーバの操作の範囲… 67 8. IANA問題… 67 9. 参照… 68 10. エディタのアドレス… 70 11. 承認… 70個の付録… 71 A.TCPはサービスを輸送します… 71 B. SMTPを生成するのはRFC822ヘッダーから命令します… 71 C.送信元経路… 72 D.シナリオ… 73 E. 他のゲートウェイ問題… 76 RFC821のF.の推奨しない特徴… 76 完全な著作権宣言文… 79
1. Introduction
1. 序論
The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.
シンプルメールトランスファプロトコル(SMTP)の目的は確かに効率的にメールを移すことです。
SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. While this document specifically discusses transport over TCP, other transports are possible. Appendices to RFC 821 describe some of them.
SMTPは特定のトランスミッションサブシステムから独立していて、高信頼の規則正しいデータストリーム・チャンネルだけを必要とします。 このドキュメントは明確にTCPの上の輸送について議論しますが、他の輸送は可能です。 RFC821への付録はそれらのいくつかについて説明します。
An important feature of SMTP is its capability to transport mail across networks, usually referred to as "SMTP mail relaying" (see section 3.8). A network consists of the mutually-TCP-accessible hosts on the public Internet, the mutually-TCP-accessible hosts on a firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN environment utilizing a non-TCP transport-level protocol. Using
SMTPの重要な特徴は通常、「SMTPメールリレー」と呼ばれたネットワークの向こう側にメールを輸送するその能力(セクション3.8を見る)です。 ネットワークが成る、互いにTCPアクセスしやすい、公共のインターネットのホスト、互いにTCPアクセスしやすい、ファイアウォールで孤立しているTCP/IPイントラネットのホスト、または非TCP輸送レベルプロトコルを利用するある他のLANかWAN環境におけるホスト。 使用
Klensin Standards Track [Page 4] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[4ページ]RFC2821
SMTP, a process can transfer mail to another process on the same network or to some other network via a relay or gateway process accessible to both networks.
SMTP、プロセスは両方のネットワークにアクセスしやすいリレーかゲートウェイプロセスを通して同じネットワークの別のプロセス、または、ある他のネットワークにメールを移すことができます。
In this way, a mail message may pass through a number of intermediate relay or gateway hosts on its path from sender to ultimate recipient. The Mail eXchanger mechanisms of the domain name system [22, 27] (and section 5 of this document) are used to identify the appropriate next-hop destination for a message being transported.
このように、メール・メッセージは経路を送付者から究極の受取人まで多くの中間的リレーかゲートウェイホストを通り抜けるかもしれません。 ドメイン名システム[22、27](そして、このドキュメントのセクション5)のメールeXchangerメカニズムは、輸送されるメッセージのために適切な次のホップの目的地を特定するのに使用されます。
2. The SMTP Model
2. SMTPモデル
2.1 Basic Structure
2.1 基本構造
The SMTP design can be pictured as:
以下としてSMTPデザインについて描写できます。
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server
+----------+ +----------+ +------+ | | | | | ユーザ| <-->、|、| SMTP| | +------+ | クライアント|コマンド/回答| サーバ| +------+ | SMTP| <、-、-、-、-、-、-、-、-、-、-、-、-、--、>| SMTP| +------+ | ファイル| <-->、|、| そして、メール| | <-->、| ファイル| |システム| | | | | |システム| +------+ +----------+ +----------+ +------+ SMTPクライアントSMTPサーバ
When an SMTP client has a message to transmit, it establishes a two- way transmission channel to an SMTP server. The responsibility of an SMTP client is to transfer mail messages to one or more SMTP servers, or report its failure to do so.
SMTPクライアントに伝わるメッセージがあるとき、それはトランスミッションがSMTPサーバーに向けられる2方法を確立します。SMTPクライアントの責任は、1つ以上のSMTPサーバーにメール・メッセージを移すか、またはそのがそうしないことを報告することです。
The means by which a mail message is presented to an SMTP client, and how that client determines the domain name(s) to which mail messages are to be transferred is a local matter, and is not addressed by this document. In some cases, the domain name(s) transferred to, or determined by, an SMTP client will identify the final destination(s) of the mail message. In other cases, common with SMTP clients associated with implementations of the POP [3, 26] or IMAP [6] protocols, or when the SMTP client is inside an isolated transport service environment, the domain name determined will identify an intermediate destination through which all mail messages are to be relayed. SMTP clients that transfer all traffic, regardless of the target domain names associated with the individual messages, or that do not maintain queues for retrying message transmissions that initially cannot be completed, may otherwise conform to this specification but are not considered fully-capable. Fully-capable SMTP implementations, including the relays used by these less capable
どれがSMTPクライアントにメール・メッセージを提示されるか、そして、そのクライアントが、わたるメール・メッセージがことであるドメイン名が地域にかかわる事柄であり、このドキュメントによって扱われないとどのように決心しているかによる手段。 ドメイン名は、いくつかの場合、SMTPクライアントがメール・メッセージの最終的な目的地を特定することを移したか、または決定しました。 他のPOP[3、26]の実装に関連しているSMTPクライアントかIMAP[6]プロトコルについて一般的なケースかそれともいつ、SMTPクライアントが孤立している輸送サービス環境にいるかとき、決定するドメイン名はリレーされるすべてのメール・メッセージがことである中間的目的地を特定するでしょう。 個々のメッセージに関連している目標ドメイン名にかかわらずすべてのトラフィックを移すか、またはそんなに初めはメッセージ送信を再試行するための待ち行列が終了できないと主張しないSMTPクライアントは、そうでなければ、この仕様に従うかもしれませんが、完全にできると考えられません。 これらでそれほどできなく使用されるリレーを含む完全にできるSMTP実装
Klensin Standards Track [Page 5] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[5ページ]RFC2821
ones, and their destinations, are expected to support all of the queuing, retrying, and alternate address functions discussed in this specification.
もの、およびそれらの目的地が列を作り、再試行、およびこの仕様で議論した代替アドレス機能のすべてをサポートすると予想されます。
The means by which an SMTP client, once it has determined a target domain name, determines the identity of an SMTP server to which a copy of a message is to be transferred, and then performs that transfer, is covered by this document. To effect a mail transfer to an SMTP server, an SMTP client establishes a two-way transmission channel to that SMTP server. An SMTP client determines the address of an appropriate host running an SMTP server by resolving a destination domain name to either an intermediate Mail eXchanger host or a final target host.
いったん目標ドメイン名を決定して、わたるメッセージのコピーがことであるSMTPサーバーのアイデンティティを決定して、次に、その転送を実行するとSMTPクライアントがこのドキュメントでカバーされている手段。 SMTPサーバーへの郵便為替に作用するように、SMTPクライアントは両用トランスミッションチャンネルをそのSMTPサーバーに確立します。SMTPクライアントは中間的メールeXchangerホストか最終的な目標ホストのどちらかに目的地ドメイン名を決議することによってSMTPサーバーを実行する適切なホストのアドレスを決定します。
An SMTP server may be either the ultimate destination or an intermediate "relay" (that is, it may assume the role of an SMTP client after receiving the message) or "gateway" (that is, it may transport the message further using some protocol other than SMTP). SMTP commands are generated by the SMTP client and sent to the SMTP server. SMTP replies are sent from the SMTP server to the SMTP client in response to the commands.
SMTPサーバーは、最終仕向地か中間的「リレー」(メッセージを受け取った後に、すなわち、それはSMTPクライアントの役割を引き受けるかもしれない)か「ゲートウェイ」のどちらかであるかもしれません(すなわち、それはさらにSMTP以外の何らかのプロトコルを使用することでメッセージを輸送するかもしれません)。 SMTPコマンドをSMTPクライアントは生成して、SMTPサーバーに送ります。コマンドに対応してSMTPサーバーからSMTPクライアントにSMTP回答を送ります。
In other words, message transfer can occur in a single connection between the original SMTP-sender and the final SMTP-recipient, or can occur in a series of hops through intermediary systems. In either case, a formal handoff of responsibility for the message occurs: the protocol requires that a server accept responsibility for either delivering a message or properly reporting the failure to do so.
言い換えれば、メッセージ転送は、オリジナルのSMTP-送付者と最終的なSMTP-受取人の間に単独結合で起こることができるか、または仲介者システムを通して一連のホップに起こることができます。どちらの場合ではも、メッセージへの責任の正式な移管は起こります: プロトコルは、サーバが伝言をもたらすか、または適切にそうしないことを報告することへの責任を引き受けるのを必要とします。
Once the transmission channel is established and initial handshaking completed, the SMTP client normally initiates a mail transaction. Such a transaction consists of a series of commands to specify the originator and destination of the mail and transmission of the message content (including any headers or other structure) itself. When the same message is sent to multiple recipients, this protocol encourages the transmission of only one copy of the data for all recipients at the same destination (or intermediate relay) host.
トランスミッションチャンネルがいったん完成した確立して初期のハンドシェイクになると、通常、SMTPクライアントはメールトランザクションを開始します。 そのようなトランザクションはメールの創始者と目的地を指定する一連のコマンドとメッセージ内容(どんなヘッダーや非重要構造も含んでいる)自体の伝達から成ります。 同じメッセージを複数の受取人に送るとき、このプロトコルは同じ目的地(または、中間的リレー)ホストのすべての受取人のためにデータのコピー1部だけのトランスミッションを奨励します。
The server responds to each command with a reply; replies may indicate that the command was accepted, that additional commands are expected, or that a temporary or permanent error condition exists. Commands specifying the sender or recipients may include server- permitted SMTP service extension requests as discussed in section 2.2. The dialog is purposely lock-step, one-at-a-time, although this can be modified by mutually-agreed extension requests such as command pipelining [13].
サーバは回答で各コマンドに反応します。 回答は、コマンドを受け入れたか、追加コマンドが予想されるか、または一時的であるか永久的なエラー条件が存在するのを示すかもしれません。 送付者か受取人を指定するコマンドはSMTPサービス拡大要求がセクション2.2で議論するように受入れられたサーバを含むかもしれません。 コマンド連続送信[13]などの相談ずくの拡大要求でこれを変更できますが、対話は一度に一つ、わざわざ堅苦しいです。
Klensin Standards Track [Page 6] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[6ページ]RFC2821
Once a given mail message has been transmitted, the client may either request that the connection be shut down or may initiate other mail transactions. In addition, an SMTP client may use a connection to an SMTP server for ancillary services such as verification of email addresses or retrieval of mailing list subscriber addresses.
与えられたメール・メッセージがいったん伝えられると、クライアントは、接続が止められるよう要求するか、または他のメールトランザクションを開始するかもしれません。 さらに、SMTPクライアントはEメールアドレスの検証かメーリングリスト加入者アドレスの検索などの付属のサービスにSMTPサーバーに接続を使用するかもしれません。
As suggested above, this protocol provides mechanisms for the transmission of mail. This transmission normally occurs directly from the sending user's host to the receiving user's host when the two hosts are connected to the same transport service. When they are not connected to the same transport service, transmission occurs via one or more relay SMTP servers. An intermediate host that acts as either an SMTP relay or as a gateway into some other transmission environment is usually selected through the use of the domain name service (DNS) Mail eXchanger mechanism.
上に示されるように、このプロトコルはメールの伝達にメカニズムを提供します。 2人のホストが同じ輸送サービスに接続されるとき、通常、このトランスミッションは直接送付ユーザのホストから受信ユーザのホストまで起こります。 それらが同じ輸送サービスに接続されないとき、トランスミッションは1つ以上のリレーSMTPプロトコルのサーバで起こります。 通常、SMTPリレーとして、または、ゲートウェイとしてある他のトランスミッション環境に務める中間的ホストはドメイン名サービス(DNS)メールeXchangerメカニズムの使用で選ばれます。
Usually, intermediate hosts are determined via the DNS MX record, not by explicit "source" routing (see section 5 and appendices C and F.2).
通常、中間的ホストは明白な「ソース」ルーティングで断固としているのではなく、DNS MX記録で断固としています(セクション5、付録C、およびF.2を見てください)。
2.2 The Extension Model
2.2 拡大モデル
2.2.1 Background
2.2.1 バックグラウンド
In an effort that started in 1990, approximately a decade after RFC 821 was completed, the protocol was modified with a "service extensions" model that permits the client and server to agree to utilize shared functionality beyond the original SMTP requirements. The SMTP extension mechanism defines a means whereby an extended SMTP client and server may recognize each other, and the server can inform the client as to the service extensions that it supports.
1990年に始まった取り組み、RFC821が完成した後におよそ10年間で、プロトコルはクライアントとサーバが、オリジナルのSMTP要件を超えて共有された機能性を利用するのに同意するのを可能にする「サービス拡大」モデルと共に変更されました。 SMTP拡張機能は拡張SMTPクライアントとサーバが互いを見分けるかもしれなくて、サーバがそれがサポートするサービス拡大に関してクライアントに知らせることができる手段を定義します。
Contemporary SMTP implementations MUST support the basic extension mechanisms. For instance, servers MUST support the EHLO command even if they do not implement any specific extensions and clients SHOULD preferentially utilize EHLO rather than HELO. (However, for compatibility with older conforming implementations, SMTP clients and servers MUST support the original HELO mechanisms as a fallback.) Unless the different characteristics of HELO must be identified for interoperability purposes, this document discusses only EHLO.
現代のSMTP実装は基本的な拡張機能をサポートしなければなりません。例えば、少しの特定の拡大も実装しなく、クライアントSHOULDが優先的にHELOよりむしろEHLOを利用しても、サーバは、EHLOがコマンドであるとサポートしなければなりません。 (しかしながら、より古い従うとの互換性のために、実装、SMTPクライアント、およびサーバは後退としてオリジナルのHELOメカニズムをサポートしなければなりません。) 相互運用性目的のためにHELOの異なった特性を特定してはいけないなら、このドキュメントはEHLOだけについて議論します。
SMTP is widely deployed and high-quality implementations have proven to be very robust. However, the Internet community now considers some services to be important that were not anticipated when the protocol was first designed. If support for those services is to be added, it must be done in a way that permits older implementations to continue working acceptably. The extension framework consists of:
SMTPは広く配布されます、そして、高品質な実装は非常に強健であると判明しました。 しかしながら、インターネット共同体は、現在、重要であるプロトコルが1番目であったときに予期されなかったいくつかのサービスが設計されていると考えます。 それらのサービスのサポートが加えることであるなら、より古い実装が、許容できて働き続けているのを許容する方法でそれをしなければなりません。 拡大フレームワークは以下から成ります。
Klensin Standards Track [Page 7] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[7ページ]RFC2821
- The SMTP command EHLO, superseding the earlier HELO,
- 以前のHELOに取って代わって、SMTPはEHLOを命令します。
- a registry of SMTP service extensions,
- SMTPサービス拡張子の登録
- additional parameters to the SMTP MAIL and RCPT commands, and
- そしてSMTP MAILとRCPTコマンドへの追加パラメタ。
- optional replacements for commands defined in this protocol, such
as for DATA in non-ASCII transmissions [33].
- このプロトコルで定義されたコマンド、非ASCII送信[33]におけるDATAなどの任意の交換。
SMTP's strength comes primarily from its simplicity. Experience with many protocols has shown that protocols with few options tend towards ubiquity, whereas protocols with many options tend towards obscurity.
SMTPの強さは主として簡単さから来ます。 多くのプロトコルの経験は、わずかなオプションがあるプロトコルは偏在の傾向があるのを示しましたが、多くのオプションがあるプロトコルは不鮮明の傾向があります。
Each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs. In many cases, the cost of extending the SMTP service will likely outweigh the benefit.
利益にかかわらず、実装、展開、および相互運用性コストに関して慎重にありとあらゆる拡大を精査しなければなりません。 多くの場合、SMTPサービスを広げる費用はおそらく利益より重いでしょう。
2.2.2 Definition and Registration of Extensions
2.2.2 拡大の定義と登録
The IANA maintains a registry of SMTP service extensions. A corresponding EHLO keyword value is associated with each extension. Each service extension registered with the IANA must be defined in a formal standards-track or IESG-approved experimental protocol document. The definition must include:
IANAはSMTPサービス拡張子の登録を維持します。 対応するEHLOキーワード価値は各拡大に関連しています。 正規の標準規格道かIESGによって承認された実験プロトコルドキュメントでIANAに示されたそれぞれのサービス拡大を定義しなければなりません。 定義は以下を含まなければなりません。
- the textual name of the SMTP service extension;
- SMTPサービス拡張子の原文の名前。
- the EHLO keyword value associated with the extension;
- 拡大に関連しているEHLOキーワード価値。
- the syntax and possible values of parameters associated with the
EHLO keyword value;
- EHLOキーワード価値に関連しているパラメタの構文と可能な値。
- any additional SMTP verbs associated with the extension
(additional verbs will usually be, but are not required to be, the
same as the EHLO keyword value);
- 拡大(追加動詞は、通常ありますが、EHLOキーワード価値として同じようにあるのに必要でない)に関連しているどんな追加SMTP動詞も。
- any new parameters the extension associates with the MAIL or RCPT
verbs;
- 拡大がメールかRCPT動詞に関連づけるどんな新しいパラメタも。
- a description of how support for the extension affects the
behavior of a server and client SMTP; and,
- 拡大のサポートがどうサーバとクライアントSMTPの動きに影響するかに関する記述。 そして
- the increment by which the extension is increasing the maximum
length of the commands MAIL and/or RCPT, over that specified in
this standard.
- 拡大がそれの上でコマンドのメール、そして/または、RCPTの最大の長さを増強している増分はこの規格で指定しました。
Klensin Standards Track [Page 8] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[8ページ]RFC2821
In addition, any EHLO keyword value starting with an upper or lower case "X" refers to a local SMTP service extension used exclusively through bilateral agreement. Keywords beginning with "X" MUST NOT be used in a registered service extension. Conversely, keyword values presented in the EHLO response that do not begin with "X" MUST correspond to a standard, standards-track, or IESG-approved experimental SMTP service extension registered with IANA. A conforming server MUST NOT offer non-"X"-prefixed keyword values that are not described in a registered extension.
さらに、上側の、または、低いケース「X」から始まるどんなEHLOキーワード価値も拡大が二国間条約を通して排他的に利用した地方のSMTPサービスについて言及します。 登録されたサービス拡大に「X」と共に始まるキーワードを使用してはいけません。 逆に、「X」と共に始まらないEHLO応答で提示されたキーワード値はIANAに示された規格、標準化過程、またはIESGによって承認された実験的なSMTPサービス拡張子に対応しなければなりません。 従うサーバは登録された拡大で説明されない非「X」前に置かれたキーワード値を提供してはいけません。
Additional verbs and parameter names are bound by the same rules as EHLO keywords; specifically, verbs beginning with "X" are local extensions that may not be registered or standardized. Conversely, verbs not beginning with "X" must always be registered.
追加動詞とパラメタ名はEHLOキーワードと同じ規則で縛られます。 明確に、「X」と共に始まる動詞は示されないかもしれないか、標準化されないかもしれない地方の拡大です。 逆に、いつも「X」と共に始まらない動詞を登録しなければなりません。
2.3 Terminology
2.3 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described below.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは以下で説明されるように本書では解釈されることであるべきですか?
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that
the definition is an absolute requirement of the specification.
1. This単語、「必要である」という用語または“SHALL"が、定義が仕様に関する絶対条件であることを意味しなければなりませんか?
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
2. This句でない、または句でない、「」、定義が仕様の絶対禁止であることを意味しなければならないでしょう。
3. SHOULD This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different
course.
3. 「推薦される」というSHOULD This単語、または形容詞が、特定の項目を無視する特定の事情の正当な理由が存在するかもしれないことを意味しますが、完全な含意を理解されて、異なったコースを選ぶ前に、慎重に熟慮しなければなりません。
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean
that there may exist valid reasons in particular circumstances
when the particular behavior is acceptable or even useful, but the
full implications should be understood and the case carefully
weighed before implementing any behavior described with this
label.
4. どんなThisも言葉で表さないか、または句が「推薦しなかった」SHOULDは、このラベルで説明されたどんな振舞いも実装する前にいつ特定の振舞いが許容できるか、または役に立ちさえしますが、完全な含意が理解されるべきであるか、そして、この件が慎重に熟慮した特定の事情の正当な理由が存在するかもしれないことを意味します。
5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because
a particular marketplace requires it or because the vendor feels
that it enhances the product while another vendor may omit the
same item. An implementation which does not include a particular
option MUST be prepared to interoperate with another
implementation which does include the option, though perhaps with
reduced functionality. In the same vein an implementation which
5. 項目は、This単語か、形容詞「任意で」、意地悪ですが、本当に、任意の状態でそうするかもしれません。 1つのベンダーが、特定の市場がそれを必要とするか、またはベンダーが、それが製品を高めると感じるので別のベンダーが同じ項目を省略しているかもしれない間、項目を含んでいるのを選ぶかもしれません。 オプションを含んでいる別の実装で共同利用するように特定のオプションを含んでいない実装を準備しなければなりません、恐らく減少している機能性で。 同じ流れの実装、どれ
Klensin Standards Track [Page 9] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[9ページ]RFC2821
does include a particular option MUST be prepared to interoperate
with another implementation which does not include the option
(except, of course, for the feature the option provides.)
特定のオプションがそうしなければならないインクルードはオプションを含んでいない別の実装で共同利用するように準備されますか?(オプションが提供する特徴のためにもちろん除いてください。)
2.3.1 Mail Objects
2.3.1 オブジェクトを郵送してください。
SMTP transports a mail object. A mail object contains an envelope and content.
SMTPはメールオブジェクトを輸送します。 メールオブジェクトは封筒と内容を含んでいます。
The SMTP envelope is sent as a series of SMTP protocol units (described in section 3). It consists of an originator address (to which error reports should be directed); one or more recipient addresses; and optional protocol extension material. Historically, variations on the recipient address specification command (RCPT TO) could be used to specify alternate delivery modes, such as immediate display; those variations have now been deprecated (see appendix F, section F.6).
SMTPのシリーズがユニット(セクション3で、説明される)について議定書の中で述べるとき、SMTP封筒を送ります。 それは創始者アドレス(エラー・レポートが向けられるべきである)から成ります。 1つ以上の受取人アドレス。 そして、任意のプロトコル拡大の材料。 歴史的に、代替配送モードを指定するのに受取人アドレス指定コマンド(RCPT TO)の変化を使用できました、即座のディスプレイなどのように。 それらの変化は現在、推奨しないです(付録F、セクションF.6を見てください)。
The SMTP content is sent in the SMTP DATA protocol unit and has two parts: the headers and the body. If the content conforms to other contemporary standards, the headers form a collection of field/value pairs structured as in the message format specification [32]; the body, if structured, is defined according to MIME [12]. The content is textual in nature, expressed using the US-ASCII repertoire [1]. Although SMTP extensions (such as "8BITMIME" [20]) may relax this restriction for the content body, the content headers are always encoded using the US-ASCII repertoire. A MIME extension [23] defines an algorithm for representing header values outside the US-ASCII repertoire, while still encoding them using the US-ASCII repertoire.
SMTP内容は、SMTP DATAプロトコルユニットで送られて、2つの部品を持っています: ヘッダーとボディー。 内容が他の現代の規格に従うなら、ヘッダーはメッセージ書式仕様[32]のように構造化された分野/値の組の収集を形成します。 構造化されるなら、MIME[12]に従って、ボディーは定義されます。 内容は米国-ASCIIレパートリー[1]を使用することで示された自然で原文です。 SMTP拡張子である、("8BITMIME"[20])としてのそのようなものは満足しているボディーのためのこの規制を緩和するかもしれなくて、満足しているヘッダーは、米国-ASCIIレパートリーを使用することでいつもコード化されます。 MIME拡大[23]は米国-ASCIIレパートリーを使用することでまだそれらをコード化している間、米国-ASCIIレパートリーの外でヘッダー値を表すためのアルゴリズムを定義します。
2.3.2 Senders and Receivers
2.3.2 送付者と受信機
In RFC 821, the two hosts participating in an SMTP transaction were described as the "SMTP-sender" and "SMTP-receiver". This document has been changed to reflect current industry terminology and hence refers to them as the "SMTP client" (or sometimes just "the client") and "SMTP server" (or just "the server"), respectively. Since a given host may act both as server and client in a relay situation, "receiver" and "sender" terminology is still used where needed for clarity.
RFC821では、SMTPトランザクションに参加する2人のホストが「SMTP-送付者」と「SMTP-受信機」として記述されました。 このドキュメントは、現在の産業用語を反映するために変えられて、したがって、それぞれ「SMTPクライアント」(または、まさしく時々「クライアント」)と「SMTPサーバー」(または、まさしく「サーバ」)とそれらを呼びます。 与えられたホストがサーバとクライアントとしてリレー状況で務めるかもしれないので、「受信機」と「送付者」用語は明快に必要であるところでまだ使用されています。
2.3.3 Mail Agents and Message Stores
2.3.3 メールエージェントとメッセージストア
Additional mail system terminology became common after RFC 821 was published and, where convenient, is used in this specification. In particular, SMTP servers and clients provide a mail transport service and therefore act as "Mail Transfer Agents" (MTAs). "Mail User Agents" (MUAs or UAs) are normally thought of as the sources and
RFC821が発行されて、この仕様で便利であるところで使用された後に追加メールシステム用語は一般的になりました。 SMTPサーバーとクライアントは、特に、メール輸送サービスを提供して、したがって、「メール配達エージェント」(MTAs)として務めます。 そして通常、「メール・ユーザー・エージェント」(MUAsかUAs)がソースとして考えられる。
Klensin Standards Track [Page 10] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[10ページ]RFC2821
targets of mail. At the source, an MUA might collect mail to be
transmitted from a user and hand it off to an MTA; the final
("delivery") MTA would be thought of as handing the mail off to an
MUA (or at least transferring responsibility to it, e.g., by
depositing the message in a "message store"). However, while these
terms are used with at least the appearance of great precision in
other environments, the implied boundaries between MUAs and MTAs
often do not accurately match common, and conforming, practices with
Internet mail. Hence, the reader should be cautious about inferring
the strong relationships and responsibilities that might be implied
if these terms were used elsewhere.
メールの目標。 ソースでは、MUAがユーザから伝えられて、それをMTAに渡すためにメールを集めるかもしれません。 最終的な(「配送」)MTAはメールをMUAに渡すと考えられるでしょう(それ、例えば、「メッセージ店」にメッセージを預けることによって責任を少なくとも移して)。 しかしながら、これらの用語は少なくとも他の環境における、かなりの精度の外観と共に使用されますが、MUAsとMTAsの間の暗示している境界はしばしば正確に一般的で、従っている習慣をインターネット・メールに合わせるというわけではありません。 したがって、読者はこれらの用語がほかの場所で使用されたなら強い関係と暗示するかもしれない責任を推論することに関して用心深いはずです。
2.3.4 Host
2.3.4 ホスト
For the purposes of this specification, a host is a computer system attached to the Internet (or, in some cases, to a private TCP/IP network) and supporting the SMTP protocol. Hosts are known by names (see "domain"); identifying them by numerical address is discouraged.
この仕様の目的において、ホストはインターネット(または私設のTCP/IPネットワークへのいくつかの場合で)とSMTPプロトコルをサポートすることへの添付のコンピュータ・システムです。 ホストは名前によって知られています(「ドメイン」を見てください)。 数字のアドレスでそれらを特定するのはお勧めできないです。
2.3.5 Domain
2.3.5 ドメイン
A domain (or domain name) consists of one or more dot-separated
components. These components ("labels" in DNS terminology [22]) are
restricted for SMTP purposes to consist of a sequence of letters,
digits, and hyphens drawn from the ASCII character set [1]. Domain
names are used as names of hosts and of other entities in the domain
name hierarchy. For example, a domain may refer to an alias (label
of a CNAME RR) or the label of Mail eXchanger records to be used to
deliver mail instead of representing a host name. See [22] and
section 5 of this specification.
ドメイン(または、ドメイン名)は1つ以上のドットで切り離されたコンポーネントから成ります。 これらのコンポーネント、(DNS用語[22])の「ラベル」は、SMTP目的がASCII文字の組[1]から得られた手紙、ケタ、およびハイフンの系列から成るように制限されます。 ドメイン名はホストと他の実体の名前としてドメイン名階層構造に使用されます。 例えば、ドメインは、ホスト名を表すことの代わりにメールを提供するのに使用されるために別名(CNAME RRのラベル)かメールeXchanger記録のラベルを示すかもしれません。 この仕様の[22]とセクション5を見てください。
The domain name, as described in this document and in [22], is the entire, fully-qualified name (often referred to as an "FQDN"). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction.
本書では説明されて[22]では、ドメイン名は全体です、完全に修飾された名前(しばしば"FQDN"と呼ばれます)。 FQDNフォームにないドメイン名はローカルの別名にすぎません。 ローカルの別名はどんなSMTPトランザクションにも現れてはいけません。
2.3.6 Buffer and State Table
2.3.6 バッファとステートテーブル
SMTP sessions are stateful, with both parties carefully maintaining a common view of the current state. In this document we model this state by a virtual "buffer" and a "state table" on the server which may be used by the client to, for example, "clear the buffer" or "reset the state table," causing the information in the buffer to be discarded and the state to be returned to some previous state.
双方が慎重に現状の共通認識を維持していて、SMTPセッションはstatefulです。 本書では私たちは例えば、「バッファをきれいにする」か、または「ステートテーブルをリセットすること」にクライアントによって使用されるかもしれないサーバで仮想の「バッファ」と「ステートテーブル」でこの状態をモデル化します、バッファの情報が捨てられることを引き起こして、状態が何らかの先に返されることを引き起こして。
Klensin Standards Track [Page 11] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[11ページ]RFC2821
2.3.7 Lines
2.3.7 線
SMTP commands and, unless altered by a service extension, message data, are transmitted in "lines". Lines consist of zero or more data characters terminated by the sequence ASCII character "CR" (hex value 0D) followed immediately by ASCII character "LF" (hex value 0A). This termination sequence is denoted as <CRLF> in this document. Conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator. Limits MAY be imposed on line lengths by servers (see section 4.5.3).
SMTPコマンドとどんなメッセージデータもサービス拡大で変更されない場合「系列」で送られません。 線がゼロから成ったか、またはすぐにASCII文字"LF"によって続かれた系列ASCII文字"CR"(十六進法値の0D)で、より多くのデータキャラクタが終わりました。(十六進法値の0A)。 この終止配列は<CRLF>として本書では指示されます。 実装を従わせるのは、系列ターミネータとしていかなる他のキャラクタかキャラクタシーケンスも見分けてはいけませんし、また生成してはいけません。 限界はサーバによって行長に課されるかもしれません(セクション4.5.3を見てください)。
In addition, the appearance of "bare" "CR" or "LF" characters in text (i.e., either without the other) has a long history of causing problems in mail implementations and applications that use the mail system as a tool. SMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a <CRLF> sequence.
さらに、テキスト(すなわち、どちらかもう片方のない)における、「むき出し」の"CR"か"LF"キャラクタの外観には、ツールとしてメールシステムを使用するメール実装とアプリケーションで問題を起こす長い歴史があります。 SMTPクライアント実装は、彼らが系列ターミネータとして意図する時を除いて、これらのキャラクタを伝えてはいけなくて、次に、上で示されるように単に<CRLF>系列としてそれらを伝えなければなりません。
2.3.8 Originator, Delivery, Relay, and Gateway Systems
2.3.8 創始者、配送、リレー、およびゲートウェイシステム
This specification makes a distinction among four types of SMTP systems, based on the role those systems play in transmitting electronic mail. An "originating" system (sometimes called an SMTP originator) introduces mail into the Internet or, more generally, into a transport service environment. A "delivery" SMTP system is one that receives mail from a transport service environment and passes it to a mail user agent or deposits it in a message store which a mail user agent is expected to subsequently access. A "relay" SMTP system (usually referred to just as a "relay") receives mail from an SMTP client and transmits it, without modification to the message data other than adding trace information, to another SMTP server for further relaying or for delivery.
この仕様は4つのタイプのSMTPシステムの中で区別をします、それらのシステムが電子メールを送る際に果たす役割に基づいて。 または、「起因する」システム(時々SMTP創始者と呼ばれる)がインターネットにメールを取り入れる、 より一般に、輸送サービス環境に。 「配送」SMTPシステムは、輸送サービス環境からメールを受け取るものであり、メールユーザエージェントにそれを渡すか、またはそれのaメールユーザエージェントが次にアクセサリーに予想されるメッセージ店にそれを預けます。 「リレー」SMTPシステム(通常、ちょうど「リレー」に言及される)は、SMTPクライアントからメールを受け取って、それを伝えます、トレース情報を加えるのを除いたメッセージデータへの変更なしで、一層のリレーか配送のための別のSMTPサーバーに。
A "gateway" SMTP system (usually referred to just as a "gateway") receives mail from a client system in one transport environment and transmits it to a server system in another transport environment. Differences in protocols or message semantics between the transport environments on either side of a gateway may require that the gateway system perform transformations to the message that are not permitted to SMTP relay systems. For the purposes of this specification, firewalls that rewrite addresses should be considered as gateways, even if SMTP is used on both sides of them (see [11]).
「ゲートウェイ」SMTPシステム(通常、ちょうど「ゲートウェイ」に言及される)は、クライアントシステムから1つの輸送環境でメールを受け取って、別の輸送環境でサーバシステムにそれを伝えます。 この仕様の目的のために、アドレスを書き直すファイアウォールはゲートウェイであるとみなされるべきです、SMTPがそれらの両側で使用されても。ゲートウェイのどちらかの側面のプロトコルの違いか輸送環境の間のメッセージ意味論が、ゲートウェイシステムがメッセージへのSMTPリレー方式に受入れられない変換を実行するのを必要とするかもしれません。([11])を見てください。
Klensin Standards Track [Page 12] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[12ページ]RFC2821
2.3.9 Message Content and Mail Data
2.3.9 メッセージ内容とメールデータ
The terms "message content" and "mail data" are used interchangeably in this document to describe the material transmitted after the DATA command is accepted and before the end of data indication is transmitted. Message content includes message headers and the possibly-structured message body. The MIME specification [12] provides the standard mechanisms for structured message bodies.
用語「メッセージ内容」と「メールデータ」は、DATAコマンドを受け入れた後とデータ指示の終わりを伝える前に伝える材料について説明するのに互換性を持って本書では使用されます。 メッセージ内容はメッセージヘッダーとことによると構造化されたメッセージ本体を含んでいます。 MIME仕様[12]は構造化されたメッセージ本体に標準のメカニズムを提供します。
2.3.10 Mailbox and Address
2.3.10 メールボックスとアドレス
As used in this specification, an "address" is a character string that identifies a user to whom mail will be sent or a location into which mail will be deposited. The term "mailbox" refers to that depository. The two terms are typically used interchangeably unless the distinction between the location in which mail is placed (the mailbox) and a reference to it (the address) is important. An address normally consists of user and domain specifications. The standard mailbox naming convention is defined to be "local- part@domain": contemporary usage permits a much broader set of applications than simple "user names". Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.
この仕様で使用されるように、「アドレス」はメールが送られるユーザかメールが預けられる位置を特定する文字列です。 「メールボックス」という用語はその貯蔵所について言及します。 メールが置かれる位置(メールボックス)とそれの参照(アドレス)の区別が重要でない場合、2つの用語が通常互換性を持って使用されます。 通常、アドレスはユーザとドメイン仕様から成ります。 一般的なメールボックス命名規則は「地方の part@domain 」になるように定義されます: 現代の用法は簡単な「ユーザ名」よりはるかに広いアプリケーションを可能にします。 その結果と、中間的ホストが、彼らを変更することによって輸送を最適化するのを試みたときの問題の長い歴史のため、地方の部分は、単にアドレスのドメイン部分で指定されたホストが、解釈されて、意味論を割り当てなければなりません。
2.3.11 Reply
2.3.11 回答
An SMTP reply is an acknowledgment (positive or negative) sent from receiver to sender via the transmission channel in response to a command. The general form of a reply is a numeric completion code (indicating failure or success) usually followed by a text string. The codes are for use by programs and the text is usually intended for human users. Recent work [34] has specified further structuring of the reply strings, including the use of supplemental and more specific completion codes.
SMTP回答はコマンドに対応したトランスミッションチャンネルで受信機から送付者に送られた承認(肯定しているか否定している)です。 回答の一般的なフォームは通常、テキスト文字列がいうことになった数値完了コード(失敗を示すか、成功)です。 プログラムによってコードは使用のためのものです、そして、通常、テキストは人間のユーザのために意図します。 近作[34]は回答ストリングの一層の構造を指定しました、補足の、そして、より特定の完了コードの使用を含んでいて。
2.4 General Syntax Principles and Transaction Model
2.4 一般構文原則とトランザクションモデル
SMTP commands and replies have a rigid syntax. All commands begin with a command verb. All Replies begin with a three digit numeric code. In some commands and replies, arguments MUST follow the verb or reply code. Some commands do not accept arguments (after the verb), and some reply codes are followed, sometimes optionally, by free form text. In both cases, where text appears, it is separated from the verb or reply code by a space character. Complete definitions of commands and replies appear in section 4.
SMTPコマンドと回答には、堅い構文があります。 すべてのコマンドがコマンド動詞で始まります。 すべてのRepliesが3ケタ数字コードで始まります。 いくつかのコマンドと回答では、議論は動詞か回答コードに従わなければなりません。 いくつかのコマンドは主張(動詞の後の)を受け入れません、そして、いくつかの回答コードが任意に時々従われています、自由形式テキストで。 どちらの場合も、テキストが現れるところに、それは間隔文字によって動詞か回答コードと切り離されます。 コマンドと回答の完全な定義はセクション4に現れます。
Klensin Standards Track [Page 13] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[13ページ]RFC2821
Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command and extension name keywords) are not case sensitive, with the sole exception in this specification of a mailbox local-part (SMTP Extensions may explicitly specify case-sensitive elements). That is, a command verb, an argument value other than a mailbox local-part, and free form text MAY be encoded in upper case, lower case, or any mixture of upper and lower case with no impact on its meaning. This is NOT true of a mailbox local-part. The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. Mailbox domains are not case sensitive. In particular, for some hosts the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.
動詞とパラメータ値(キーワードというRCPTコマンドと拡大名の例えば、「TO:」か「To:」)は大文字と小文字を区別していません、メールボックスの地方の部分のこの仕様による唯一の例外で(SMTP拡張子は明らかに大文字と小文字を区別する要素を指定するかもしれません)。 それはそうです、コマンド動詞、メールボックスの地方の部分以外のパラメータ値、そして、自由形式テキストが意味で大文字と小文字の大文字、小文字、またはどんな混合物の中にも影響なしでコード化されるかもしれません。 これはメールボックスの地方の部分に関して本当ではありません。 大文字と小文字を区別するとしてメールボックスの地方の部分を扱わなければなりません。 したがって、SMTP実装は、メールボックスの地方の部分に関するケースを保存するために注意されなければなりません。 メールボックスドメインは大文字と小文字を区別していません。 何人かのホストにとって、ユーザ「鍛冶屋」はユーザ「スミス」と特に、異なっています。 しかしながら、メールボックスの地方の部分のケース感度を利用するのは、相互運用性を妨害して、お勧めできないです。
A few SMTP servers, in violation of this specification (and RFC 821) require that command verbs be encoded by clients in upper case. Implementations MAY wish to employ this encoding to accommodate those servers.
いくつかのSMTPサーバー、これを違反して仕様(そして、RFC821)はコマンド動詞がコード化されるのを必要とします。大文字の中のクライアントで。 実装は、それらのサーバを収容するのにこのコード化を使いたがっているかもしれません。
The argument field consists of a variable length character string ending with the end of the line, i.e., with the character sequence <CRLF>. The receiver will take no action until this sequence is received.
議論分野は行の終わりで可変長文字列結末から成ります、すなわち、キャラクタシーケンス<CRLF>で。 この系列が受け取られているまで、受信機は行動を全く取らないでしょう。
The syntax for each command is shown with the discussion of that command. Common elements and parameters are shown in section 4.1.2.
各コマンドのための構文はそのコマンドの議論で示されます。 一般的な要素とパラメタはセクション4.1.2で見せられます。
Commands and replies are composed of characters from the ASCII
character set [1]. When the transport service provides an 8-bit byte
(octet) transmission channel, each 7-bit character is transmitted
right justified in an octet with the high order bit cleared to zero.
More specifically, the unextended SMTP service provides seven bit
transport only. An originating SMTP client which has not
successfully negotiated an appropriate extension with a particular
server MUST NOT transmit messages with information in the high-order
bit of octets. If such messages are transmitted in violation of this
rule, receiving SMTP servers MAY clear the high-order bit or reject
the message as invalid. In general, a relay SMTP SHOULD assume that
the message content it has received is valid and, assuming that the
envelope permits doing so, relay it without inspecting that content.
Of course, if the content is mislabeled and the data path cannot
accept the actual content, this may result in ultimate delivery of a
severely garbled message to the recipient. Delivery SMTP systems MAY
reject ("bounce") such messages rather than deliver them. No sending
SMTP system is permitted to send envelope commands in any character
コマンドと回答はASCII文字の組[1]からキャラクタで構成されます。 輸送サービスが8ビットのバイト(八重奏)トランスミッションチャンネルを提供するとき、それぞれの7ビットのキャラクタは高位のビットがゼロまできれいにされている八重奏で正当化された伝えられた権利です。 より明確に、unextended SMTPサービスは7ビットの輸送だけを提供します。 情報が八重奏の高位のビットにある状態で、首尾よく特定のサーバと適切な拡大を交渉していない起因しているSMTPクライアントはメッセージを送ってはいけません。 そのようなメッセージがこの規則を違反して送られるなら、SMTPサーバーを受け取るのは、高位のビットをきれいにするか、またはメッセージが無効であると拒絶するかもしれません。 その内容を点検しないで、一般に、リレーSMTP SHOULDはそれが受け取ったメッセージ内容が有効であると仮定して、封筒が、そうするのを可能にすると仮定して、それをリレーします。 もちろん、内容が間違ったレッテルを貼られて、データ経路が実際の内容を受け入れることができないなら、これは受取人への厳しく誤り伝えられたメッセージの究極の配送をもたらすかもしれません。 配送SMTPシステムはそれらを提供するよりむしろそのようなメッセージを拒絶するかもしれません(「弾みます」)。 送付SMTPシステムが全くどんなキャラクタでも封筒コマンドを送ることが許可されていません。
Klensin Standards Track [Page 14] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[14ページ]RFC2821
set other than US-ASCII; receiving systems SHOULD reject such commands, normally using "500 syntax error - invalid character" replies.
米国-ASCIIを除いて、セットしてください。 受電方式SHOULDはそのようなコマンド、通常使用している「500構文エラー--無効のキャラクタ」回答を拒絶します。
Eight-bit message content transmission MAY be requested of the server by a client using extended SMTP facilities, notably the "8BITMIME" extension [20]. 8BITMIME SHOULD be supported by SMTP servers. However, it MUST not be construed as authorization to transmit unrestricted eight bit material. 8BITMIME MUST NOT be requested by senders for material with the high bit on that is not in MIME format with an appropriate content-transfer encoding; servers MAY reject such messages.
8ビットのメッセージ内容送信はサーバについて拡張SMTP施設(著しく"8BITMIME"拡大[20])を使用しているクライアントによって要求されているかもしれません。 8BITMIME SHOULD、SMTPサーバーによってサポートされてください。 しかしながら、8ビットの無制限な材料を伝えるためにそれを承認に理解してはいけません。 8BITMIMEは高いビットがオンの適切な満足している転送がコード化されているMIME形式にはない材料のために送付者によって要求されていてはいけません。 サーバはそのようなメッセージを拒絶するかもしれません。
The metalinguistic notation used in this document corresponds to the "Augmented BNF" used in other Internet mail system documents. The reader who is not familiar with that syntax should consult the ABNF specification [8]. Metalanguage terms used in running text are surrounded by pointed brackets (e.g., <CRLF>) for clarity.
本書では使用されるmetalinguistic記法は他のインターネット・メールシステムドキュメントで使用される「増大しているBNF」に対応しています。 その構文に詳しくない読者はABNF仕様[8]に相談するべきです。 明快のための先鋭な括弧(例えば、<CRLF>)によって広告のための活字原稿で使用されるメタ言語用語は囲まれます。
3. The SMTP Procedures: An Overview
3. SMTP手順: 概要
This section contains descriptions of the procedures used in SMTP: session initiation, the mail transaction, forwarding mail, verifying mailbox names and expanding mailing lists, and the opening and closing exchanges. Comments on relaying, a note on mail domains, and a discussion of changing roles are included at the end of this section. Several complete scenarios are presented in appendix D.
このセクションはSMTPで用いられた手順の記述を含みます: セッション開始、メールボックス名と拡張メーリングリストについて確かめて、メールを転送するメールトランザクション、および初めの、そして、終わりの交換。 リレーのコメント、メール・ドメインに関する注、および役割を変える議論はこのセクションの端に含まれています。 いくつかの完全なシナリオが付録Dに提示されます。
3.1 Session Initiation
3.1 セッション開始
An SMTP session is initiated when a client opens a connection to a server and the server responds with an opening message.
クライアントがサーバに接続を開くと、SMTPセッションは開始されます、そして、サーバは初めのメッセージで反応します。
SMTP server implementations MAY include identification of their software and version information in the connection greeting reply after the 220 code, a practice that permits more efficient isolation and repair of any problems. Implementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns. While some systems also identify their contact point for mail problems, this is not a substitute for maintaining the required "postmaster" address (see section 4.5.1).
SMTPサーバー実装は220コードの後に接続挨拶回答における、それらのソフトウェアとバージョン情報の識別を含むかもしれません、どんな問題の、より効率的な分離と修理も可能にする習慣。実装は、安全上の配慮を引き起こすところでソフトウェアとバージョン発表を損傷するためにSMTPサーバーに備えるかもしれません。 また、いくつかのシステムがメール問題のためのそれらの接点を特定しますが、これは必要な「郵便局長」アドレスを維持する代用品(セクション4.5.1を見る)ではありません。
The SMTP protocol allows a server to formally reject a transaction while still allowing the initial connection as follows: a 554 response MAY be given in the initial connection opening message instead of the 220. A server taking this approach MUST still wait for the client to send a QUIT (see section 4.1.1.10) before closing the connection and SHOULD respond to any intervening commands with
SMTPプロトコルで、サーバはまだ以下の初期の接続を許している間、正式にトランザクションを拒絶できます: 220の代わりに初期の接続初めのメッセージで554応答を与えるかもしれません。 このアプローチを取るサーバが、クライアントがQUITを送るのをまだ待たなければならない、(接続とSHOULDを終える前の.10が)どんな介入しているコマンドにも応じるセクション4.1.1を見てください。
Klensin Standards Track [Page 15] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[15ページ]RFC2821
"503 bad sequence of commands". Since an attempt to make an SMTP connection to such a system is probably in error, a server returning a 554 response on connection opening SHOULD provide enough information in the reply text to facilitate debugging of the sending system.
「コマンドの503の悪い系列。」 以来、SMTP接続をそのようなシステムにする試みはたぶん誤り(デバッグするのを容易にするほど初めのSHOULDが回答テキストの情報を提供する送付システムの接続のときに554応答を返すサーバ)中です。
3.2 Client Initiation
3.2 クライアント開始
Once the server has sent the welcoming message and the client has received it, the client normally sends the EHLO command to the server, indicating the client's identity. In addition to opening the session, use of EHLO indicates that the client is able to process service extensions and requests that the server provide a list of the extensions it supports. Older SMTP systems which are unable to support service extensions and contemporary clients which do not require service extensions in the mail session being initiated, MAY use HELO instead of EHLO. Servers MUST NOT return the extended EHLO-style response to a HELO command. For a particular connection attempt, if the server returns a "command not recognized" response to EHLO, the client SHOULD be able to fall back and send HELO.
いったんサーバが歓迎メッセージを送って、クライアントがそれを受けると、通常、クライアントはEHLOコマンドをサーバに送ります、クライアントのアイデンティティを示して。 セッションを開くことに加えて、EHLOの使用は、クライアントがサービス拡大とサーバがそれがサポートする拡大のリストを提供するという要求を処理できるのを示します。 開始されるメールセッション、5月に修理するサービスが拡大であるとサポートすることができないシステムと現代のそうしないクライアントが拡大が必要であるより古いSMTPがEHLOの代わりにHELOを使用します。 サーバはHELOコマンドへの拡張EHLO-スタイル応答を返してはいけません。 特定の接続試みのために、サーバがEHLOへの「認識されなかったコマンド」応答を返すなら、クライアントSHOULDは後ろへ下がることができて、HELOを送ります。
In the EHLO command the host sending the command identifies itself; the command may be interpreted as saying "Hello, I am <domain>" (and, in the case of EHLO, "and I support service extension requests").
EHLOコマンドで、コマンドを送るホストは身元を明らかにします。 「こんにちは、私は<ドメイン>(EHLOの場合では、「そして、私は、サービス拡大が要求であるとサポートする」)である」と言いながら、コマンドが解釈されるかもしれません。
3.3 Mail Transactions
3.3 メールトランザクション
There are three steps to SMTP mail transactions. The transaction starts with a MAIL command which gives the sender identification. (In general, the MAIL command may be sent only when no mail transaction is in progress; see section 4.1.4.) A series of one or more RCPT commands follows giving the receiver information. Then a DATA command initiates transfer of the mail data and is terminated by the "end of mail" data indicator, which also confirms the transaction.
SMTPメールトランザクションへの3ステップがあります。 トランザクションは送付者識別を与えるメールコマンドから始まります。 (メールトランザクションが全く進行していないときだけ、一般に、メールコマンドを送るかもしれません; セクション4.1.4を見てください。) 一連の1つ以上のRCPTコマンドが、受信機情報を教えながら、続きます。 次に、DATAコマンドは、メールデータの転送を起こして、「メールの終わり」データインディケータによって終えられます。(また、それは、トランザクションを確認します)。
The first step in the procedure is the MAIL command.
手順による第一歩はメールコマンドです。
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
メールFROM:<の逆経路の>[パラメタを郵送しているSP<>]<CRLF>。
This command tells the SMTP-receiver that a new mail transaction is starting and to reset all its state tables and buffers, including any recipients or mail data. The <reverse-path> portion of the first or only argument contains the source mailbox (between "<" and ">" brackets), which can be used to report errors (see section 4.2 for a discussion of error reporting). If accepted, the SMTP server returns a 250 OK reply. If the mailbox specification is not acceptable for some reason, the server MUST return a reply indicating whether the
このコマンドは、新しいメールトランザクションが出かける、すべての州が見送るリセットとバッファにどんな受取人やメールデータも含めることであるとSMTP-受信機に言います。 1番目か議論だけの<の逆経路の>部分はソースメールボックス("<"と">"括弧の間の)を含んでいます(誤りが報告する議論に関してセクション4.2を見てください)。(誤りを報告するのにそれを使用できます)。 受け入れるなら、SMTPサーバーは250OK回答を返します。 メールボックス仕様がある理由で許容できないなら、サーバは回答表示を返さなければなりません。
Klensin Standards Track [Page 16] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[16ページ]RFC2821
failure is permanent (i.e., will occur again if the client tries to send the same address again) or temporary (i.e., the address might be accepted if the client tries again later). Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies.
失敗は、永久的であるか(すなわち、再び、クライアントが再び同じアドレスを送ろうとすると、起こるでしょう)、または一時的です(クライアントが後で再び試みるなら、すなわち、アドレスを受け入れるかもしれません)。 この要件の見かけの範囲にもかかわらず、逆経路の受容性が1つ以上のフォワードパス(RCPTコマンドにおける)を調べることができるまで決定していないかもしれない事情があります。 それらの場合では、サーバが合理的に、逆経路(250回答がある)を受け入れるかもしれなくて、次に、フォワードパスの後のレポート問題は、受け取られて、調べられます。 通常、失敗は550か553の回答を起こします。
Historically, the <reverse-path> can contain more than just a mailbox, however, contemporary systems SHOULD NOT use source routing (see appendix C).
歴史的に、<逆経路>はまさしくメールボックス以上を含むことができて、しかしながら、現代のシステムSHOULD NOTはソースルーティングを使用します(付録Cを見てください)。
The optional <mail-parameters> are associated with negotiated SMTP service extensions (see section 2.2).
任意の<メールパラメタ>は交渉されたSMTPサービス拡張子に関連しています(セクション2.2を見てください)。
The second step in the procedure is the RCPT command.
手順における第2ステップはRCPTコマンドです。
RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
RCPT TO:<フォワードパス>[SP<rcpt-パラメタ>]<CRLF>。
The first or only argument to this command includes a forward-path (normally a mailbox and domain, always surrounded by "<" and ">" brackets) identifying one recipient. If accepted, the SMTP server returns a 250 OK reply and stores the forward-path. If the recipient is known not to be a deliverable address, the SMTP server returns a 550 reply, typically with a string such as "no such user - " and the mailbox name (other circumstances and reply codes are possible). This step of the procedure can be repeated any number of times.
このコマンドへの1番目か議論だけが、1人の受取人を特定しながら、フォワードパス(通常いつも"<"と">"括弧によって囲まれたメールボックスとドメイン)を含んでいます。 受け入れるなら、SMTPサーバーは、250OK回答を返して、フォワードパスを保存します。 受取人が提出物のアドレスでないことが知られているなら、SMTPサーバーは通常「いいえ、そのようなユーザ」やメールボックス名などのひもで550回答を返します(他の事情と回答コードは可能です)。 いろいろな回手順のこのステップを繰り返すことができます。
The <forward-path> can contain more than just a mailbox. Historically, the <forward-path> can be a source routing list of hosts and the destination mailbox, however, contemporary SMTP clients SHOULD NOT utilize source routes (see appendix C). Servers MUST be prepared to encounter a list of source routes in the forward path, but SHOULD ignore the routes or MAY decline to support the relaying they imply. Similarly, servers MAY decline to accept mail that is destined for other hosts or systems. These restrictions make a server useless as a relay for clients that do not support full SMTP functionality. Consequently, restricted-capability clients MUST NOT assume that any SMTP server on the Internet can be used as their mail processing (relaying) site. If a RCPT command appears without a previous MAIL command, the server MUST return a 503 "Bad sequence of commands" response. The optional <rcpt-parameters> are associated with negotiated SMTP service extensions (see section 2.2).
<フォワードパス>はまさしくメールボックス以上を含むことができます。 <フォワードパス>が歴史的に、ホストのソースルーティングリストとあて先メールボックスであるかもしれない、しかしながら、現代のSMTPクライアントSHOULD NOTは送信元経路を利用します(付録Cを見てください)。 フォワードパスで送信元経路のリストに遭遇するようにサーバを準備しなければなりませんが、SHOULDは、彼らが含意するリレーをサポートするためにルートか5月の衰退を無視します。 同様に、サーバは、他のホストかシステムのために運命づけられているメールを受け入れるのを断るかもしれません。これらの制限で、サーバは完全なSMTPが機能性であるとサポートしないクライアントのためのリレーとして役に立たなくなります。 その結果、制限された能力クライアントは、彼らのメール処理(リレーする)サイトとしてインターネットのどんなSMTPサーバーも使用できると仮定してはいけません。 RCPTコマンドが前のメールコマンドなしで現れるなら、サーバは503「コマンドの悪い系列」応答を返さなければなりません。 任意の<rcpt-パラメタ>は交渉されたSMTPサービス拡張子に関連しています(セクション2.2を見てください)。
The third step in the procedure is the DATA command (or some alternative specified in a service extension).
手順における第3ステップはDATAコマンド(何らかの選択肢がサービス拡大で指定した)です。
Klensin Standards Track [Page 17] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[17ページ]RFC2821
DATA <CRLF>
データ<CRLF>。
If accepted, the SMTP server returns a 354 Intermediate reply and considers all succeeding lines up to but not including the end of mail data indicator to be the message text. When the end of text is successfully received and stored the SMTP-receiver sends a 250 OK reply.
受け入れるなら、SMTPサーバーは、354Intermediate回答を返して、系列をすべて引き継ぎますが、メールデータインディケータについて終わりを含まないのが、メッセージ・テキストであると考えます。 テキストの終わりが首尾よく得られて、保存されるとき、SMTP-受信機は250OK回答を送ります。
Since the mail data is sent on the transmission channel, the end of mail data must be indicated so that the command and reply dialog can be resumed. SMTP indicates the end of the mail data by sending a line containing only a "." (period or full stop). A transparency procedure is used to prevent this from interfering with the user's text (see section 4.5.2).
トランスミッションチャンネルでメールデータを送るので、コマンドと回答対話を再開できるようにメールデータの終わりを示さなければなりません。 「SMTPはa」だけ、を含む系列を送ることによって、メールデータの終わりを示します。」 (期間か終止符。) 透明手順は、これがユーザのテキストを妨げるのを防ぐのに用いられます(セクション4.5.2を見てください)。
The end of mail data indicator also confirms the mail transaction and tells the SMTP server to now process the stored recipients and mail data. If accepted, the SMTP server returns a 250 OK reply. The DATA command can fail at only two points in the protocol exchange:
メールデータインディケータの終わりは、また、メールトランザクションを確認して、今保存された受取人とメールデータを処理するようにSMTPサーバーに言います。 受け入れるなら、SMTPサーバーは250OK回答を返します。 DATAコマンドは2ポイントだけでプロトコル交換で失敗できます:
- If there was no MAIL, or no RCPT, command, or all such commands
were rejected, the server MAY return a "command out of sequence"
(503) or "no valid recipients" (554) reply in response to the DATA
command. If one of those replies (or any other 5yz reply) is
received, the client MUST NOT send the message data; more
generally, message data MUST NOT be sent unless a 354 reply is
received.
- メールが全くなかったというわけではないか、またはRCPT、コマンド、またはそのようなすべてのコマンドが拒絶されたというわけではないなら、サーバはDATAコマンドに対応して(503)にもかかわらず、「有効な受取人がありません」(554)回答を「系列からのコマンド」に返すかもしれません。 それらの回答(または、いかなる他の5yz回答)の1つが受け取られているなら、クライアントはメッセージデータを送ってはいけません。 より一般に、354回答が受け取られていない場合、メッセージデータを送ってはいけません。
- If the verb is initially accepted and the 354 reply issued, the
DATA command should fail only if the mail transaction was
incomplete (for example, no recipients), or if resources were
unavailable (including, of course, the server unexpectedly
becoming unavailable), or if the server determines that the
message should be rejected for policy or other reasons.
- 初めは、動詞を受け入れるか、そして、発行された354回答、メールトランザクションが単に不完全であったか(例えば、受取人がありません)、リソースが入手できなかった(もちろん不意にサーバを含んでいます入手できなくなる)、またはサーバが、メッセージが方針か他の理由で拒絶されるべきであることを決定するなら、DATAコマンドは失敗するべきです。
However, in practice, some servers do not perform recipient verification until after the message text is received. These servers SHOULD treat a failure for one or more recipients as a "subsequent failure" and return a mail message as discussed in section 6. Using a "550 mailbox not found" (or equivalent) reply code after the data are accepted makes it difficult or impossible for the client to determine which recipients failed.
しかしながら、実際には、いくつかのサーバはメッセージ・テキストが受け取られていた後まで受取人検証を実行しません。 セクション6で議論して、SHOULDが「その後の失敗」として1人以上の受取人のための失敗を扱って、メール・メッセージを返すこれらのサーバ。 データを受け入れた後に「見つけられなかった550メールボックス」(または、同等物)回答コードを使用するのに、クライアントが、どの受取人が失敗したかを決心しているのが難しいか不可能になります。
When RFC 822 format [7, 32] is being used, the mail data include the memo header items such as Date, Subject, To, Cc, From. Server SMTP systems SHOULD NOT reject messages based on perceived defects in the RFC 822 or MIME [12] message header or message body. In particular,
RFC822形式[7、32]が使用されているとき、メールデータはDateなどのメモヘッダーの品目を含んでいます、Subject、To、Cc、From。 サーバSMTPシステムSHOULD NOTはRFC822、MIME[12]メッセージヘッダーまたはメッセージ本体で知覚された欠陥に基づくメッセージを拒絶します。 特に
Klensin Standards Track [Page 18] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[18ページ]RFC2821
they MUST NOT reject messages in which the numbers of Resent-fields do not match or Resent-to appears without Resent-from and/or Resent- date.
または、彼らがResent-分野の数が合っていないメッセージを拒絶してはいけない、Resent、-、現れる、Resent、-、そして/または、Resent日付。
Mail transaction commands MUST be used in the order discussed above.
上で議論したオーダーでメールトランザクションコマンドを使用しなければなりません。
3.4 Forwarding for Address Correction or Updating
3.4 住所変更かアップデートのための推進
Forwarding support is most often required to consolidate and simplify addresses within, or relative to, some enterprise and less frequently to establish addresses to link a person's prior address with current one. Silent forwarding of messages (without server notification to the sender), for security or non-disclosure purposes, is common in the contemporary Internet.
推進サポートが、企業以内かいくらかの企業アドレスを統合して、簡素化して、どんなより頻繁にも人の先のアドレスを現在の1つにリンクするためにアドレスを確立しないようにたいてい必要です。 セキュリティへのメッセージ(送付者へのサーバ通知のない)か非公開目的の静かな推進は現代のインターネットで一般的です。
In both the enterprise and the "new address" cases, information hiding (and sometimes security) considerations argue against exposure of the "final" address through the SMTP protocol as a side-effect of the forwarding activity. This may be especially important when the final address may not even be reachable by the sender. Consequently, the "forwarding" mechanisms described in section 3.2 of RFC 821, and especially the 251 (corrected destination) and 551 reply codes from RCPT must be evaluated carefully by implementers and, when they are available, by those configuring systems.
企業と「新しいアドレス」ケースの両方では、情報隠蔽(そして、時々セキュリティ)問題は推進活動の副作用としてSMTPプロトコルを通して「最終的な」アドレスの暴露について反対の議論をします。 最終アドレスが送付者で届かないときさえ、これは特に重要であるかもしれません。 その結果、implementersであってそれらで構成することでそれらが利用可能であるときに慎重に特にRFC821のセクション3.2で説明されたメカニズム、251(目的地を修正する)、および551の回答コードがRCPTからの「進める」であることを評価しなければなりません。システム。
In particular:
特に:
* Servers MAY forward messages when they are aware of an address
change. When they do so, they MAY either provide address-updating
information with a 251 code, or may forward "silently" and return
a 250 code. But, if a 251 code is used, they MUST NOT assume that
the client will actually update address information or even return
that information to the user.
* それらがアドレス変化を意識しているとき、サーバはメッセージを転送するかもしれません。 彼らがそうすると、彼らは、250コードをアドレスをアップデートする情報に251コードを提供するか、「静かに」進めて、または返すかもしれません。 しかし、251コードが使用されているなら、彼らは、クライアントが実際にアドレス情報をアップデートするか、またはその情報をユーザに返しさえすると仮定してはいけません。
Alternately,
交互に
* Servers MAY reject or bounce messages when they are not
deliverable when addressed. When they do so, they MAY either
provide address-updating information with a 551 code, or may
reject the message as undeliverable with a 550 code and no
address-specific information. But, if a 551 code is used, they
MUST NOT assume that the client will actually update address
information or even return that information to the user.
* 扱われる場合それらが提出物でないときに、サーバは、メッセージを拒絶するか、または弾ませるかもしれません。 彼らがそうすると、彼らは、アドレスをアップデートする情報に551コードを提供するか、またはメッセージが550コードにもかかわらず、どんなアドレス特有の情報でも「非-提出物」でないと拒絶するかもしれません。 しかし、551コードが使用されているなら、彼らは、クライアントが実際にアドレス情報をアップデートするか、またはその情報をユーザに返しさえすると仮定してはいけません。
SMTP server implementations that support the 251 and/or 551 reply codes are strongly encouraged to provide configuration mechanisms so that sites which conclude that they would undesirably disclose information can disable or restrict their use.
彼らがあいにく情報を開示すると結論を下すサイトが彼らの使用を無効にする場合があるか、または制限する場合があるように251、そして/または、551回答がコードであるとサポートするSMTPサーバー実装が構成メカニズムを提供するよう強く奨励されます。
Klensin Standards Track [Page 19] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[19ページ]RFC2821
3.5 Commands for Debugging Addresses
3.5 デバッグアドレスのためのコマンド
3.5.1 Overview
3.5.1 概要
SMTP provides commands to verify a user name or obtain the content of a mailing list. This is done with the VRFY and EXPN commands, which have character string arguments. Implementations SHOULD support VRFY and EXPN (however, see section 3.5.2 and 7.3).
SMTPはユーザ名について確かめるか、またはメーリングリストの内容を得るコマンドを提供します。 VRFYとEXPNコマンドでこれをします。(コマンドには、文字列議論があります)。 実装SHOULDはVRFYとEXPNをサポートします(しかしながら、セクション3.5 .2と7.3を見てください)。
For the VRFY command, the string is a user name or a user name and domain (see below). If a normal (i.e., 250) response is returned, the response MAY include the full name of the user and MUST include the mailbox of the user. It MUST be in either of the following forms:
VRFYコマンドのために、ストリングは、ユーザ名かユーザ名とドメイン(以下を見る)です。 通常(すなわち、250)の応答を返すなら、応答は、ユーザのフルネームを含むかもしれなくて、ユーザのメールボックスを含まなければなりません。 それは以下のフォームのどちらかにあるに違いありません:
User Name <local-part@domain>
local-part@domain
ユーザ Name <local-part@domain 、gt;、地方のパート@domain
When a name that is the argument to VRFY could identify more than one mailbox, the server MAY either note the ambiguity or identify the alternatives. In other words, any of the following are legitimate response to VRFY:
VRFYへの議論である名前が1個以上のメールボックスを特定できたとき、サーバは、あいまいさに注意するか、または代替手段を特定するかもしれません。 言い換えれば、↓これのどれかはVRFYへの正統の応答です:
553 User ambiguous
553ユーザあいまいです。
or
または
553- Ambiguous; Possibilities are
553-Joe Smith <jsmith@foo.com>
553-Harry Smith <hsmith@foo.com>
553 Melvin Smith <dweep@foo.com>
553 あいまい。 ポシビリティーズが553ジョーの Smith <jsmith@foo.com である、gt;、553ハリーの Smith <hsmith@foo.com 、gt;、553メルビン Smith <dweep@foo.com 、gt。
or
または
553-Ambiguous; Possibilities
553- <jsmith@foo.com>
553- <hsmith@foo.com>
553 <dweep@foo.com>
553あいまい。 ポシビリティーズ 553- <jsmith@foo.com 、gt;、553<hsmith@foo.com> 553 <dweep@foo.com 、gt。
Under normal circumstances, a client receiving a 553 reply would be expected to expose the result to the user. Use of exactly the forms given, and the "user ambiguous" or "ambiguous" keywords, possibly supplemented by extended reply codes such as those described in [34], will facilitate automated translation into other languages as needed. Of course, a client that was highly automated or that was operating in another language than English, might choose to try to translate the response, to return some other indication to the user than the
通常の状況下で、553回答を受け取るクライアントがユーザに結果を暴露すると予想されるでしょう。 ことによると[34]で説明されたものなどの拡張回答コードによって補われたまさに与えられた書式の使用、および「ユーザあいまいである」か「あいまいな」キーワードは必要に応じて他の言語への自動化された翻訳を容易にするでしょう。 もちろん、英語、力が応答を翻訳して、ある他の指示をユーザに返そうとするのを選ぶより非常に自動化されたクライアントかそれが別の言語で手術されていました。
Klensin Standards Track [Page 20] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[20ページ]RFC2821
literal text of the reply, or to take some automated action such as consulting a directory service for additional information before reporting to the user.
回答か、撮影への或るものがユーザに報告する前に追加情報のためにディレクトリサービスに相談しながら動作を自動化した文字通りのテキスト。
For the EXPN command, the string identifies a mailing list, and the successful (i.e., 250) multiline response MAY include the full name of the users and MUST give the mailboxes on the mailing list.
EXPNコマンドのために、ストリングがメーリングリストを特定して、うまくいっている(すなわち、250)マルチライン応答は、ユーザのフルネームを含むかもしれなくて、メーリングリストのメールボックスを与えなければなりません。
In some hosts the distinction between a mailing list and an alias for a single mailbox is a bit fuzzy, since a common data structure may hold both types of entries, and it is possible to have mailing lists containing only one mailbox. If a request is made to apply VRFY to a mailing list, a positive response MAY be given if a message so addressed would be delivered to everyone on the list, otherwise an error SHOULD be reported (e.g., "550 That is a mailing list, not a user" or "252 Unable to verify members of mailing list"). If a request is made to expand a user name, the server MAY return a positive response consisting of a list containing one name, or an error MAY be reported (e.g., "550 That is a user name, not a mailing list").
何人かのホストでは、単一のメールボックスのためのメーリングリストと別名の区別は少しあいまいです、一般的なデータ構造が両方のタイプのエントリーを保持するかもしれなくて、1個のメールボックスだけを含むメーリングリストを持っているのが可能であるので。 要求をするなら、メーリングリスト、リストでそのように扱われたメッセージを皆に提供するなら応答を与えるかもしれなくて、そうでなければ、誤りがSHOULDであることを確信しているaにVRFYを適用するには、報告してください(例えば、「550Thatはメーリングリストです、ユーザでない」か「メーリングリストのメンバーについて確かめる252Unable」)。 ユーザ名を広げるのを要求をするなら、サーバが1つの名前を含むリストから成る積極的な応答を返すかもしれませんか、または誤りは報告されるかもしれません(例えば、「550 Thatはメーリングリストではなく、ユーザ名です」)。
In the case of a successful multiline reply (normal for EXPN) exactly one mailbox is to be specified on each line of the reply. The case of an ambiguous request is discussed above.
うまくいっているマルチライン回答(EXPNに、正常な)の場合では、ちょうど1個のメールボックスが回答の各系列で指定されることになっています。 上であいまいな要求に関するケースについて議論します。
"User name" is a fuzzy term and has been used deliberately. An implementation of the VRFY or EXPN commands MUST include at least recognition of local mailboxes as "user names". However, since current Internet practice often results in a single host handling mail for multiple domains, hosts, especially hosts that provide this functionality, SHOULD accept the "local-part@domain" form as a "user name"; hosts MAY also choose to recognize other strings as "user names".
「ユーザ名」は、あいまいな用語であり、故意に使用されました。 VRFYかEXPNコマンドの実装は「ユーザ名」として少なくとも地方のメールボックスの認識を含まなければなりません。 しかしながら、現在のインターネット習慣がしばしば複数のドメインのためのただ一つのホスト取り扱いメールをもたらして以来のホスト、特にこの機能性、SHOULDを提供するホストが「ユーザ名」として" local-part@domain "フォームを認めます。 また、ホストは、他のストリングが「ユーザ名」であると認めるのを選ぶかもしれません。
The case of expanding a mailbox list requires a multiline reply, such as:
メールボックスリストを広げるケースは以下などのマルチライン回答を必要とします。
C: EXPN Example-People
S: 250-Jon Postel <Postel@isi.edu>
S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
S: 250 Sam Q. Smith <SQSmith@specific.generic.com>
C: EXPN例人々S: 250ジョンの Postel <Postel@isi.edu 、gt;、S: 250フレッドの Fonebone <Fonebone@physics.foo-u.edu 、gt;、S: 250サムQ. Smith <SQSmith@specific.generic.com 、gt。
or
または
C: EXPN Executive-Washroom-List
S: 550 Access Denied to You.
C: EXPN幹部社員洗面所リストS: 550 あなたへのアクセス拒否。
Klensin Standards Track [Page 21] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[21ページ]RFC2821
The character string arguments of the VRFY and EXPN commands cannot be further restricted due to the variety of implementations of the user name and mailbox list concepts. On some systems it may be appropriate for the argument of the EXPN command to be a file name for a file containing a mailing list, but again there are a variety of file naming conventions in the Internet. Similarly, historical variations in what is returned by these commands are such that the response SHOULD be interpreted very carefully, if at all, and SHOULD generally only be used for diagnostic purposes.
VRFYとEXPNコマンドの文字列議論はユーザ名とメールボックスリスト概念の実装のバラエティーのためさらに制限されない場合があります。 いくつかのシステムの上では、メーリングリストを含むファイルのためのファイル名であるEXPNコマンドの議論に、それは適切であるかもしれませんが、さまざまなファイル命名規則が再びインターネットであります。 これらのコマンドで返されるものの歴史的な変化は、同様に、応答SHOULDが非常にせいぜい慎重に解釈されるようなものとSHOULDです。一般に、単に診断目的で使用されてください。
3.5.2 VRFY Normal Response
3.5.2 VRFYの通常の応答
When normal (2yz or 551) responses are returned from a VRFY or EXPN request, the reply normally includes the mailbox name, i.e., "<local-part@domain>", where "domain" is a fully qualified domain name, MUST appear in the syntax. In circumstances exceptional enough to justify violating the intent of this specification, free-form text MAY be returned. In order to facilitate parsing by both computers and people, addresses SHOULD appear in pointed brackets. When addresses, rather than free-form debugging information, are returned, EXPN and VRFY MUST return only valid domain addresses that are usable in SMTP RCPT commands. Consequently, if an address implies delivery to a program or other system, the mailbox name used to reach that target MUST be given. Paths (explicit source routes) MUST NOT be returned by VRFY or EXPN.
「VRFYかEXPN要求から通常(2yzか551)の応答を返すとき、通常、回答はメールボックス名を含んでいます、すなわち、 "<local-part@domain 、gt;、」 構文で「ドメイン」が完全修飾ドメイン名であるところに見えなければなりません。 この仕様の意図に違反するのを正当化するほど例外的な事情では、自由形式テキストを返すかもしれません。 コンピュータと人々の両方で分析するのを容易にするために、SHOULDが載っているアドレスは括弧を指しました。 自由形式デバッグ情報よりむしろアドレスを返すとき、EXPNとVRFY MUSTはSMTP RCPTコマンドで使用可能な有効なドメインアドレスだけを返します。 その結果、アドレスがプログラムか他のシステムに配送を含意するなら、その目標に達するのに使用されるメールボックス名を与えなければなりません。 経路(明白な送信元経路)はVRFYかEXPNによって返されてはいけません。
Server implementations SHOULD support both VRFY and EXPN. For security reasons, implementations MAY provide local installations a way to disable either or both of these commands through configuration options or the equivalent. When these commands are supported, they are not required to work across relays when relaying is supported. Since they were both optional in RFC 821, they MUST be listed as service extensions in an EHLO response, if they are supported.
サーバ実装SHOULDはVRFYとEXPNの両方をサポートします。 安全保障上の理由で、実装はこれらのどちらかか両方が設定オプションによるコマンドか同等物であると無効にする方法を現地搬入に提供するかもしれません。 これらのコマンドがサポートされるとき、それらは必要でないことで、リレーするとき、リレーの向こう側に働いているのがサポートされるということです。 それらがRFC821でともに任意であったので、EHLO応答におけるサービス拡大としてそれらを記載しなければなりません、それらがサポートされるなら。
3.5.3 Meaning of VRFY or EXPN Success Response
3.5.3 VRFYかEXPN成功応答の意味
A server MUST NOT return a 250 code in response to a VRFY or EXPN command unless it has actually verified the address. In particular, a server MUST NOT return 250 if all it has done is to verify that the syntax given is valid. In that case, 502 (Command not implemented) or 500 (Syntax error, command unrecognized) SHOULD be returned. As stated elsewhere, implementation (in the sense of actually validating addresses and returning information) of VRFY and EXPN are strongly recommended. Hence, implementations that return 500 or 502 for VRFY are not in full compliance with this specification.
実際にアドレスについて確かめていない場合、サーバはVRFYかEXPNコマンドに対応して250コードを返してはいけません。 特に、サーバはそれがしたすべてが与えられた構文が有効であることを確かめることであるなら250を返してはいけません。 その場合、502(実装されなかったコマンド)、または500の(構文エラーで、コマンド認識されていません)のSHOULD、返してください。 別記のとおり、VRFYとEXPNの実装(実際にアドレスと返品情報を有効にするという意味における)は強く推薦されます。 したがって、VRFYのために500か502を返す実装がこの仕様に応えてありません。
Klensin Standards Track [Page 22] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[22ページ]RFC2821
There may be circumstances where an address appears to be valid but cannot reasonably be verified in real time, particularly when a server is acting as a mail exchanger for another server or domain. "Apparent validity" in this case would normally involve at least syntax checking and might involve verification that any domains specified were ones to which the host expected to be able to relay mail. In these situations, reply code 252 SHOULD be returned. These cases parallel the discussion of RCPT verification discussed in section 2.1. Similarly, the discussion in section 3.4 applies to the use of reply codes 251 and 551 with VRFY (and EXPN) to indicate addresses that are recognized but that would be forwarded or bounced were mail received for them. Implementations generally SHOULD be more aggressive about address verification in the case of VRFY than in the case of RCPT, even if it takes a little longer to do so.
事情がアドレスについて有効であるように見えますが、リアルタイムで合理的に確かめることができないところにあるかもしれません、特にサーバが別のサーバかドメインへのメール交換器として機能しているとき。 ホストができると予想したものがメールをリレーするなら、この場合、「見かけの正当性」は、通常、少なくとも構文の照合にかかわって、どんなドメインも指定した検証にかかわるでしょうに。 これらでは、状況、回答は252SHOULDをコード化します。返します。 これらのケースはセクション2.1で議論したRCPT検証の議論に沿います。 同様に、セクション3.4での議論は、認識しますが、転送するか、または弾ませるアドレスがそれらのために受け取られたメールであったのを示すのをVRFY(そして、EXPN)との回答コード251と551の使用に適用します。 一般に実装SHOULD、VRFYの場合ではRCPTに関するケースよりアドレス検査に関して攻撃的であってください、そうするために少し時間がかかっても。
3.5.4 Semantics and Applications of EXPN
3.5.4 EXPNの意味論とアプリケーション
EXPN is often very useful in debugging and understanding problems with mailing lists and multiple-target-address aliases. Some systems have attempted to use source expansion of mailing lists as a means of eliminating duplicates. The propagation of aliasing systems with mail on the Internet, for hosts (typically with MX and CNAME DNS records), for mailboxes (various types of local host aliases), and in various proxying arrangements, has made it nearly impossible for these strategies to work consistently, and mail systems SHOULD NOT attempt them.
EXPNはメーリングリストと複数のあて先アドレス別名に関する問題をデバッグして、理解する際にしばしば非常に役に立ちます。 いくつかのシステムが、写しを排除する手段としてメーリングリストのソース拡張を使用するのを試みました。 インターネット、ホスト(通常、MXとCNAME DNS記録がある)、メールボックス(様々なタイプのローカル・ホスト別名)、および様々なproxyingアレンジメントにおけるメールがあるエイリアシングシステムの伝播でこれらの戦略が一貫して利くのがほとんど不可能になりました、そして、メールシステムSHOULD NOTはそれらを試みます。
3.6 Domains
3.6 ドメイン
Only resolvable, fully-qualified, domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs. Local nicknames or unqualified names MUST NOT be used. There are two exceptions to the rule requiring FQDNs:
ドメイン名がSMTPで使用されるとき、溶解性だけの、そして、完全に適切なドメイン名(FQDNs)は受入れられます。 言い換えれば、MX RRsかA RRs(セクション5で議論するように)に決議できる名前は目標を決議できるCNAME RRsのように順番に受入れられます、MXかA RRsに。 ローカルのあだ名か資格のない名前を使用してはいけません。 規則へのFQDNsを必要とする2つの例外があります:
- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.
- 一次ホスト名(AにRRを決議するドメイン名)かセクション4.1.1で説明されるアドレスリテラルのどちらかがホストに名前が全くないなら.1であったに違いないならEHLOコマンドで与えられたドメイン名。
- The reserved mailbox name "postmaster" may be used in a RCPT
command without domain qualification (see section 4.1.1.3) and
MUST be accepted if so used.
- そして、「郵便局長」という予約されたメールボックス名がドメイン資格なしでRCPTコマンドに使用されるかもしれない、(.3が、)4.1に.1を区分するのを見る、そのように使用するなら、受け入れなければなりません。
Klensin Standards Track [Page 23] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[23ページ]RFC2821
3.7 Relaying
3.7 リレー
In general, the availability of Mail eXchanger records in the domain name system [22, 27] makes the use of explicit source routes in the Internet mail system unnecessary. Many historical problems with their interpretation have made their use undesirable. SMTP clients SHOULD NOT generate explicit source routes except under unusual circumstances. SMTP servers MAY decline to act as mail relays or to accept addresses that specify source routes. When route information is encountered, SMTP servers are also permitted to ignore the route information and simply send to the final destination specified as the last element in the route and SHOULD do so. There has been an invalid practice of using names that do not appear in the DNS as destination names, with the senders counting on the intermediate hosts specified in source routing to resolve any problems. If source routes are stripped, this practice will cause failures. This is one of several reasons why SMTP clients MUST NOT generate invalid source routes or depend on serial resolution of names.
一般に、ドメイン名システム[22、27]のメールeXchanger記録の有用性で、インターネット・メールシステムにおける明白な送信元経路の使用は不要になります。 多くの彼らの解釈に関する歴史的な問題で、彼らの使用は望ましくなくなりました。 珍しい状況を除いて、SMTPクライアントSHOULD NOTは明白な送信元経路を生成します。 SMTPサーバーは、メール中継として機能するか、または送信元経路を指定するアドレスを認めるのを断るかもしれません。 また、経由地案内が遭遇するとき、SMTPサーバーは、経由地案内を無視して、単にルートにおける最後の要素として指定された最終的な目的地に発信するのが可能にされます、そして、SHOULDはそうします。 目的地名としてDNSに現れない名前を使用する無効の習慣がありました、送付者が、ソースルーティングで指定された中間的ホストがどんな問題も解決するのを頼りにしていて。送信元経路が剥取られると、この習慣は失敗を引き起こすでしょう。 これはSMTPクライアントが無効の送信元経路を生成してはいけませんし、また名前の連続の解決を当てにしてはいけないいくつかの理由の1つです。
When source routes are not used, the process described in RFC 821 for constructing a reverse-path from the forward-path is not applicable and the reverse-path at the time of delivery will simply be the address that appeared in the MAIL command.
送信元経路が使用されていないとき、フォワードパスから逆経路を構成するためにRFC821で説明されたプロセスは適切ではありません、そして、逆経路は販売時に単にメールコマンドに現れたアドレスになるでしょう。
A relay SMTP server is usually the target of a DNS MX record that designates it, rather than the final delivery system. The relay server may accept or reject the task of relaying the mail in the same way it accepts or rejects mail for a local user. If it accepts the task, it then becomes an SMTP client, establishes a transmission channel to the next SMTP server specified in the DNS (according to the rules in section 5), and sends it the mail. If it declines to relay mail to a particular address for policy reasons, a 550 response SHOULD be returned.
通常、リレーSMTPサーバは最終的な配送システムよりむしろそれを指定するDNS MX記録の目標です。 リレーサーバは、地元のユーザのためにメールを受け入れるか、または拒絶する同じようにメールをリレーするタスクを受け入れるか、または拒絶するかもしれません。 タスクを受け入れるなら、それは、次に、SMTPクライアントになって、DNS(セクション5の規則に従って)で指定された次のSMTPサーバーにトランスミッションチャンネルを確立して、メールをそれに送ります。 減退するなら、方針理由、550応答SHOULDのための特定のアドレスにメールをリレーするには、返してください。
Many mail-sending clients exist, especially in conjunction with facilities that receive mail via POP3 or IMAP, that have limited capability to support some of the requirements of this specification, such as the ability to queue messages for subsequent delivery attempts. For these clients, it is common practice to make private arrangements to send all messages to a single server for processing and subsequent distribution. SMTP, as specified here, is not ideally suited for this role, and work is underway on standardized mail submission protocols that might eventually supercede the current practices. In any event, because these arrangements are private and fall outside the scope of this specification, they are not described here.
多くのメールを送るクライアントが存在します、特にPOP3かIMAPを通してメールを受け取って、この仕様の要件のいくつかをサポートする能力を制限した施設に関連して、その後の配送試みへのメッセージを列に並ばせる能力などのように。 これらのクライアントにとって、処理とその後の分配のためのただ一つのサーバにすべてのメッセージを送るために秘密協定をするのは、一般的な習慣です。 ここで指定されるとして、SMTPは理想的にこの役割に合っていません、そして、仕事は標準化された結局電流が練習するsupercedeがそうするかもしれないメール服従プロトコルで進行中です。 とにかく、これらのアレンジメントが個人的であり、この仕様の範囲をそらせるので、それらはここで説明されません。
Klensin Standards Track [Page 24] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[24ページ]RFC2821
It is important to note that MX records can point to SMTP servers which act as gateways into other environments, not just SMTP relays and final delivery systems; see sections 3.8 and 5.
MX記録がSMTPリレーと最終的な配送システムだけではなく、他の環境へのゲートウェイとしてどの行為をSMTPサーバーに向けることができるかに注意するのは重要です。 セクション3.8と5を見てください。
If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse- path). Formats specified for non-delivery reports by other standards (see, for example, [24, 25]) SHOULD be used if possible.
SMTPサーバーが、メールをリレーするタスクを受け入れて、後で目的地が不正確であるか、またはある他の理由でメールは提供できないのがわかるなら、それが、「「非-提出物」メール」通知メッセージを構成して、「非-提出物」メールの創始者にそれを送らなければなりません(逆経路によって示されるように)。 非配送に指定された形式は、他の規格(例えば、見ます[24、25])SHOULDでできれば、使用されるように報告します。
This notification message must be from the SMTP server at the relay host or the host that first determines that delivery cannot be accomplished. Of course, SMTP servers MUST NOT send notification messages about problems transporting notification messages. One way to prevent loops in error reporting is to specify a null reverse-path in the MAIL command of a notification message. When such a message is transmitted the reverse-path MUST be set to null (see section 4.5.5 for additional discussion). A MAIL command with a null reverse-path appears as follows:
この通知メッセージは最初に配送を実行できないと決心している中継ホストかホストでSMTPサーバーから来ているに違いありません。 もちろん、SMTPサーバーは通知メッセージを輸送することにおける問題に関する通知メッセージを送ってはいけません。 間違い輪が報告するのを防ぐ1つの方法は通知メッセージのメールコマンドにおける逆経路のヌルを指定することです。 そのようなメッセージが送られるとき、逆経路をヌルに設定しなければなりません(追加議論に関してセクション4.5.5を見てください)。 逆経路であることでのヌルメールコマンドは以下の通りに見えます:
MAIL FROM:<>
メールFROM:<>。
As discussed in section 2.4.1, a relay SMTP has no need to inspect or act upon the headers or body of the message data and MUST NOT do so except to add its own "Received:" header (section 4.4) and, optionally, to attempt to detect looping in the mail system (see section 6.2).
セクション2.4.1で議論するように、リレーSMTPはヘッダーかメッセージ欄データに点検するか、または作用する必要性を全く持たないで、加える以外に、そうそれ自身の「受け取るのであったこと」をしてはいけません。 ヘッダー(セクション4.4)と任意にメールシステム(セクション6.2を見る)にループを検出する試みるのに。
3.8 Mail Gatewaying
3.8 メールGatewaying
While the relay function discussed above operates within the Internet SMTP transport service environment, MX records or various forms of explicit routing may require that an intermediate SMTP server perform a translation function between one transport service and another. As discussed in section 2.3.8, when such a system is at the boundary between two transport service environments, we refer to it as a "gateway" or "gateway SMTP".
上で議論したリレー機能がインターネットSMTP輸送サービス環境の中で作動している間、MX記録か様々なフォームの明白なルーティングは、中間的SMTPサーバーが1つの輸送サービスと別のものの間の翻訳機能を実行するのを必要とするかもしれません。 そのようなシステムが2つの輸送サービス環境の間の境界にあるとき、セクション2.3.8で議論するように、私たちは「ゲートウェイ」か「ゲートウェイSMTP」とそれを呼びます。
Gatewaying mail between different mail environments, such as different mail formats and protocols, is complex and does not easily yield to standardization. However, some general requirements may be given for a gateway between the Internet and another mail environment.
異なったメール書式やプロトコルなどの異なったメール環境の間のメールをGatewayingするのは複雑であり、容易に標準化に屈しません。 しかしながら、インターネットと別のメール環境の間でいくつかの一般的な要件をゲートウェイに与えるかもしれません。
Klensin Standards Track [Page 25] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[25ページ]RFC2821
3.8.1 Header Fields in Gatewaying
3.8.1 Gatewayingのヘッダーフィールド
Header fields MAY be rewritten when necessary as messages are gatewayed across mail environment boundaries. This may involve inspecting the message body or interpreting the local-part of the destination address in spite of the prohibitions in section 2.4.1.
必要であるときに、メッセージがメール環境限界の向こう側にgatewayedされるとき、ヘッダーフィールドは書き直されるかもしれません。 これは、メッセージ本体を点検するか、禁止にもかかわらず、または送付先アドレスの地方の部分を解釈することをセクション2.4.1に伴うかもしれません。
Other mail systems gatewayed to the Internet often use a subset of RFC 822 headers or provide similar functionality with a different syntax, but some of these mail systems do not have an equivalent to the SMTP envelope. Therefore, when a message leaves the Internet environment, it may be necessary to fold the SMTP envelope information into the message header. A possible solution would be to create new header fields to carry the envelope information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would require changes in mail programs in foreign environments and might risk disclosure of private information (see section 7.2).
または、インターネットにgatewayedされた他のメールシステムがしばしばRFCの部分集合を使用する、822個のヘッダー、異なった構文を同様の機能性に提供しなさい、ただし、これらのいくつかのメールシステムはSMTP封筒に同等物を持っていません。 したがって、メッセージがインターネット環境を残すとき、SMTP封筒情報をメッセージヘッダーに折り重ねるのが必要であるかもしれません。 そして、可能なソリューションが封筒情報を運ぶために新しいヘッダーフィールドを作成するだろうことである、(例えば、「以下をX-SMTP郵送してください」、「X-SMTP-RCPT:」、)、。 しかしながら、これは、外国環境におけるメールプログラムに釣り銭がいて、個人情報の公開を危険にさらすかもしれません(セクション7.2を見てください)。
3.8.2 Received Lines in Gatewaying
3.8.2 Gatewayingの容認された線
When forwarding a message into or out of the Internet environment, a gateway MUST prepend a Received: line, but it MUST NOT alter in any way a Received: line that is already in the header.
環境の中、または、インターネット環境からメッセージを転送するとき、ゲートウェイはReceivedをprependしなければなりません: 何らかの方法でReceivedを変更してはいけません: ヘッダーに既にある系列。
"Received:" fields of messages originating from other environments may not conform exactly to this specification. However, the most important use of Received: lines is for debugging mail faults, and this debugging can be severely hampered by well-meaning gateways that try to "fix" a Received: line. As another consequence of trace fields arising in non-SMTP environments, receiving systems MUST NOT reject mail based on the format of a trace field and SHOULD be extremely robust in the light of unexpected information or formats in those fields.
「受け取りました」 他の環境から発するメッセージの分野はちょうどこの仕様に従わないかもしれません。 Receivedの最も重要な使用: 系列がデバッグメール障害によってあります、そして、Receivedを「修理しようとする」善意のゲートウェイは厳しくこのデバッグを妨げることができます: 立ち並んでください。 跡の別の結果が非SMTP環境における起こることをさばくので、システムを受け止めて、跡の分野の形式に基づく廃棄物メールとSHOULDは予期していなかった情報か形式の見地からそれらの分野で非常に強健であるはずがありませんか?
The gateway SHOULD indicate the environment and protocol in the "via" clauses of Received field(s) that it supplies.
ゲートウェイSHOULDが環境とプロトコルを示す、Receivedの節「を通して」では、それが供給する(s)をさばいてください。
3.8.3 Addresses in Gatewaying
3.8.3 Gatewayingのアドレス
From the Internet side, the gateway SHOULD accept all valid address formats in SMTP commands and in RFC 822 headers, and all valid RFC 822 messages. Addresses and headers generated by gateways MUST conform to applicable Internet standards (including this one and RFC 822). Gateways are, of course, subject to the same rules for handling source routes as those described for other SMTP systems in section 3.3.
インターネット側から、ゲートウェイSHOULDはRFCのSMTPコマンドにおけるすべての有効なアドレス形式、822個のヘッダー、およびすべての有効なRFC822メッセージを受け入れます。 ゲートウェイによって作られたアドレスとヘッダーは適切なインターネット標準に従わなければなりません(この1とRFC822を含んでいて)。 取り扱い送信元経路において、ゲートウェイはもちろんものが他のSMTPシステムのためにセクション3.3で説明したように同じ規則を受けることがあります。
Klensin Standards Track [Page 26] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[26ページ]RFC2821
3.8.4 Other Header Fields in Gatewaying
3.8.4 Gatewayingの他のヘッダーフィールド
The gateway MUST ensure that all header fields of a message that it forwards into the Internet mail environment meet the requirements for Internet mail. In particular, all addresses in "From:", "To:", "Cc:", etc., fields MUST be transformed (if necessary) to satisfy RFC 822 syntax, MUST reference only fully-qualified domain names, and MUST be effective and useful for sending replies. The translation algorithm used to convert mail from the Internet protocols to another environment's protocol SHOULD ensure that error messages from the foreign mail environment are delivered to the return path from the SMTP envelope, not to the sender listed in the "From:" field (or other fields) of the RFC 822 message.
ゲートウェイは、それがインターネット・メール環境に転送するメッセージのすべてのヘッダーフィールドがインターネット・メールのために条件を満たすのを確実にしなければなりません。 特に「From:」、「To:」、「Cc:」などにおけるすべてのアドレス、分野は、送付回答に(必要なら、)RFC822構文を満たすために変えなければならなくて、完全修飾ドメイン名だけに参照をつけなければならなくて、有効であって、役に立つに違いありません。 インターネットプロトコルから別の環境のプロトコルSHOULDまでメールを変換するのに使用される変換アルゴリズムは、外国メール環境からのエラーメッセージが「From:」に記載された送付者から提供されるのではなく、SMTP封筒からリターンパスに提供されるのを確実にします。 RFC822メッセージの分野(または、他の分野)。
3.8.5 Envelopes in Gatewaying
3.8.5 Gatewayingの封筒
Similarly, when forwarding a message from another environment into the Internet, the gateway SHOULD set the envelope return path in accordance with an error message return address, if supplied by the foreign environment. If the foreign environment has no equivalent concept, the gateway must select and use a best approximation, with the message originator's address as the default of last resort.
メッセージを別の環境からインターネットに転送するとき、同様に、エラーメッセージ返送先によると、ゲートウェイSHOULDは封筒リターンパスを設定します、外国環境から供給するなら。 外国環境でどんな同等な概念もないなら、ゲートウェイは、最良近似を選択して、使用しなければなりません、切り札のデフォルトとしてのメッセージ創始者のアドレスで。
3.9 Terminating Sessions and Connections
3.9 セッションとコネクションズを終えること。
An SMTP connection is terminated when the client sends a QUIT command. The server responds with a positive reply code, after which it closes the connection.
クライアントがQUITコマンドを送ると、SMTP接続は終えられます。 サーバは積極的な返事コードで反応します。(その時、それは接続を終えました後)。
An SMTP server MUST NOT intentionally close the connection except:
以下以外に、SMTPサーバーは故意に接続を終えてはいけません。
- After receiving a QUIT command and responding with a 221 reply.
- QUITコマンドを受け取って、221回答で応じた後に。
- After detecting the need to shut down the SMTP service and
returning a 421 response code. This response code can be issued
after the server receives any command or, if necessary,
asynchronously from command receipt (on the assumption that the
client will receive it after the next command is issued).
- SMTPサービスを止める必要性を見つけて、421応答コードを返した後に。 または、サーバがどんなコマンドも受け取った後にこの応答コードを発行できる、必要ならと、非同期である、コマンド領収書(次のコマンドを発行した後にクライアントがそれを受けるという前提での)から。
In particular, a server that closes connections in response to commands that are not understood is in violation of this specification. Servers are expected to be tolerant of unknown commands, issuing a 500 reply and awaiting further instructions from the client.
特に、理解されていないコマンドに対応して接続を終えるサーバはこの仕様を違反しています。 500回答を発行して、クライアントからその後の支持を待って、サーバは未知のコマンドにおいて許容性があると予想されます。
Klensin Standards Track [Page 27] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[27ページ]RFC2821
An SMTP server which is forcibly shut down via external means SHOULD attempt to send a line containing a 421 response code to the SMTP client before exiting. The SMTP client will normally read the 421 response code after sending its next command.
外部を通して強制的に止められるSMTPサーバーは、SHOULDが、出る前に421応答コードをSMTPクライアントに含む系列を送るのを試みることを意味します。 次のコマンドを送った後に、通常、SMTPクライアントは421応答コードを読むでしょう。
SMTP clients that experience a connection close, reset, or other communications failure due to circumstances not under their control (in violation of the intent of this specification but sometimes unavoidable) SHOULD, to maintain the robustness of the mail system, treat the mail transaction as if a 451 response had been received and act accordingly.
近くで接続を経験するSMTPクライアント、リセット、または事情による他のコミュニケーション失敗が、メールシステムの丈夫さを維持するためにまるで451応答を受けたかのようにそれらのコントロール(この仕様にもかかわらず、時々避けられないことの意図を違反した)SHOULDの下でメールトランザクションを扱って、善処しません。
3.10 Mailing Lists and Aliases
3.10 メーリングリストと別名
An SMTP-capable host SHOULD support both the alias and the list
models of address expansion for multiple delivery. When a message is
delivered or forwarded to each address of an expanded list form, the
return address in the envelope ("MAIL FROM:") MUST be changed to be
the address of a person or other entity who administers the list.
However, in this case, the message header [32] MUST be left
unchanged; in particular, the "From" field of the message header is
unaffected.
SHOULDが別名と多重配信のためのアドレス拡張のリストモデルの両方をサポートするSMTP有能なホスト。 拡張リストフォームの各アドレスにメッセージを提供するか、または転送するとき、リストを管理する人か他の実体のアドレスになるように封筒(「メールFROM:」)の返送先を変えなければなりません。 しかしながら、この場合、メッセージヘッダー[32]を変わりがないままにしなければなりません。 メッセージヘッダーの“From"分野は特に、影響を受けないです。
An important mail facility is a mechanism for multi-destination delivery of a single message, by transforming (or "expanding" or "exploding") a pseudo-mailbox address into a list of destination mailbox addresses. When a message is sent to such a pseudo-mailbox (sometimes called an "exploder"), copies are forwarded or redistributed to each mailbox in the expanded list. Servers SHOULD simply utilize the addresses on the list; application of heuristics or other matching rules to eliminate some addresses, such as that of the originator, is strongly discouraged. We classify such a pseudo- mailbox as an "alias" or a "list", depending upon the expansion rules.
重要な郵便施設はただ一つのメッセージのマルチの目的地配送のためのメカニズムです、疑似メールボックスアドレスをあて先メールボックスアドレスのリストに変えることによって(または、「広げる」か「爆発」)。 そのような疑似メールボックス(時々「発破器」と呼ばれる)にメッセージを送るとき、拡張リストの各メールボックスにコピーを送るか、または再配付します。 サーバSHOULDはリストで単にアドレスを利用します。 創始者のものなどのように、何らかのいくつかのアドレスを排除するために規則に合っている発見的教授法の適用は強くお勧めできないです。 拡張規則によって、私たちは「別名」や「リスト」のような疑似メールボックスを分類します。
3.10.1 Alias
3.10.1 通称
To expand an alias, the recipient mailer simply replaces the pseudo- mailbox address in the envelope with each of the expanded addresses in turn; the rest of the envelope and the message body are left unchanged. The message is then delivered or forwarded to each expanded address.
別名を広げるために、受取人郵送者は単に封筒の広げるのがあるそれぞれについてアドレスが順番に扱う疑似メールボックスを取り替えます。 封筒の残りとメッセージ本体は変わりがないままにされます。 各拡張アドレスにメッセージを次に、提供するか、または転送します。
3.10.2 List
3.10.2 リスト
A mailing list may be said to operate by "redistribution" rather than by "forwarding". To expand a list, the recipient mailer replaces the pseudo-mailbox address in the envelope with all of the expanded
メーリングリストは「推進」でというよりむしろ「再分配」で作動すると言われているかもしれません。 リストを広げるために、受取人郵送者は封筒で疑似メールボックスアドレスを広げることのすべてに置き換えます。
Klensin Standards Track [Page 28] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[28ページ]RFC2821
addresses. The return address in the envelope is changed so that all error messages generated by the final deliveries will be returned to a list administrator, not to the message originator, who generally has no control over the contents of the list and will typically find error messages annoying.
アドレス。 一般に、リストのコンテンツを管理しないで、エラーメッセージが煩わしいのが通常わかるメッセージ創始者ではなく、リスト管理者に最終的な配送で生成されたすべてのエラーメッセージを返すように封筒の返送先を変えます。
4. The SMTP Specifications
4. SMTP仕様
4.1 SMTP Commands
4.1 SMTPコマンド
4.1.1 Command Semantics and Syntax
4.1.1 コマンド意味論と構文
The SMTP commands define the mail transfer or the mail system function requested by the user. SMTP commands are character strings terminated by <CRLF>. The commands themselves are alphabetic characters terminated by <SP> if parameters follow and <CRLF> otherwise. (In the interest of improved interoperability, SMTP receivers are encouraged to tolerate trailing white space before the terminating <CRLF>.) The syntax of the local part of a mailbox must conform to receiver site conventions and the syntax specified in section 4.1.2. The SMTP commands are discussed below. The SMTP replies are discussed in section 4.2.
SMTPコマンドはユーザによって要求された郵便為替かメールシステム機能を定義します。 SMTPコマンドは<CRLF>によって終えられた文字列です。 そうでなければ、コマンド自体は、パラメタが従うなら<SP>によって終えられた英字と<CRLF>です。 (改良された相互運用性のために、SMTP受信機が、終わっている<CRLF>の前に余白を引きずるのを許容するよう奨励されます。) メールボックスの地方の部分の構文はセクション4.1.2で指定された受信機サイトコンベンションと構文に従わなければなりません。 以下でSMTPコマンドについて議論します。 セクション4.2でSMTP回答について議論します。
A mail transaction involves several data objects which are communicated as arguments to different commands. The reverse-path is the argument of the MAIL command, the forward-path is the argument of the RCPT command, and the mail data is the argument of the DATA command. These arguments or data objects must be transmitted and held pending the confirmation communicated by the end of mail data indication which finalizes the transaction. The model for this is that distinct buffers are provided to hold the types of data objects, that is, there is a reverse-path buffer, a forward-path buffer, and a mail data buffer. Specific commands cause information to be appended to a specific buffer, or cause one or more buffers to be cleared.
メールトランザクションは議論として異なったコマンドに伝えられる数個のデータ・オブジェクトにかかわります。 逆経路はメールコマンドの議論です、そして、フォワードパスはRCPTコマンドの議論です、そして、メールデータはDATAコマンドの議論です。 トランザクションを成立させるメールデータ指示の終わりまでに伝えられた確認までこれらの議論かデータ・オブジェクトを伝えられて、持たなければなりません。 これのためのモデルがデータ・オブジェクトのタイプを保持するために異なったバッファを提供するということである、すなわち、逆経路バッファ、フォワードパスバッファ、およびメールデータバッファがあります。 特定のコマンドで、クリアされるために特定のバッファ、またはより多くの原因1バッファに情報を追加します。
Several commands (RSET, DATA, QUIT) are specified as not permitting parameters. In the absence of specific extensions offered by the server and accepted by the client, clients MUST NOT send such parameters and servers SHOULD reject commands containing them as having invalid syntax.
いくつかのコマンド(RSET、DATA、QUIT)はどんな可能にするパラメタとしても指定されません。 サーバによって提供されて、クライアントによって受け入れられた特定の拡大がないときクライアントがそのようなパラメタとサーバを送ってはいけないので、SHOULDは無効の構文を持っているとしてそれらを含むコマンドを拒絶します。
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
こんにちは、(EHLO)か4.1.1.1 広げられて、こんにちは(HELO)
These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is
これらのコマンドは、SMTPクライアントをSMTPサーバーに特定するのに使用されます。1つが利用可能であるなら、議論分野はSMTPクライアントの完全修飾ドメイン名を含んでいます。 SMTPクライアントシステムが重要なドメイン名を持っていない状況、(例えば、ダイナミックにアドレスを割り当てて、どんな逆のマッピング記録も割り当てません。
Klensin Standards Track [Page 29] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[29ページ]RFC2821
available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. y The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command.
利用可能である、)、クライアントSHOULDが文字通り(セクション4.1.3を見る)の、そして、クライアントシステムを特定するのを助ける情報が任意にあとに続くアドレスを送る、y、SMTPサーバーは接続挨拶回答とこのコマンドへの応答でSMTPクライアントにそれ自体を特定します。
A client SMTP SHOULD start an SMTP session by issuing the EHLO command. If the SMTP server supports the SMTP service extensions it will give a successful response, a failure response, or an error response. If the SMTP server, in violation of this specification, does not support any SMTP service extensions it will generate an error response. Older client SMTP systems MAY, as discussed above, use HELO (as specified in RFC 821) instead of EHLO, and servers MUST support the HELO command and reply properly to it. In any event, a client MUST issue HELO or EHLO before starting a mail transaction.
クライアントSMTP SHOULDは、EHLOコマンドを発行することによって、SMTPセッションを始めます。 SMTPサーバーがSMTPをサポートするなら、それがうまくいっている応答、失敗応答、または誤り応答を与える拡大を修理してください。 SMTPサーバーが、この仕様を違反してどんなSMTPサービスも拡大であるとサポートしないと、それは誤り応答を生成するでしょう。 より古いクライアントSMTPシステムがEHLOの代わりに上で議論するようにHELOを使用するかもしれなくて(RFC821で指定されるように)、サーバは、HELOがコマンドであるとサポートして、適切にそれに答えなければなりません。 とにかく、メールトランザクションを始める前に、クライアントはHELOかEHLOを発行しなければなりません。
These commands, and a "250 OK" reply to one of them, confirm that both the SMTP client and the SMTP server are in the initial state, that is, there is no transaction in progress and all state tables and buffers are cleared.
これらのコマンド、およびそれらの1つに関する「250OK」回答は、SMTPクライアントとSMTPサーバーの両方が初期状態にあると確認します、そして、すなわち、進行中のどんなトランザクションもありません、そして、すべてのステートテーブルとバッファはきれいにされます。
Syntax:
構文:
ehlo = "EHLO" SP Domain CRLF
helo = "HELO" SP Domain CRLF
"EHLO"SPドメインehlo=CRLF heloは"HELO"SPドメインCRLFと等しいです。
Normally, the response to EHLO will be a multiline reply. Each line of the response contains a keyword and, optionally, one or more parameters. Following the normal syntax for multiline replies, these keyworks follow the code (250) and a hyphen for all but the last line, and the code and a space for the last line. The syntax for a positive response, using the ABNF notation and terminal symbols of [8], is:
通常、EHLOへの応答はマルチライン回答になるでしょう。 応答の各系列はキーワードと任意に1つ以上のパラメタを含んでいます。 マルチライン回答のための正常な構文に従って、これらのkeyworksは最終ライン以外のすべてのためにコード(250)とハイフンに従って、コードとスペースに最終ラインに従います。 積極的な応答のための構文([8]のABNF記法を使用して、終端記号)は、以下の通りです。
ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF )
/ ( "250-" domain [ SP ehlo-greet ] CRLF
*( "250-" ehlo-line CRLF )
"250" SP ehlo-line CRLF )
ehloの間違いないrspは/と等しいです(「250」ドメイン[SP ehlo挨拶する]CRLF)。(「250」ドメイン[SP ehlo挨拶する]CRLF*(「250」ehlo-系列CRLF)「250」SP ehlo-系列CRLF)
ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
; string of any characters other than CR or LF
=1*(%d0-9/%d11-12/%d14-127)にehlo挨拶してください。 CRかLF以外のどんなキャラクタのストリング
ehlo-line = ehlo-keyword *( SP ehlo-param )
ehlo-系列=ehlo-キーワード*(SP ehlo-param)
ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
; additional syntax of ehlo-params depends on
; ehlo-keyword
ehlo-キーワード=(アルファー/DIGIT)*(ALPHA / DIGIT /「-」)。 ehlo-paramsの追加構文がよる、。 ehlo-キーワード
Klensin Standards Track [Page 30] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[30ページ]RFC2821
ehlo-param = 1*(%d33-127)
; any CHAR excluding <SP> and all
; control characters (US-ASCII 0-31 inclusive)
ehlo-param=1*(%d33-127)。 <SP>を除いたどんなCHARとすべて。 制御文字(米国-ASCII0-31包括的)です。
Although EHLO keywords may be specified in upper, lower, or mixed case, they MUST always be recognized and processed in a case- insensitive manner. This is simply an extension of practices specified in RFC 821 and section 2.4.1.
EHLOキーワードは上側の、または、下側の、または、複雑な場合で指定されるかもしれませんが、ケースの神経の鈍い方法でそれらをいつも認識されて、処理しなければなりません。 これは単にRFC821とセクション2.4.1で指定された習慣の拡大です。
4.1.1.2 MAIL (MAIL)
4.1.1.2 メール(メール)
This command is used to initiate a mail transaction in which the mail data is delivered to an SMTP server which may, in turn, deliver it to one or more mailboxes or pass it on to another system (possibly using SMTP). The argument field contains a reverse-path and may contain optional parameters. In general, the MAIL command may be sent only when no mail transaction is in progress, see section 4.1.4.
このコマンドは、メールデータが順番に1個以上のメールボックスにそれを提供するか、または別のシステムにそれを通過するかもしれないSMTPサーバーに提供されるメールトランザクションを開始するのに使用されます(ことによるとSMTPを使用して)。 議論分野は、逆経路を含んでいて、任意のパラメタを含むかもしれません。 セクション4.1.4は、メールトランザクションが全く進行していないときだけ、一般に、メールコマンドが送られるかもしれないのを見ます。
The reverse-path consists of the sender mailbox. Historically, that mailbox might optionally have been preceded by a list of hosts, but that behavior is now deprecated (see appendix C). In some types of reporting messages for which a reply is likely to cause a mail loop (for example, mail delivery and nondelivery notifications), the reverse-path may be null (see section 3.7).
逆経路は送付者メールボックスから成ります。 歴史的に、ホストのリストは任意にそのメールボックスに先行したかもしれませんが、その振舞いは現在、推奨しないです(付録Cを見てください)。 中では、回答がaメールを引き起こしそうであるメッセージを報告する何人かのタイプが輪にする、(例えば、郵便配達と不着損害通知)、逆経路はヌルであるかもしれません(セクション3.7を見てください)。
This command clears the reverse-path buffer, the forward-path buffer, and the mail data buffer; and inserts the reverse-path information from this command into the reverse-path buffer.
このコマンドは逆経路バッファ、フォワードパスバッファ、およびメールデータバッファをきれいにします。 そして、逆経路へのこのコマンドからの逆経路情報がバッファリングする差し込み。
If service extensions were negotiated, the MAIL command may also carry parameters associated with a particular service extension.
また、サービス拡大が交渉されたなら、メールコマンドは特定のサービス拡大に関連しているパラメタを運ぶかもしれません。
Syntax:
構文:
"MAIL FROM:" ("<>" / Reverse-Path)
[SP Mail-parameters] CRLF
「メールFROM:」 (逆「<>」/経路) [SPメールパラメタ] CRLF
4.1.1.3 RECIPIENT (RCPT)
4.1.1.3 受取人(RCPT)
This command is used to identify an individual recipient of the mail data; multiple recipients are specified by multiple use of this command. The argument field contains a forward-path and may contain optional parameters.
このコマンドはメールデータの個々の受取人を特定するのに使用されます。 複数の受取人はこのコマンドの複数の使用で指定されます。 議論分野は、フォワードパスを含んでいて、任意のパラメタを含むかもしれません。
The forward-path normally consists of the required destination mailbox. Sending systems SHOULD not generate the optional list of hosts known as a source route. Receiving systems MUST recognize
通常、フォワードパスは必要なあて先メールボックスから成ります。 送付システムSHOULDは送信元経路として知られているホストの任意のリストを生成しません。 システムが認識しなければならない受信
Klensin Standards Track [Page 31] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[31ページ]RFC2821
source route syntax but SHOULD strip off the source route specification and utilize the domain name associated with the mailbox as if the source route had not been provided.
まるで送信元経路が提供されていないかのように、送信元経路の構文にもかかわらず、SHOULDは送信元経路仕様を全部はぎ取って、メールボックスに関連しているドメイン名を利用します。
Similarly, relay hosts SHOULD strip or ignore source routes, and names MUST NOT be copied into the reverse-path. When mail reaches its ultimate destination (the forward-path contains only a destination mailbox), the SMTP server inserts it into the destination mailbox in accordance with its host mail conventions.
同様に、中継ホストSHOULDは送信元経路を剥取るか、または無視します、そして、名前は逆経路にコピーされてはいけません。 メールが最終仕向地に達すると(フォワードパスはあて先メールボックスだけを含んでいます)、ホストメールコンベンションによると、SMTPサーバーはあて先メールボックスの中にそれを挿入します。
For example, mail received at relay host xyz.com with envelope commands
例えば、メールは中継ホストxyz.comで封筒コマンドで受信されました。
MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
FROM:<userx@y.foo.org に郵送してください、gt;、@jkl.org: RCPT TO:<@hosta.int 、 userc@d.bar.org 、gt。
will normally be sent directly on to host d.bar.org with envelope commands
通常、封筒コマンドと共に直接ホストd.bar.orgに送るでしょう。
MAIL FROM:<userx@y.foo.org>
RCPT TO:<userc@d.bar.org>
FROM:<userx@y.foo.org に郵送してください、gt;、RCPT TO:<userc@d.bar.org 、gt。
As provided in appendix C, xyz.com MAY also choose to relay the message to hosta.int, using the envelope commands
付録Cに供給するように、また、封筒コマンドを使用して、xyz.comは、hosta.intにメッセージをリレーするのを選ぶかもしれません。
MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
FROM:<userx@y.foo.org に郵送してください、gt;、@jkl.org: RCPT TO:<@hosta.int 、 userc@d.bar.org 、gt。
or to jkl.org, using the envelope commands
または、jkl.orgに、封筒を使用するのは命令します。
MAIL FROM:<userx@y.foo.org>
RCPT TO:<@jkl.org:userc@d.bar.org>
FROM:<userx@y.foo.org に郵送してください、gt;、RCPT TO:<@jkl.org : userc@d.bar.org>。
Of course, since hosts are not required to relay mail at all, xyz.com may also reject the message entirely when the RCPT command is received, using a 550 code (since this is a "policy reason").
もちろん、ホストが全くメールをリレーする必要はないので、また、完全にRCPTコマンドが受け取られているとき、xyz.comはメッセージを拒絶するかもしれません、550コードを使用して(これが「方針理由」であるので)。
If service extensions were negotiated, the RCPT command may also carry parameters associated with a particular service extension offered by the server. The client MUST NOT transmit parameters other than those associated with a service extension offered by the server in its EHLO response.
また、サービス拡大が交渉されたなら、RCPTコマンドはサーバで提供する特定のサービス拡大に関連しているパラメタを運ぶかもしれません。クライアントはEHLO応答におけるサーバで提供するサービス拡大に関連づけられたもの以外のパラメタを伝えてはいけません。
Syntax:
"RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path)
[SP Rcpt-parameters] CRLF
構文: 「RCPT TO:」 (「<郵便局長@」ドメイン">"/「<郵便局長>」/フォワードパス) [SP Rcpt-パラメタ] CRLF
Klensin Standards Track [Page 32] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[32ページ]RFC2821
4.1.1.4 DATA (DATA)
4.1.1.4 データ(データ)
The receiver normally sends a 354 response to DATA, and then treats the lines (strings ending in <CRLF> sequences, as described in section 2.3.7) following the command as mail data from the sender. This command causes the mail data to be appended to the mail data buffer. The mail data may contain any of the 128 ASCII character codes, although experience has indicated that use of control characters other than SP, HT, CR, and LF may cause problems and SHOULD be avoided when possible.
受信機は、通常、354応答をDATAに送って、メールデータとしてコマンドに続いて、次に、送付者から系列(セクション2.3.7で説明されるように<CRLF>系列に終わるストリング)を扱います。 このコマンドで、メールデータバッファにメールデータを追加します。 メールデータは128のASCII文字コードのどれかを含むかもしれなくて、経験は、SP、HT、CR、およびLF以外の制御文字の使用が問題とSHOULDを引き起こすかもしれないのを示しましたが、可能であるときには避けられてください。
The mail data is terminated by a line containing only a period, that is, the character sequence "<CRLF>.<CRLF>" (see section 4.5.2). This is the end of mail data indication. Note that the first <CRLF> of this terminating sequence is also the <CRLF> that ends the final line of the data (message text) or, if there was no data, ends the DATA command itself. An extra <CRLF> MUST NOT be added, as that would cause an empty line to be added to the message. The only exception to this rule would arise if the message body were passed to the originating SMTP-sender with a final "line" that did not end in <CRLF>; in that case, the originating SMTP system MUST either reject the message as invalid or add <CRLF> in order to have the receiving SMTP server recognize the "end of data" condition.
メールデータはすなわち、期間だけを含む系列、キャラクタシーケンス「<CRLF><CRLF>」によって終えられます(セクション4.5.2を見てください)。 これはメールデータ指示の終わりです。 また、系列を終えるこの最初の<CRLF>がデータ(メッセージ・テキスト)の最終的な系列を終わらせるか、またはデータが全くなかったならDATAコマンド自体を終わらせる<CRLF>であることに注意してください。 CRLF>がそうしなければならない付加的な<が加えられないで、それが引き起こすように空の系列がメッセージに追加されることを引き起こしてください。 メッセージ本体が<CRLF>に終わらなかった最終的な「系列」で起因しているSMTP-送付者に渡されるなら、この規則への唯一の例外が起こるでしょうに。 その場合、受信SMTPサーバーに「データの終わり」状態を認識させるように、起因しているSMTPシステムは、メッセージが無効であると拒絶しなければならないか、または<CRLF>を言い足さなければなりません。
The custom of accepting lines ending only in <LF>, as a concession to non-conforming behavior on the part of some UNIX systems, has proven to cause more interoperability problems than it solves, and SMTP server systems MUST NOT do this, even in the name of improved robustness. In particular, the sequence "<LF>.<LF>" (bare line feeds, without carriage returns) MUST NOT be treated as equivalent to <CRLF>.<CRLF> as the end of mail data indication.
いくつかのUNIXシステム側の譲歩として<LF>だけに終わる系列を非の従うことの振舞いに認める習慣は解決するより多くの相互運用性問題を引き起こすと判明しました、そして、SMTPサーバーシステムはこれをしてはいけません、改良された丈夫さの名にかけてさえ。 特に、メールデータ指示の終わりとして系列「<LF><LF>」(復帰のないむき出しの改行)を<CRLF><CRLF>と同等物として扱ってはいけません。
Receipt of the end of mail data indication requires the server to process the stored mail transaction information. This processing consumes the information in the reverse-path buffer, the forward-path buffer, and the mail data buffer, and on the completion of this command these buffers are cleared. If the processing is successful, the receiver MUST send an OK reply. If the processing fails the receiver MUST send a failure reply. The SMTP model does not allow for partial failures at this point: either the message is accepted by the server for delivery and a positive response is returned or it is not accepted and a failure reply is returned. In sending a positive completion reply to the end of data indication, the receiver takes full responsibility for the message (see section 6.1). Errors that are diagnosed subsequently MUST be reported in a mail message, as discussed in section 4.4.
メールデータ指示の終わりの領収書は、保存されたメールトランザクション情報を処理するためにサーバを必要とします。 この処理は逆経路バッファ、フォワードパスバッファ、およびメールデータバッファの情報を消費します、そして、このコマンドの完成のときに、これらのバッファはきれいにされます。 処理がうまくいくなら、受信機はOK回答を送らなければなりません。 処理が失敗するなら、受信機は失敗回答を送らなければなりません。 SMTPモデルはここに部分的な失敗を考慮しません: 配送のためのサーバでメッセージを受け入れます、そして、それを受け入れません、そして、積極的な応答を返すか、または失敗回答を返します。 積極的な完成回答をデータ指示の終わりに送る際に、受信機はメッセージへの完全な責任を取ります(セクション6.1を見てください)。 セクション4.4で議論するような次に診断されて、メール・メッセージで報告しなければならないということである誤り。
Klensin Standards Track [Page 33] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[33ページ]RFC2821
When the SMTP server accepts a message either for relaying or for final delivery, it inserts a trace record (also referred to interchangeably as a "time stamp line" or "Received" line) at the top of the mail data. This trace record indicates the identity of the host that sent the message, the identity of the host that received the message (and is inserting this time stamp), and the date and time the message was received. Relayed messages will have multiple time stamp lines. Details for formation of these lines, including their syntax, is specified in section 4.4.
SMTPサーバーがリレーか最終的な配送へのメッセージを受け入れるとき、それはメールデータの先端で跡の記録(また、「タイムスタンプ系列」か「受け取られていている」系列に互換性を持って言及される)を挿入します。 この跡の記録は、メッセージ、メッセージ(これを挿入するのは、タイムスタンプである)を受け取ったホストのアイデンティティ、および日時にメッセージを送ったホストのアイデンティティが受け取られたのを示します。 リレーされたメッセージには、複数のタイムスタンプ系列があるでしょう。 それらの構文を含むこれらの系列の構成のための詳細はセクション4.4で指定されます。
Additional discussion about the operation of the DATA command appears in section 3.3.
DATAコマンドの操作についての追加議論はセクション3.3に現れます。
Syntax:
"DATA" CRLF
構文: 「データ」CRLF
4.1.1.5 RESET (RSET)
4.1.1.5 リセット(RSET)
This command specifies that the current mail transaction will be aborted. Any stored sender, recipients, and mail data MUST be discarded, and all buffers and state tables cleared. The receiver MUST send a "250 OK" reply to a RSET command with no arguments. A reset command may be issued by the client at any time. It is effectively equivalent to a NOOP (i.e., if has no effect) if issued immediately after EHLO, before EHLO is issued in the session, after an end-of-data indicator has been sent and acknowledged, or immediately before a QUIT. An SMTP server MUST NOT close the connection as the result of receiving a RSET; that action is reserved for QUIT (see section 4.1.1.10).
このコマンドは、現在のメールトランザクションが中止されると指定します。 どんな保存された送付者、受取人、およびメールデータも捨てなければなりませんでした、そして、すべてのバッファとステートテーブルはきれいにされました。 受信機は議論なしで「250OK」回答をRSETコマンドに送らなければなりません。 リセットコマンドはいつでも、クライアントによって発行されるかもしれません。 すなわち、事実上、それがNOOPに同等である、(効果がありません) EHLO直後発行されるなら、以前、EHLOはセッション、データのエンドインディケータが送られて、承認された後またはQUITの直前発行されます。 SMTPサーバーはRSETを受けるという結果として接続を終えてはいけません。 セクション4.1を見てください。その動作がQUITのために控えられる、(.1 .10)。
Since EHLO implies some additional processing and response by the server, RSET will normally be more efficient than reissuing that command, even though the formal semantics are the same.
EHLOが、通常、何らかの追加処理とサーバによる応答、RSETがそれを再発行するより効率的になるのを含意するので、正式な意味論ですが、同じくらいがそうであると命令してください。
There are circumstances, contrary to the intent of this specification, in which an SMTP server may receive an indication that the underlying TCP connection has been closed or reset. To preserve the robustness of the mail system, SMTP servers SHOULD be prepared for this condition and SHOULD treat it as if a QUIT had been received before the connection disappeared.
事情があります、この仕様の意図とは逆に。そこでは、SMTPサーバーが基本的なTCP接続が閉店するか、またはリセットされたという指示を受けるかもしれません。 メールシステム、SMTPプロトコルのサーバSHOULDの丈夫さを保存するために、この状態のために用意してください。そうすれば、SHOULDはまるで接続が姿を消す前にQUITを受け取ったかのようにそれを扱います。
Syntax:
"RSET" CRLF
構文: "RSET"CRLF
Klensin Standards Track [Page 34] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[34ページ]RFC2821
4.1.1.6 VERIFY (VRFY)
4.1.1.6、検証(VRFY)
This command asks the receiver to confirm that the argument identifies a user or mailbox. If it is a user name, information is returned as specified in section 3.5.
このコマンドは、議論がユーザかメールボックスを特定すると確認するように受信機に頼みます。 それがユーザ名であるなら、セクション3.5で指定されるように情報を返します。
This command has no effect on the reverse-path buffer, the forward- path buffer, or the mail data buffer.
このコマンドは逆経路バッファ、前進の経路バッファ、またはメールデータバッファの上で効き目がありません。
Syntax:
"VRFY" SP String CRLF
構文: "VRFY"SPストリングCRLF
4.1.1.7 EXPAND (EXPN)
4.1.1.7 広がってください。(EXPN)
This command asks the receiver to confirm that the argument identifies a mailing list, and if so, to return the membership of that list. If the command is successful, a reply is returned containing information as described in section 3.5. This reply will have multiple lines except in the trivial case of a one-member list.
このコマンドは、議論がメーリングリストを特定すると確認して、そうだとすれば、そのリストの会員資格を返すように受信機に頼みます。 コマンドがうまくいくなら、セクション3.5で説明されるように情報を含んでいて、回答を返します。 この回答には、1メンバーのリストの些細なケース以外の複数の系列があるでしょう。
This command has no effect on the reverse-path buffer, the forward- path buffer, or the mail data buffer and may be issued at any time.
このコマンドは逆経路バッファ、前進の経路バッファ、またはメールデータバッファの上で効き目がなくて、いつでも、発行するかもしれません。
Syntax:
"EXPN" SP String CRLF
構文: "EXPN"SPストリングCRLF
4.1.1.8 HELP (HELP)
4.1.1.8 ヘルプ(助け)
This command causes the server to send helpful information to the client. The command MAY take an argument (e.g., any command name) and return more specific information as a response.
このコマンドで、サーバは役立つ情報をクライアントに送ります。 コマンドは、主張(例えばどんなコマンド名も)を取って、応答として、より特定の情報を返すかもしれません。
This command has no effect on the reverse-path buffer, the forward- path buffer, or the mail data buffer and may be issued at any time.
このコマンドは逆経路バッファ、前進の経路バッファ、またはメールデータバッファの上で効き目がなくて、いつでも、発行するかもしれません。
SMTP servers SHOULD support HELP without arguments and MAY support it with arguments.
SMTPプロトコルのサーバSHOULDサポートヘルプと議論なしで5月は議論でそれをサポートします。
Syntax:
"HELP" [ SP String ] CRLF
構文: 「助け」[SPストリング]CRLF
4.1.1.9 NOOP (NOOP)
4.1.1.9 NOOP(NOOP)
This command does not affect any parameters or previously entered commands. It specifies no action other than that the receiver send an OK reply.
このコマンドは少しのパラメタや以前に入力されたコマンドにも影響しません。 受信機がOK回答を送る以外に、それは動作を全く指定しません。
Klensin Standards Track [Page 35] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[35ページ]RFC2821
This command has no effect on the reverse-path buffer, the forward- path buffer, or the mail data buffer and may be issued at any time. If a parameter string is specified, servers SHOULD ignore it.
このコマンドは逆経路バッファ、前進の経路バッファ、またはメールデータバッファの上で効き目がなくて、いつでも、発行するかもしれません。 パラメタストリングが指定されるなら、サーバSHOULDはそれを無視します。
Syntax:
"NOOP" [ SP String ] CRLF
構文: "NOOP"[SPストリング]CRLF
4.1.1.10 QUIT (QUIT)
4.1.1.10 やめてください。(やめます)
This command specifies that the receiver MUST send an OK reply, and then close the transmission channel.
このコマンドは、受信機がOK回答を送って、次に、トランスミッションチャンネルを閉じなければならないと指定します。
The receiver MUST NOT intentionally close the transmission channel until it receives and replies to a QUIT command (even if there was an error). The sender MUST NOT intentionally close the transmission channel until it sends a QUIT command and SHOULD wait until it receives the reply (even if there was an error response to a previous command). If the connection is closed prematurely due to violations of the above or system or network failure, the server MUST cancel any pending transaction, but not undo any previously completed transaction, and generally MUST act as if the command or transaction in progress had received a temporary error (i.e., a 4yz response).
受信機は故意にQUITコマンドに受けて、答えるまで(誤りがあったとしても)トランスミッションチャンネルを閉じてはいけません。 QUITコマンドを送って、回答を受け取るまで(前のコマンドへの誤り応答があったとしても)SHOULDが待つまで、送付者は故意にトランスミッションチャンネルを閉じてはいけません。 接続が早まって、違反のため上記で閉じられるか、そして、システムかネットワーク失敗、サーバがどんな未定のトランザクションも取り消さなければなりません、どんな以前に完成したトランザクションも元に戻さないで、まるで進行中のコマンドかトランザクションが一時的な誤り(すなわち、4yz応答)を受けたかのように一般に、行動しなければならないのを除いて。
The QUIT command may be issued at any time.
いつでも、QUITコマンドを発行するかもしれません。
Syntax:
"QUIT" CRLF
構文: 「やめてください」CRLF
4.1.2 Command Argument Syntax
4.1.2 コマンド議論構文
The syntax of the argument fields of the above commands (using the syntax specified in [8] where applicable) is given below. Some of the productions given below are used only in conjunction with source routes as described in appendix C. Terminals not defined in this document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in the "core" syntax [8 (section 6)] or in the message format syntax [32].
上のコマンド(適切であるところで[8]で指定された構文を使用する)の議論分野の構文を以下に与えます。 以下に与えられた創作のいくつかが付録C.で説明されるように送信元経路に関連してだけ使用されます。アルファーなどのように本書では定義されなかったTerminals、DIGIT、SP、CR、LF(CRLF)が「コア」構文[8(セクション6)]で定義されるか、メッセージ・フォーマット構文[32]であります。
Reverse-path = Path
Forward-path = Path
Path = "<" [ A-d-l ":" ] Mailbox ">"
A-d-l = At-domain *( "," A-d-l )
; Note that this form, the so-called "source route",
; MUST BE accepted, SHOULD NOT be generated, and SHOULD be
; ignored.
At-domain = "@" domain
Mail-parameters = esmtp-param *(SP esmtp-param)
Rcpt-parameters = esmtp-param *(SP esmtp-param)
「逆経路=経路経路フォワードパス=経路="<"、[d l」、:、」、]、メールボックス">"d lがドメインの*と等しい、(「」 d l)、。 このフォーム、そのいわゆる「送信元経路」に注意してください。 SHOULD NOT、受け入れなければならない、生成されてください、SHOULD、いてください。 無視にされる。 ドメインの="@"ドメインメールパラメタはesmtp-param*(SP esmtp-param)Rcpt-パラメタ=esmtp-param*と等しいです。(SP esmtp-param)
Klensin Standards Track [Page 36] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[36ページ]RFC2821
esmtp-param = esmtp-keyword ["=" esmtp-value]
esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
esmtp-value = 1*(%d33-60 / %d62-127)
; any CHAR excluding "=", SP, and control characters
Keyword = Ldh-str
Argument = Atom
Domain = (sub-domain 1*("." sub-domain)) / address-literal
sub-domain = Let-dig [Ldh-str]
esmtp-paramはesmtp-キーワード[esmtp-値と「等しい」]esmtp-キーワード=(アルファー/ケタ)*(アルファ/ケタ/「-」)esmtp-値=1*(%d33-60/%d62-127)と等しいです。 原子「=」を除いたどんなCHAR、SP、および制御文字キーワード=Ldh-str議論も=ドメインが等しい、(サブドメイン1*、(「. 」 サブドメイン) /アドレスリテラルサブドメイン=、皮肉をさせます。[Ldh-str]
address-literal = "[" IPv4-address-literal /
IPv6-address-literal /
General-address-literal "]"
; See section 4.1.3
「[「一般アドレスIPv6アドレスIPv4アドレスリテラル/リテラル/リテラル」]」というアドレスリテラル=。 セクション4.1.3を見てください。
Mailbox = Local-part "@" Domain
メールボックス=地方の部分"@"ドメイン
Local-part = Dot-string / Quoted-string
; MAY be case-sensitive
地方の部分はドットストリング/引用文字列と等しいです。 大文字と小文字を区別しているかもしれません。
Dot-string = Atom *("." Atom)
ドットストリング=原子*(「. 」 原子、)
Atom = 1*atext
原子=1*atext
Quoted-string = DQUOTE *qcontent DQUOTE
引用文字列=DQUOTE*qcontent DQUOTE
String = Atom / Quoted-string
ストリング=原子/引用文字列
While the above definition for Local-part is relatively permissive, for maximum interoperability, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form or where the Local-part is case- sensitive. For any purposes that require generating or comparing Local-parts (e.g., to specific mailbox names), all quoted forms MUST be treated as equivalent and the sending system SHOULD transmit the form that uses the minimum quoting possible.
Local-部分のための上の定義が比較的寛大である間、最大限のインターオペラビリティ、受信すると予想するホストに関して、メールSHOULDは、Local-部分がQuoted-ストリングフォームを必要とするか、またはLocal-部分がケース敏感である(または、用途)メールボックスを定義するのを避けます。 Local-部品(例えば、特定のメールボックス名への)を生成するか、または比較するのを必要とするどんな目的のためにも、すべてが、同等物としてフォームを扱わなければならないのを引用しました、そして、送付システムSHOULDは可能な最小の引用を使用する書式を伝えます。
Systems MUST NOT define mailboxes in such a way as to require the use in SMTP of non-ASCII characters (octets with the high order bit set to one) or ASCII "control characters" (decimal value 0-31 and 127). These characters MUST NOT be used in MAIL or RCPT commands or other commands that require mailbox names.
システムはメールボックスを非ASCII文字(高位のビットによる八重奏は1つにセットしました)かASCII「制御文字」(デシマル値0-31と127)のSMTPにおける使用を必要とするほどそのような方法で定義してはいけません。 メールボックス名を必要とするメール、RCPTコマンドまたは他のコマンドにこれらのキャラクタを使用してはいけません。
Note that the backslash, "\", is a quote character, which is used to indicate that the next character is to be used literally (instead of its normal interpretation). For example, "Joe\,Smith" indicates a single nine character user field with the comma being the fourth character of the field.
「\」というバックスラッシュが引用文字であることに注意してください。(その引用文字は、次のキャラクタが文字通り(通常の解釈の代わりに)使用されることになっているのを示すのに使用されます)。 例えば、「ジョー\、スミス」は分野の4番目のキャラクタであるコンマでただ一つの9キャラクタユーザ分野を示します。
Klensin Standards Track [Page 37] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[37ページ]RFC2821
To promote interoperability and consistent with long-standing guidance about conservative use of the DNS in naming and applications (e.g., see section 2.3.1 of the base DNS document, RFC1035 [22]), characters outside the set of alphas, digits, and hyphen MUST NOT appear in domain name labels for SMTP clients or servers. In particular, the underscore character is not permitted. SMTP servers that receive a command in which invalid character codes have been employed, and for which there are no other reasons for rejection, MUST reject that command with a 501 response.
促進する、相互運用性で長年の指導と命名とアプリケーションにおけるDNSの保守的な使用に関して一致する、(例えば、ベースDNSドキュメント、RFC1035[22])、アルファのセットの外におけるキャラクタ、ケタ、および.1のセクション2.3ハイフンがドメイン名ラベルにSMTPクライアントかサーバに関して現れてはいけないのを確実にしてください。 特に、強調キャラクタは受入れられません。 どの無効のキャラクタコードでコマンドを受け取るSMTPサーバーが使われて、何か他のものがどれがあるように拒絶のために推論して、501応答によるそのコマンドを拒絶してはいけないかをそうされます。
4.1.3 Address Literals
4.1.3 アドレスリテラル
Sometimes a host is not known to the domain name system and communication (and, in particular, communication to report and repair the error) is blocked. To bypass this barrier a special literal form of the address is allowed as an alternative to a domain name. For IPv4 addresses, this form uses four small decimal integers separated by dots and enclosed by brackets such as [123.255.37.2], which indicates an (IPv4) Internet Address in sequence-of-octets form. For IPv6 and other forms of addressing that might eventually be standardized, the form consists of a standardized "tag" that identifies the address syntax, a colon, and the address itself, in a format specified as part of the IPv6 standards [17].
時々、ホストはドメイン名システムに知られていません、そして、コミュニケーション(誤りを報告して、修理する特にコミュニケーション)は妨げられます。 このバリアを迂回させるために、アドレスの特別な文字通りのフォームはドメイン名に代わる手段として許容されています。 IPv4アドレスに、このフォームがわずかな10進ドットで切り離している、同封の整数がそのようなものに腕木を付ける4を使用する、[123.255 .37 .2] 八重奏の系列の(IPv4)インターネットAddressが形成するのを示す。 結局標準化されるかもしれないIPv6と他の用紙のアドレシングのために、フォームはアドレス構文、コロン、およびアドレス自体を特定する標準化された「タグ」から成ります、IPv6規格[17]の一部として指定された形式で。
Specifically:
明確に:
IPv4-address-literal = Snum 3("." Snum)
IPv6-address-literal = "IPv6:" IPv6-addr
General-address-literal = Standardized-tag ":" 1*dcontent
Standardized-tag = Ldh-str
; MUST be specified in a standards-track RFC
; and registered with IANA
IPv4アドレスリテラル=Snum3、(「. 」 Snum) IPv6アドレスリテラル=、「IPv6:」 「IPv6-addrの一般アドレスリテラルは標準化されたタグと等しい」:、」 1*dcontentの標準化されたタグはLdh-strと等しいです。 標準化過程RFCで指定しなければなりません。 そして、IANAに登録にされる
Snum = 1*3DIGIT ; representing a decimal integer
; value in the range 0 through 255
Let-dig = ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
Snumは1*3DIGITと等しいです。 10進整数を表します。 範囲で皮肉をさせて0〜255Let-皮肉=アルファー/DIGIT Ldh-str=*(アルファー/ DIGIT /「-」)を評価してください。
IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
IPv6-hex = 1*4HEXDIG
IPv6-full = IPv6-hex 7(":" IPv6-hex)
IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":"
IPv6-hex)]
; The "::" represents at least 2 16-bit groups of zeros
; No more than 6 groups in addition to the "::" may be
; present
IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
「IPv6-addrはIPv6完全であるかIPv6v4いっぱいなIPv6-コンピュータ/IPv6v4/コンピュータIPv6-十六進法=1*4HEXDIG IPv6完全な=IPv6-十六進法7(「:」 IPv6-十六進法)IPv6-コンピュータ=[IPv6-十六進法*5(「:」 IPv6-十六進法)]と等しい」:、:、」 [IPv6-十六進法*5(「:」 IPv6-十六進法)]。 「The」、:、:、」 少なくとも2つのゼロ人の16ビットのグループを代表します。 に加えて「6つ未満のグループ、」、:、:、」 あるかもしれません。 「IPv6-十六進法いっぱいな現在のIPv6v4=5(「:」 IPv6-十六進法)」:、」 「IPv4アドレスリテラルIPv6v4-コンピュータ=[IPv6-十六進法*3(「:」 IPv6-十六進法)]」:、:、」
Klensin Standards Track [Page 38] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[38ページ]RFC2821
[IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal
; The "::" represents at least 2 16-bit groups of zeros
; No more than 4 groups in addition to the "::" and
; IPv4-address-literal may be present
「[IPv6-十六進法*3(「:」 IPv6-十六進法)、」、:、」、]、IPv4はリテラルを扱います。 「The」、:、:、」 少なくとも2つのゼロ人の16ビットのグループを代表します。 に加えて「4つ未満のグループ、」、:、:、」 そして、。 IPv4アドレスリテラルは存在しているかもしれません。
4.1.4 Order of Commands
4.1.4 コマンドの注文
There are restrictions on the order in which these commands may be used.
これらのコマンドが使用されるかもしれないオーダーには制限があります。
A session that will contain mail transactions MUST first be initialized by the use of the EHLO command. An SMTP server SHOULD accept commands for non-mail transactions (e.g., VRFY or EXPN) without this initialization.
最初に、EHLOコマンドの使用でメールトランザクションを含むセッションを初期化しなければなりません。 SHOULDが受け入れるSMTPサーバーは非メールトランザクション(例えば、VRFYかEXPN)のためにこの初期化なしで命令します。
An EHLO command MAY be issued by a client later in the session. If it is issued after the session begins, the SMTP server MUST clear all buffers and reset the state exactly as if a RSET command had been issued. In other words, the sequence of RSET followed immediately by EHLO is redundant, but not harmful other than in the performance cost of executing unnecessary commands.
EHLOコマンドは後でのセッションにおけるクライアントによって発行されるかもしれません。 セッションが始まった後にそれが発行されるなら、SMTPサーバーは、まるでちょうどRSETコマンドを発行したかのようにすべてのバッファをきれいにして、状態をリセットしなければなりません。 言い換えれば、すぐEHLOによって続かれたRSETの系列は、余分ですが、不要なコマンドを実行する性能費用以外に、有害ではありません。
If the EHLO command is not acceptable to the SMTP server, 501, 500, or 502 failure replies MUST be returned as appropriate. The SMTP server MUST stay in the same state after transmitting these replies that it was in before the EHLO was received.
EHLOコマンドが許容できないなら、SMTPサーバー、501、500、または502に、適宜失敗回答を返さなければなりません。 それが以前にあったこれらの回答を伝えて、EHLOが受け取られていた後にSMTPサーバーは同じ状態にいなければなりません。
The SMTP client MUST, if possible, ensure that the domain parameter to the EHLO command is a valid principal host name (not a CNAME or MX name) for its host. If this is not possible (e.g., when the client's address is dynamically assigned and the client does not have an obvious name), an address literal SHOULD be substituted for the domain name and supplemental information provided that will assist in identifying the client.
できれば、SMTPクライアントは、EHLOコマンドへのドメインパラメタが有効なホストにとって、主要なホスト名(CNAMEでないMX名でない)であることを保証しなければなりません。 これは可能ではありません(例えば、クライアントには、いつ、クライアントのアドレスがダイナミックに割り当てられて、明白な名前がありませんか)、アドレスの文字通りのSHOULD。ドメイン名に代入されるのと補足的情報が、意志であればクライアントを特定するのを助けるということになってください。
An SMTP server MAY verify that the domain name parameter in the EHLO command actually corresponds to the IP address of the client. However, the server MUST NOT refuse to accept a message for this reason if the verification fails: the information about verification failure is for logging and tracing only.
SMTPサーバーは、EHLOコマンドにおけるドメイン名パラメタが実際にクライアントのIPアドレスに対応することを確かめるかもしれません。 しかしながら、検証が失敗するなら、サーバは、この理由でメッセージを受け入れるのを拒否してはいけません: 検証失敗の情報は伐採とたどるだけのものです。
The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time during a session, or without previously initializing a session. SMTP servers SHOULD process these normally (that is, not return a 503 code) even if no EHLO command has yet been received; clients SHOULD open a session with EHLO before sending these commands.
NOOP、ヘルプ、セッション、または以前にセッションを初期化しないで、いつでも、EXPN、VRFY、およびRSETコマンドを使用できます。 まだEHLOコマンドを全く受け取らないでも、通常(すなわち、503コードを返さない)、SMTPプロトコルのサーバSHOULDはこれらを処理します。 クライアントSHOULDはこれらのコマンドを送る前のEHLOと共に開会します。
Klensin Standards Track [Page 39] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[39ページ]RFC2821
If these rules are followed, the example in RFC 821 that shows "550 access denied to you" in response to an EXPN command is incorrect unless an EHLO command precedes the EXPN or the denial of access is based on the client's IP address or other authentication or authorization-determining mechanisms.
これらの規則が従われていて、EHLOコマンドがEXPNに先行しない場合、EXPNコマンドに対応して「あなたへの550アクセス拒否」を示しているRFC821の例が不正確であるか、またはアクセスの否定はクライアントのIPアドレス、他の認証または承認を決定するメカニズムに基づいています。
The MAIL command (or the obsolete SEND, SOML, or SAML commands) begins a mail transaction. Once started, a mail transaction consists of a transaction beginning command, one or more RCPT commands, and a DATA command, in that order. A mail transaction may be aborted by the RSET (or a new EHLO) command. There may be zero or more transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be sent if a mail transaction is already open, i.e., it should be sent only if no mail transaction had been started in the session, or it the previous one successfully concluded with a successful DATA command, or if the previous one was aborted with a RSET.
メールコマンド(または、時代遅れのSEND、SOML、またはSAMLコマンド)はメールトランザクションを始めます。 一度始められます、メールトランザクションはコマンド、1つ以上のRCPTコマンド、およびDATAコマンドを始めるトランザクションから成ります、そのオーダーで。 メールトランザクションはRSET(または、新しいEHLO)コマンドで中止されるかもしれません。 セッションにはゼロか、より多くのトランザクションがあるかもしれません。 メールトランザクションが既に開きます、セッションのときにメールトランザクションを全く始めていない場合にだけすなわち、それを送るということであるかそれがうまくいっているDATAコマンドで首尾よく結論づけられた前のものである、またはRSETと共に前のものを中止したなら、メール(または、SEND、SOML、またはSAML)を送ってはいけません。
If the transaction beginning command argument is not acceptable, a 501 failure reply MUST be returned and the SMTP server MUST stay in the same state. If the commands in a transaction are out of order to the degree that they cannot be processed by the server, a 503 failure reply MUST be returned and the SMTP server MUST stay in the same state.
コマンド議論を始めるトランザクションが許容できないなら、501失敗回答を返さなければなりません、そして、SMTPサーバーは同じ状態にいなければなりません。 トランザクションにおけるコマンドが度合いに不適切であるなら、サーバ、503失敗回答でそれらを処理できないのを返さなければなりません、そして、SMTPサーバーは同じ状態にいなければなりません。
The last command in a session MUST be the QUIT command. The QUIT command cannot be used at any other time in a session, but SHOULD be used by the client SMTP to request connection closure, even when no session opening command was sent and accepted.
セッションにおける持続コマンドはQUITコマンドであるに違いありません。 セッションのときに他の時ならいつでもQUITコマンドを使用できませんが、SHOULDが接続閉鎖を要求するのにクライアントSMTPによって使用されて、セッションでさえないときに、初めのコマンドを送って、受け入れました。
4.1.5 Private-use Commands
4.1.5 私用コマンド
As specified in section 2.2.2, commands starting in "X" may be used by bilateral agreement between the client (sending) and server (receiving) SMTP agents. An SMTP server that does not recognize such a command is expected to reply with "500 Command not recognized". An extended SMTP server MAY list the feature names associated with these private commands in the response to the EHLO command.
セクション2.2.2で指定されるように、「X」で始まるコマンドはクライアント(発信)とサーバ(受信)SMTPエージェントの間の二国間条約によって使用されるかもしれません。 そのようなコマンドを認識しないSMTPサーバーが「Commandが認識しなかった500」で返答すると予想されます。 拡張SMTPサーバーはEHLOコマンドへの応答におけるこれらの個人的なコマンドに関連している特徴名を記載するかもしれません。
Commands sent or accepted by SMTP systems that do not start with "X" MUST conform to the requirements of section 2.2.2.
「X」から始まらないSMTPシステムで送るか、または受け入れるコマンドはセクション2.2.2の要件に従わなければなりません。
4.2 SMTP Replies
4.2 SMTP回答
Replies to SMTP commands serve to ensure the synchronization of requests and actions in the process of mail transfer and to guarantee that the SMTP client always knows the state of the SMTP server. Every command MUST generate exactly one reply.
SMTPコマンドに関する回答は郵便為替の途中に要求と動作の同期を確実にして、SMTPクライアントがいつもSMTPサーバーの事情を知っているのを保証するのに役立ちます。あらゆるコマンドがまさに1つの回答を生成しなければなりません。
Klensin Standards Track [Page 40] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[40ページ]RFC2821
The details of the command-reply sequence are described in section 4.3.
コマンド回答系列の詳細はセクション4.3で説明されます。
An SMTP reply consists of a three digit number (transmitted as three numeric characters) followed by some text unless specified otherwise in this document. The number is for use by automata to determine what state to enter next; the text is for the human user. The three digits contain enough encoded information that the SMTP client need not examine the text and may either discard it or pass it on to the user, as appropriate. Exceptions are as noted elsewhere in this document. In particular, the 220, 221, 251, 421, and 551 reply codes are associated with message text that must be parsed and interpreted by machines. In the general case, the text may be receiver dependent and context dependent, so there are likely to be varying texts for each reply code. A discussion of the theory of reply codes is given in section 4.2.1. Formally, a reply is defined to be the sequence: a three-digit code, <SP>, one line of text, and <CRLF>, or a multiline reply (as defined in section 4.2.1). Since, in violation of this specification, the text is sometimes not sent, clients which do not receive it SHOULD be prepared to process the code alone (with or without a trailing space character). Only the EHLO, EXPN, and HELP commands are expected to result in multiline replies in normal circumstances, however, multiline replies are allowed for any command.
SMTP回答は別の方法で本書では指定されない場合何らかのテキストがあとに続いた3桁数(3つの数字として、伝えられる)から成ります。 数はオートマトンによる使用が、次にどんな状態に入ったらよいかを決定することです。 テキストは人間のユーザのためのものです。 3ケタはSMTPクライアントがテキストを調べる必要はなくて、それを捨てるか、またはそれを通過するかもしれないという十分なコード化された情報をユーザに含んでいます、適宜。 例外が別掲のとおりこのドキュメントにあります。 220、221、251、421、および551の回答コードがマシンで分析されて、解釈しなければならないメッセージ・テキストに特に、関連しています。 一般的な場合には、テキストが受信機に依存していて文脈に依存しているかもしれないので、それぞれの回答コードにおいて、異なったテキストがありそうです。 セクション4.2.1で回答コードの理論の議論をします。 正式に、回答は系列になるように定義されます: 3ケタのコードか、<SP>か、1個のテキスト行と、<CRLF>か、マルチラインが返答します(セクション4.2.1で定義されるように)。 以来この仕様を違反してテキストは時々送られません、それを受けないクライアント、SHOULD、単独(引きずっている間隔文字のあるなしにかかわらず)でコードを処理するように用意してください。 EHLO、EXPN、およびHELPコマンドだけが平常な時にマルチライン回答をもたらすと予想されて、しかしながら、マルチライン回答はどんなコマンドのためにも許されています。
In ABNF, server responses are:
ABNFでは、サーバ応答は以下の通りです。
Greeting = "220 " Domain [ SP text ] CRLF
Reply-line = Reply-code [ SP text ] CRLF
挨拶=回答コード[SPテキスト]「220」ドメイン[SPテキスト]CRLF Reply-線=CRLF
where "Greeting" appears only in the 220 response that announces that the server is opening its part of the connection.
「挨拶」が220応答だけに現れるところでは、それは、サーバが接続の一部を開いていると発表します。
An SMTP server SHOULD send only the reply codes listed in this document. An SMTP server SHOULD use the text shown in the examples whenever appropriate.
SHOULDが回答コードだけを送るSMTPサーバーは本書では記載しました。 SMTPサーバーSHOULDは適切であるときはいつも、例に示されたテキストを使用します。
An SMTP client MUST determine its actions only by the reply code, not by the text (except for the "change of address" 251 and 551 and, if necessary, 220, 221, and 421 replies); in the general case, any text, including no text at all (although senders SHOULD NOT send bare codes), MUST be acceptable. The space (blank) following the reply code is considered part of the text. Whenever possible, a receiver- SMTP SHOULD test the first digit (severity indication) of the reply code.
回答コード(必要なら「住所の変更」251と551、220、221、および421の回答を除いた)だけでSMTPクライアントはテキストで決定するのではなく、動作を決定しなければなりません。 一般的な場合では、テキストを全く(送付者SHOULD NOTはむき出しのコードを送りますが)含まないどんなテキストも許容できるに違いありません。 回答コードに従うスペース(空白の)はテキストの一部であると考えられます。 可能であるときはいつも、受信機SMTP SHOULDは回答コードの最初のケタ(厳しさ指示)をテストします。
Klensin Standards Track [Page 41] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[41ページ]RFC2821
The list of codes that appears below MUST NOT be construed as permanent. While the addition of new codes should be a rare and significant activity, with supplemental information in the textual part of the response being preferred, new codes may be added as the result of new Standards or Standards-track specifications. Consequently, a sender-SMTP MUST be prepared to handle codes not specified in this document and MUST do so by interpreting the first digit only.
永久的であるとして以下に現れるコードのリストを解釈してはいけません。 新法の追加がまれで重要な活動であるべきである間、応答の原文の部分の補足的情報が好まれている状態で、新法は新しいStandardsかStandards-道の仕様の結果として加えられるかもしれません。 その結果、送付者-SMTP MUSTは、本書では指定されなかったコードを扱うように準備されて、最初のケタだけを解釈することによって、そうしなければなりません。
4.2.1 Reply Code Severities and Theory
4.2.1 回答コードの厳しさと理論
The three digits of the reply each have a special significance. The first digit denotes whether the response is good, bad or incomplete. An unsophisticated SMTP client, or one that receives an unexpected code, will be able to determine its next action (proceed as planned, redo, retrench, etc.) by examining this first digit. An SMTP client that wants to know approximately what kind of error occurred (e.g., mail system error, command syntax error) may examine the second digit. The third digit and any supplemental information that may be present is reserved for the finest gradation of information.
それぞれ回答の3ケタは特別な意義があります。 応答が良いか、悪いかまたは不完全であることにかかわらずケタが指示する1番目。 世慣れていないSMTPクライアント、または予期していなかったコードを受け取るものが次の動作を決定できる、(計画通り続いてください、改装、など) 調べるのによるこの最初のケタに節約してください。 どういう誤りが周囲に発生したかを(例えば、システム誤りを郵送してください、コマンド構文エラー)知りたがっているSMTPクライアントは2番目のケタを調べるかもしれません。 存在するかもしれない3番目のケタとどんな補足的情報も情報の最もすばらしい段階のために予約されます。
There are five values for the first digit of the reply code:
回答コードの最初のケタのための5つの値があります:
1yz Positive Preliminary reply
The command has been accepted, but the requested action is being
held in abeyance, pending confirmation of the information in this
reply. The SMTP client should send another command specifying
whether to continue or abort the action. Note: unextended SMTP
does not have any commands that allow this type of reply, and so
does not have continue or abort commands.
要求された動作だけが停止しているのに保たれています、コマンドが持っている1yz Positive Preliminary回答を受け入れてこの回答における、情報の確認まで。 SMTPクライアントは別のコマンドに動作を続けているか、または中止するかを指定させるべきです。 以下に注意してください。 unextended SMTPには、それがこのタイプの回答を許すのでコマンドを続けているか、または中止するのを持っていない少しのコマンドもありません。
2yz Positive Completion reply
The requested action has been successfully completed. A new
request may be initiated.
要求された動作が持っている2yz Positive Completion回答は首尾よくそうです。完成されます。 新しい要求は開始されるかもしれません。
3yz Positive Intermediate reply
The command has been accepted, but the requested action is being
held in abeyance, pending receipt of further information. The
SMTP client should send another command specifying this
information. This reply is used in command sequence groups (i.e.,
in DATA).
要求された動作だけが停止しているのに保たれています、コマンドが持っている3yz Positive Intermediate回答を受け入れて詳細の領収書まで。 SMTPクライアントは別のコマンドにこの情報を指定させるべきです。 この回答はコマンド・シーケンスグループ(すなわち、DATAの)に使用されます。
4yz Transient Negative Completion reply
The command was not accepted, and the requested action did not
occur. However, the error condition is temporary and the action
may be requested again. The sender should return to the beginning
of the command sequence (if any). It is difficult to assign a
meaning to "transient" when two different sites (receiver- and
4yz Transient Negative Completionは返答します。コマンドは受け入れられませんでした、そして、要求された動作は起こりませんでした。 しかしながら、エラー条件は一時的です、そして、動作は再び要求されているかもしれません。 送付者はコマンド・シーケンス(もしあれば)の始まりまで戻るべきです。 そして2つの異なったサイトであるときに、「一時的に」意味を割り当てるのが難しい、(受信機。
Klensin Standards Track [Page 42] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[42ページ]RFC2821
sender-SMTP agents) must agree on the interpretation. Each reply
in this category might have a different time value, but the SMTP
client is encouraged to try again. A rule of thumb to determine
whether a reply fits into the 4yz or the 5yz category (see below)
is that replies are 4yz if they can be successful if repeated
without any change in command form or in properties of the sender
or receiver (that is, the command is repeated identically and the
receiver does not put up a new implementation.)
送付者-SMTPエージェント) 解釈に同意しなければなりません。 このカテゴリにおける各回答には、異なった時間的価値があるかもしれませんが、SMTPクライアントが再試行するよう奨励されます。 回答が4yzか5yzカテゴリに収まる(以下を見てください)か否かに関係なく、決定する経験則はコマンドフォームか特性における少しも変化なしで繰り返されるならそれらが送付者か受信機でうまくいく場合があるなら回答が4yzであるということです。(すなわち、コマンドは同様に繰り返されて、受信機は新しい実装を提供しません。)
5yz Permanent Negative Completion reply
The command was not accepted and the requested action did not
occur. The SMTP client is discouraged from repeating the exact
request (in the same sequence). Even some "permanent" error
conditions can be corrected, so the human user may want to direct
the SMTP client to reinitiate the command sequence by direct
action at some point in the future (e.g., after the spelling has
been changed, or the user has altered the account status).
5yz Permanent Negative Completionは返答します。コマンドは受け入れられませんでした、そして、要求された動作は起こりませんでした。 SMTPクライアントは、正確な要求(同じ系列の)を繰り返して、がっかりしています。 人間のユーザは、いくつかの「永久的な」エラー条件さえ修正できるので、いくつかの直接行動によるコマンド・シーケンスが将来指す再開始にSMTPクライアントを向けたがっているかもしれません(例えば、スペルを変えたか、またはユーザがアカウントステータスを変更した後に)。
The second digit encodes responses in specific categories:
2番目のケタは特定のカテゴリにおける応答をコード化します:
x0z Syntax: These replies refer to syntax errors, syntactically
correct commands that do not fit any functional category, and
unimplemented or superfluous commands.
x0z構文: これらの回答は構文エラー、どんな機能的なカテゴリにも合わないシンタクス上正しいコマンド、および非実装しているか余計なコマンドを示します。
x1z Information: These are replies to requests for information,
such as status or help.
x1z情報: これらは、状態などの情報に関する要求に関する回答であるか助けます。
x2z Connections: These are replies referring to the transmission
channel.
x2zコネクションズ: これらはトランスミッションチャンネルについて言及する回答です。
x3z Unspecified.
x3z不特定です。
x4z Unspecified.
x4z不特定です。
x5z Mail system: These replies indicate the status of the receiver
mail system vis-a-vis the requested transfer or other mail system
action.
x5zメールシステム: これらの回答は要求された転送か他のメールシステム動作と向かいあって受信機メールシステムの状態を示します。
The third digit gives a finer gradation of meaning in each category specified by the second digit. The list of replies illustrates this. Each reply text is recommended rather than mandatory, and may even change according to the command with which it is associated. On the other hand, the reply codes must strictly follow the specifications in this section. Receiver implementations should not invent new codes for slightly different situations from the ones described here, but rather adapt codes already defined.
3番目のケタは2番目のケタによって指定された各カテゴリにおける意味の、よりすばらしい段階を与えます。 回答のリストはこれを例証します。 それぞれの回答テキストは、義務的であるというよりむしろお勧めであり、それが関連しているコマンドに応じて、変化さえするかもしれません。 他方では、回答コードは厳密にこのセクションの仕様に従わなければなりません。 受信機実装はここで説明されたものからわずかに異なった状況のための新法を発明するべきではありませんが、むしろ既に定義されたコードを適合させてください。
Klensin Standards Track [Page 43] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[43ページ]RFC2821
For example, a command such as NOOP, whose successful execution does not offer the SMTP client any new information, will return a 250 reply. The reply is 502 when the command requests an unimplemented non-site-specific action. A refinement of that is the 504 reply for a command that is implemented, but that requests an unimplemented parameter.
例えば、NOOPなどのコマンドは250回答を返すでしょう。(NOOPのうまくいっている実行は少しの新情報もSMTPクライアントに提供しません)。 コマンドが非実装している非サイトの詳細動作を要求するとき、回答は502です。 その気品は実装されますが、非実装しているパラメタを要求するコマンドのための504回答です。
The reply text may be longer than a single line; in these cases the complete text must be marked so the SMTP client knows when it can stop reading the reply. This requires a special format to indicate a multiple line reply.
回答テキストは単線より長いかもしれません。 これらの場合では、全文をマークしなければならないので、SMTPクライアントは、それが、いつ回答を読むのを止めることができるかを知っています。 これは、複数の系列回答を示すために特別な形式を必要とします。
The format for multiline replies requires that every line, except the last, begin with the reply code, followed immediately by a hyphen, "-" (also known as minus), followed by text. The last line will begin with the reply code, followed immediately by <SP>, optionally some text, and <CRLF>. As noted above, servers SHOULD send the <SP> if subsequent text is not sent, but clients MUST be prepared for it to be omitted.
マルチライン回答のための形式は、最終を除いて、テキストがすぐにハイフン、「-」(また、マイナスとして、知られている)であとに続く回答コードのあとに続いていてあらゆる系列が始まるのを必要とします。 最終ラインはすぐ<SP>によって従われた回答コードで任意に始まるでしょう。何らかのテキスト、および<CRLF>。 上で述べたように、その後のテキストが送られませんが、クライアントがそれが省略される用意ができていなければならないなら、サーバSHOULDは<SP>を送ります。
For example:
例えば:
123-First line
123-Second line
123-234 text beginning with numbers
123 The last line
No.123で最終ラインを始める123セカンドラインの最初に123系列123-234テキスト
In many cases the SMTP client then simply needs to search for a line beginning with the reply code followed by <SP> or <CRLF> and ignore all preceding lines. In a few cases, there is important data for the client in the reply "text". The client will be able to identify these cases from the current context.
多くの場合、そして、SMTPクライアントは、単に回答コードが<SP>か<CRLF>によって従われている状態で始まる系列を捜し求めて、すべての前の系列を無視する必要があります。 いくつかの場合には、回答「テキスト」にクライアントにとって、重要なデータがあります。 クライアントは現在の背景からのこれらのケースを特定できるでしょう。
4.2.2 Reply Codes by Function Groups
4.2.2 関数群による回答コード
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 (see section 4.2.4)
503 Bad sequence of commands
504 Command parameter not implemented
500構文エラー、パラメタか議論502Commandの認識されていない(これはあまりに長い間、コマンドラインなどの誤りを含むかもしれない)501Syntax誤りが504Commandパラメタが実装しなかったコマンドの503Bad系列を実装しなかった(セクション4.2.4を見ます)コマンド
211 System status, or system help reply
214 Help message
(Information on how to use the receiver or the meaning of a
particular non-standard command; this reply is useful only
to the human user)
211 システム状態、またはシステム助け回答214ヘルプメッセージ(特定の標準的でないコマンド; この回答の受信機か意味を使用するのがどう人間のユーザだけの役に立つかに関する情報)
Klensin Standards Track [Page 44] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[44ページ]RFC2821
220 <domain> Service ready
221 <domain> Service closing transmission channel
421 <domain> Service not available, closing transmission channel
(This may be a reply to any command if the service knows it
must shut down)
220 持ち合わせの<の>Service終わりのトランスミッションドメイン>Service221<ドメインチャンネル421のドメインの>のServiceの利用可能で、終わりでないトランスミッション<チャンネル(サービスが、それが停止しなければならないのを知っているなら、これはどんなコマンドに関する回答であるかもしれません)
250 Requested mail action okay, completed
251 User not local; will forward to <forward-path>
(See section 3.4)
252 Cannot VRFY user, but will accept message and attempt
delivery
(See section 3.5.3)
450 Requested mail action not taken: mailbox unavailable
(e.g., mailbox busy)
550 Requested action not taken: mailbox unavailable
(e.g., mailbox not found, no access, or command rejected
for policy reasons)
451 Requested action aborted: error in processing
551 User not local; please try <forward-path>
(See section 3.4)
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., mailbox syntax incorrect)
354 Start mail input; end with <CRLF>.<CRLF>
554 Transaction failed (Or, in the case of a connection-opening
response, "No SMTP service here")
250は地方でなくメール動作オーケーの、そして、完成した251Userを要求しました。 >(セクション3.4を見る)252Cannot VRFYユーザを<フォワードパスに送りますが、メッセージと試み配送(セクション3.5.3を見る)450Requestedメール動作が取られないと受け入れるでしょう: 入手できないメールボックス、(例えば、メールボックスが忙しくする、)、550 取られなかったRequested行動: メールボックス入手できない(方針理由で拒絶されなかった例えば見つけられなかったメールボックス、アクセス、またはコマンド全く)451Requested動作は中止になりました: 処理551Userの地方でない誤り。 取られなかった<フォワードパス>(セクション3.4を見る)452Requested行動を試みてください: 不十分なシステムストレージ552Requestedメール動作は中止になりました: 取られなかった超えられている記憶領域の割当て553Requested行動: メールボックス名が許容しなかった、(例えば、メールボックス構文不正確である、)、354 Startは入力を郵送します。 <CRLF><CRLF>554Transactionが失敗されている状態で、終わってください。(または接続の初めである応答、「ここでSMTPサービスがありません」の場合で)
4.2.3 Reply Codes in Numeric Order
4.2.3 数値オーダーにおける回答コード
211 System status, or system help reply
214 Help message
(Information on how to use the receiver or the meaning of a
particular non-standard command; this reply is useful only
to the human user)
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>
(See section 3.4)
252 Cannot VRFY user, but will accept message and attempt
delivery
(See section 3.5.3)
211 システム状態、または地方でなくトランスミッションチャンネル250Requestedメール動作オーケーの、そして、完成した251Userを閉じるシステム助け回答214ヘルプメッセージ(特定の標準的でないコマンド; この回答の受信機か意味を使用するのがどう人間のユーザだけの役に立つかに関する情報)220<ドメイン>のServiceの持ち合わせの221<ドメイン>Service。 >(セクション3.4を見る)252Cannot VRFYユーザを<フォワードパスに送りますが、メッセージと試み配送を受け入れるでしょう。(セクション3.5.3を見ます)
354 Start mail input; end with <CRLF>.<CRLF>
354 メール入力を始めてください。 <CRLF><CRLF>で、終わってください。
Klensin Standards Track [Page 45] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[45ページ]RFC2821
421 <domain> Service not available, closing transmission channel
(This may be a reply to any command if the service knows it
must shut down)
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 (see section 4.2.4)
503 Bad sequence of commands
504 Command parameter not implemented
550 Requested action not taken: mailbox unavailable
(e.g., mailbox not found, no access, or command rejected
for policy reasons)
551 User not local; please try <forward-path>
(See section 3.4)
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 (Or, in the case of a connection-opening
response, "No SMTP service here")
421 <のドメインの>のServiceの利用可能で、終わりでないトランスミッションチャンネル(サービスが、それが停止しなければならないのを知っているなら、これはどんなコマンドに関する回答であるかもしれない)450Requestedは取られなかった行動を郵送します: 入手できないメールボックス、(例えば、メールボックスが忙しくする、)、451 Requested動作は中止になりました: 取られなかった処理452Requested行動における地方の誤り: 不十分なシステムストレージ500Syntax誤り、パラメタか議論502Commandの認識されていない(これはあまりに長い間、コマンドラインなどの誤りを含むかもしれない)501Syntax誤りが504Commandパラメタが取られなかった550Requested行動を実装しなかったコマンドの503Bad系列を実装しなかった(セクション4.2.4を見ます)コマンド: ローカルではなく、メールボックス入手できない(方針理由で拒絶されなかった例えば見つけられなかったメールボックス、アクセス、またはコマンド全く)551User。 >(セクション3.4を見る)552Requestedメール動作が中止した<フォワードパスを試みてください: 取られなかった超えられている記憶領域の割当て553Requested行動: メールボックス名が許容しなかった、(例えば、メールボックス構文不正確である、)、554Transactionは失敗しました。(または接続の初めである応答、「ここでSMTPサービスがありません」の場合で)
4.2.4 Reply Code 502
4.2.4 回答コード502
Questions have been raised as to when reply code 502 (Command not implemented) SHOULD be returned in preference to other codes. 502 SHOULD be used when the command is actually recognized by the SMTP server, but not implemented. If the command is not recognized, code 500 SHOULD be returned. Extended SMTP systems MUST NOT list capabilities in response to EHLO for which they will return 502 (or 500) replies.
回答が502(実装されなかったコマンド)SHOULDをコード化する時に関して疑問を引き起こしました。他のコードに優先して、返します。 502 コマンドが実際にSMTPサーバーによって認識されるとき、使用されますが、実装されなかったSHOULD。 コマンドが認識されないで、500SHOULDをコード化するなら、返してください。 拡張SMTPシステムはそれらが502(または、500)の回答を返すEHLOに対応して能力を記載してはいけません。
4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
4.2.5 回答はデータとその後の<CRLFの後に><CRLF>をコード化します。
When an SMTP server returns a positive completion status (2yz code) after the DATA command is completed with <CRLF>.<CRLF>, it accepts responsibility for:
DATAコマンドが<CRLF><CRLF>で終了した後にSMTPサーバーが上向きの完成状態(2yzコード)を返すとき、それは以下のために責任を引き受けます。
- delivering the message (if the recipient mailbox exists), or
- またはメッセージ(受取人メールボックスが存在しているなら)を提供する。
- if attempts to deliver the message fail due to transient
conditions, retrying delivery some reasonable number of times at
intervals as specified in section 4.5.4.
- メッセージを提供する試みが一時的な状態、再試行配送のためセクション4.5.4における指定されるとしての間隔を置いて何らかの相当な数の回に失敗するなら。
Klensin Standards Track [Page 46] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[46ページ]RFC2821
- if attempts to deliver the message fail due to permanent
conditions, or if repeated attempts to deliver the message fail
due to transient conditions, returning appropriate notification to
the sender of the original message (using the address in the SMTP
MAIL command).
- メッセージを提供する試みが永久的な状態のため失敗するか、またはオリジナルのメッセージの送付者に適切な通知を返して、メッセージを提供する繰り返された試みが一時的な状態のため失敗するなら(SMTP MAILコマンドにアドレスを使用して)。
When an SMTP server returns a permanent error status (5yz) code after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make any subsequent attempt to deliver that message. The SMTP client retains responsibility for delivery of that message and may either return it to the user or requeue it for a subsequent attempt (see section 4.5.4.1).
DATAコマンドが<CRLF><CRLF>で終了した後にSMTPサーバーが永続エラー状態(5yz)コードを返すとき、それはそのメッセージを提供するどんなその後の試みもしてはいけません。 セクション4.5を見てください。SMTPクライアントがそのメッセージの配送のために責任を保有して、それをユーザに返すか、またはその後の試みのためにそれを「再-列に並ばせ」るかもしれない、(.4 .1)。
The user who originated the message SHOULD be able to interpret the return of a transient failure status (by mail message or otherwise) as a non-delivery indication, just as a permanent failure would be interpreted. I.e., if the client SMTP successfully handles these conditions, the user will not receive such a reply.
だれがメッセージSHOULDを溯源したか。ユーザ、非配送指示として一時障害状態(メール・メッセージかそうでないのによる)の復帰を解釈できてください、ちょうど永久的な失敗が解釈されるように。 すなわち、クライアントSMTPが首尾よくこれらの状態を扱うと、ユーザはそのような回答を受け取らないでしょう。
When an SMTP server returns a permanent error status (5yz) code after the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make any subsequent attempt to deliver the message. As with temporary error status codes, the SMTP client retains responsibility for the message, but SHOULD not again attempt delivery to the same server without user review and intervention of the message.
DATAコマンドが<CRLF>完全に<CRLF>であった後にSMTPサーバーが永続エラー状態(5yz)コードを返すとき、それはメッセージを提供するどんなその後の試みもしてはいけません。 一時的な誤りステータスコードのように、SMTPクライアントはメッセージへの責任を保有します、しかし、SHOULDが再びメッセージのユーザレビューと介入なしで同じサーバに配送を試みません。
4.3 Sequencing of Commands and Replies
4.3 コマンドと回答の配列
4.3.1 Sequencing Overview
4.3.1 配列概要
The communication between the sender and receiver is an alternating dialogue, controlled by the sender. As such, the sender issues a command and the receiver responds with a reply. Unless other arrangements are negotiated through service extensions, the sender MUST wait for this response before sending further commands.
送付者と受信機とのコミュニケーションは送付者によって制御された交互の対話です。 そういうものとして、送付者はコマンドを発行します、そして、受信機は回答で応じます。 他のアレンジメントがサービス拡大で交渉されない場合、さらなるコマンドを送る前に、送付者はこの応答を待たなければなりません。
One important reply is the connection greeting. Normally, a receiver will send a 220 "Service ready" reply when the connection is completed. The sender SHOULD wait for this greeting message before sending any commands.
1つの重要な回答は接続挨拶です。 接続が終了しているとき、通常、受信機は220の「サービス準備ができる」回答を送るでしょう。 どんなコマンドも送る前に、送付者SHOULDはこのあいさつメッセージを待ちます。
Note: all the greeting-type replies have the official name (the fully-qualified primary domain name) of the server host as the first word following the reply code. Sometimes the host will have no meaningful name. See 4.1.3 for a discussion of alternatives in these situations.
以下に注意してください。 挨拶タイプ回答にはすべて、回答コードに従って、最初の単語としてサーバー・ホストの正式名称(完全に適切な一次的領域名)があります。 ホストには、時々、どんな重要な名前もないでしょう。 これらの状況における、代替手段の議論に関して4.1に.3を見てください。
Klensin Standards Track [Page 47] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[47ページ]RFC2821
For example,
例えば
220 ISIF.USC.EDU Service ready
or
220 mail.foo.com SuperSMTP v 6.1.2 Service ready
or
220 [10.0.0.1] Clueless host service ready
ISIF.USC.EDU Service準備ができるか220mail.foo.com SuperSMTP v6.1.2Serviceが準備する220か220、[10.0の.0の.1の]手掛かりのないホストサービス準備ができている。
The table below lists alternative success and failure replies for each command. These SHOULD be strictly adhered to: a receiver may substitute text in the replies, but the meaning and action implied by the code numbers and by the specific command reply sequence cannot be altered.
代替の成功と失敗が各コマンドのために返答するリストの下のテーブル。 固く守られて、これらのSHOULDは厳密に以下の通りです。 受信機は回答におけるテキストを代入するかもしれませんが、コード番号と特定のコマンド回答系列によって含意された意味と動作は変更できません。
4.3.2 Command-Reply Sequences
4.3.2 コマンド回答系列
Each command is listed with its usual possible replies. The prefixes used before the possible replies are "I" for intermediate, "S" for success, and "E" for error. Since some servers may generate other replies under special circumstances, and to allow for future extension, SMTP clients SHOULD, when possible, interpret only the first digit of the reply and MUST be prepared to deal with unrecognized reply codes by interpreting the first digit only. Unless extended using the mechanisms described in section 2.2, SMTP servers MUST NOT transmit reply codes to an SMTP client that are other than three digits or that do not start in a digit between 2 and 5 inclusive.
各コマンドは普通の可能な回答で記載されています。 可能な回答の前に使用された接頭語は、中間的のための「私」と、成功のための「S」と、誤りのための「E」です。 以来に、いくつかのサーバが他の特殊事情の下での回答を生成するかもしれなくて、可能であるときに、今後の拡大を考慮するために、SMTPクライアントSHOULDを回答の最初のケタだけを解釈して、最初のケタだけを解釈することによって認識されていない回答コードに対処するように準備しなければなりません。 セクション2.2で説明されたメカニズムを使用することで広げられない場合、SMTPサーバーはSMTPクライアントへの3ケタ以外に、あるか、または2〜5ケタで包括的に開始しない回答コードを伝えてはいけません。
These sequencing rules and, in principle, the codes themselves, can be extended or modified by SMTP extensions offered by the server and accepted (requested) by the client.
サーバによって提供されて、クライアントによって受け入れられた(要求されています)SMTP拡張子で、これらは、規則と原則としてコード自体を配列するか、広げているか、または変更できます。
In addition to the codes listed below, any SMTP command can return any of the following codes if the corresponding unusual circumstances are encountered:
以下に記載されたコードに加えて、対応する珍しい事情が遭遇するなら、どんなSMTPコマンドも以下のコードのどれかを返すことができます:
500 For the "command line too long" case or if the command name was
not recognized. Note that producing a "command not recognized"
error in response to the required subset of these commands is a
violation of this specification.
500 「コマンドラインも切望する」というケースかそれともコマンド名が認識されなかったかどうかのために。 これらのコマンドの必要な部分集合に対応して「認識されなかったコマンド」誤りを起こすのが、この仕様の違反であることに注意してください。
501 Syntax error in command or arguments. In order to provide for
future extensions, commands that are specified in this document as
not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501
message if arguments are supplied in the absence of EHLO-
advertised extensions.
コマンドか議論における501構文エラー。 今後の拡大に備えるために、EHLOが不在のとき議論を供給するなら本書では、SHOULDが501メッセージを返す主張(DATA、RSET、QUIT)を受け入れないと指定されるコマンドは拡大の広告を出しました。
421 Service shutting down and closing transmission channel
421 停止するサービスと終わりのトランスミッションは向けられます。
Klensin Standards Track [Page 48] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[48ページ]RFC2821
Specific sequences are:
特定の系列は以下の通りです。
CONNECTION ESTABLISHMENT
S: 220
E: 554
EHLO or HELO
S: 250
E: 504, 550
MAIL
S: 250
E: 552, 451, 452, 550, 553, 503
RCPT
S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
E: 550, 551, 552, 553, 450, 451, 452, 503, 550
DATA
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
E: 451, 554, 503
RSET
S: 250
VRFY
S: 250, 251, 252
E: 550, 551, 553, 502, 504
EXPN
S: 250, 252
E: 550, 500, 502, 504
HELP
S: 211, 214
E: 502, 504
NOOP
S: 250
QUIT
S: 221
コネクション確立S: 220E: 554 EHLOかHELO S: 250E: 504、550はSを郵送します: 250E: 552、451、452、550、553、503RCPT S: 250、251(251と551の議論に関してセクション3.4を見る)E: 550、551、552、553、450、451、452、503、550のデータI: 354 ->データ->S: 250E: 552、554、451、452E: 451、554、503RSET S: 250VRFY S: 250、251、252E: 550、551、553、502、504EXPN S: 250、252E: 550、500、502、504はSを助けます: 211、214E: 502、504NOOP S: 250 Sをやめてください: 221
4.4 Trace Information
4.4 トレース情報
When an SMTP server receives a message for delivery or further
processing, it MUST insert trace ("time stamp" or "Received")
information at the beginning of the message content, as discussed in
section 4.1.1.4.
SMTPサーバーが配送かさらなる処理へのメッセージを受け取るとき、メールの文頭の内容で跡(「タイムスタンプ」の、または、「受け取られていている」)の情報を挿入しなければなりません、セクション4.1.1で.4に議論するように
This line MUST be structured as follows:
以下の通りこの系列を構造化しなければなりません:
- The FROM field, which MUST be supplied in an SMTP environment,
SHOULD contain both (1) the name of the source host as presented
in the EHLO command and (2) an address literal containing the IP
address of the source, determined from the TCP connection.
- FROM野原、SHOULDは(1) EHLOコマンドにおける提示されるとしての送信元ホストの名前と(2) ソースのIPアドレスを含むアドレスリテラルの両方を含んでいます、TCP接続によって、断固としています。(SMTP環境でその野原を供給しなければなりません)。
Klensin Standards Track [Page 49] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[49ページ]RFC2821
- The ID field MAY contain an "@" as suggested in RFC 822, but this
is not required.
- ID分野はRFC822に示されるように"@"を含むかもしれませんが、これは必要ではありません。
- The FOR field MAY contain a list of <path> entries when multiple
RCPT commands have been given. This may raise some security
issues and is usually not desirable; see section 7.2.
- 複数のRCPTコマンドを与えたとき、FOR分野は<経路>エントリーのリストを含むかもしれません。 これは、いくつかの安全保障問題を提起するかもしれなくて、通常、望ましくはありません。 セクション7.2を見てください。
An Internet mail program MUST NOT change a Received: line that was previously added to the message header. SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location.
インターネット・メールプログラムはReceivedを変えてはいけません: 以前にメッセージヘッダーに加えられた系列。 SMTPサーバーはメッセージへのprepend Received系列がそうしなければなりません。 彼らは、既設線の注文を変えてはいけませんし、またReceived系列をいかなる他の位置にも挿入してはいけません。
As the Internet grows, comparability of Received fields is important for detecting problems, especially slow relays. SMTP servers that create Received fields SHOULD use explicit offsets in the dates (e.g., -0800), rather than time zone names of any type. Local time (with an offset) is preferred to UT when feasible. This formulation allows slightly more information about local circumstances to be specified. If UT is needed, the receiver need merely do some simple arithmetic to convert the values. Use of UT loses information about the time zone-location of the server. If it is desired to supply a time zone name, it SHOULD be included in a comment.
インターネットが発展するので、問題、特に遅いリレーを検出するのに、Received分野の比較可能性は重要です。 Received分野SHOULDを作成するSMTPサーバーがどんなタイプの時間帯の名よりもむしろ日付(例えば、-0800)で明白なオフセットを使用します。 可能であるときに、現地時間(オフセットがある)はユタより好まれます。 この定式化は、地元の事情に関する詳しい情報が指定されるのをわずかに許容します。 ユタが必要であるなら、受信機は、値を変換するために単に何らかの簡単な演算をしなければなりません。 ユタの使用はサーバの時間帯位置の情報を失います。それが望まれているなら、時間帯の名前を提供してください、それ、SHOULD、コメントで含められてください。
When the delivery SMTP server makes the "final delivery" of a message, it inserts a return-path line at the beginning of the mail data. This use of return-path is required; mail systems MUST support it. The return-path line preserves the information in the <reverse- path> from the MAIL command. Here, final delivery means the message has left the SMTP environment. Normally, this would mean it had been delivered to the destination user or an associated mail drop, but in some cases it may be further processed and transmitted by another mail system.
配送SMTPサーバがメッセージの「最終的な配送」を作ると、それはメールデータの始めにリターンパス線を挿入します。 リターンパスのこの使用が必要です。 メールシステムはそれをサポートしなければなりません。 リターンパス線はメールコマンドから<逆経路>の情報を保存します。 ここで、最終的な配送は、メッセージがSMTPを環境に残したことを意味します。 通常、これが、それが目的地ユーザか関連ポストの差入れ口に提供されたことを意味するでしょうが、いくつかの場合、それは、別のメールシステムによってさらに処理されて、伝えられるかもしれません。
It is possible for the mailbox in the return path to be different from the actual sender's mailbox, for example, if error responses are to be delivered to a special error handling mailbox rather than to the message sender. When mailing lists are involved, this arrangement is common and useful as a means of directing errors to the list maintainer rather than the message originator.
リターンパスのメールボックスが実際の送付者のメールボックスと異なるのは、例えば可能です、誤り応答がメッセージ送付者にというよりむしろ特別なエラー処理メールボックスに提供されることであるなら。 メーリングリストがかかわるとき、このアレンジメントは、メッセージ創始者よりむしろリスト維持装置に誤りを向ける手段として一般的であって、役に立ちます。
The text above implies that the final mail data will begin with a return path line, followed by one or more time stamp lines. These lines will be followed by the mail data headers and body [32].
上のテキストは、最終的なメールデータが1つ以上のタイムスタンプ系列があとに続いたリターンパス線で始まるのを含意します。 メールデータヘッダーとボディー[32]はこれらの系列を支えるでしょう。
It is sometimes difficult for an SMTP server to determine whether or not it is making final delivery since forwarding or other operations may occur after the message is accepted for delivery. Consequently,
SMTPサーバーが、それが配送のためにメッセージを受け入れた後に推進か他の操作が起こるかもしれないので最終的な配送をしているかどうか決定するのは、時々難しいです。 その結果
Klensin Standards Track [Page 50] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[50ページ]RFC2821
any further (forwarding, gateway, or relay) systems MAY remove the return path and rebuild the MAIL command as needed to ensure that exactly one such line appears in a delivered message.
どんなより遠い(推進、ゲートウェイ、またはリレー)システムも、まさにそのような系列の1つが提供されたメッセージに現れるのを保証するためにリターンパスを取り除いて、必要に応じてメールコマンドを再建するかもしれません。
A message-originating SMTP system SHOULD NOT send a message that already contains a Return-path header. SMTP servers performing a relay function MUST NOT inspect the message data, and especially not to the extent needed to determine if Return-path headers are present. SMTP servers making final delivery MAY remove Return-path headers before adding their own.
SHOULD NOTが既にReturn-経路ヘッダーを含むメッセージを送るメッセージを溯源するSMTPシステム。 リレー機能を実行するSMTPサーバーはメッセージデータを点検してはいけません、そして、特に確認するのに必要であるいずれの範囲にもReturn-経路ヘッダーは出席していません。 それら自身のを加える前に、最終的な配送をするSMTPサーバーはReturn-経路ヘッダーを取り除くかもしれません。
The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered. Systems using RFC 822 syntax with non-SMTP transports SHOULD designate an unambiguous address, associated with the transport envelope, to which error reports (e.g., non-delivery messages) should be sent.
Return-経路のプライマリ目的は送られる非配送か他のメールシステム障害を示すメッセージがことであるアドレスを指定することです。 これが明白なまさに1つのリターンパスのSHOULDであるには、メッセージが提供されたら、存在してください。 SHOULDが輸送封筒に関連づけられた明白なアドレスを指定する非SMTP輸送があるRFC822構文をどのエラー・レポート(例えば、非配送メッセージ)に使用するシステムを送るべきです。
Historical note: Text in RFC 822 that appears to contradict the use of the Return-path header (or the envelope reverse path address from the MAIL command) as the destination for error messages is not applicable on the Internet. The reverse path address (as copied into the Return-path) MUST be used as the target of any mail containing delivery error messages.
歴史的な注意: エラーメッセージのための目的地としてReturn-経路ヘッダー(または、メールコマンドからの封筒逆経路アドレス)の使用に矛盾するように見えるRFC822のテキストはインターネットで適切ではありません。 配送エラーメッセージを含むどんなメールの目標としても逆の経路アドレス(Return-経路にコピーされるように)を使用しなければなりません。
In particular:
特に:
- a gateway from SMTP->elsewhere SHOULD insert a return-path header,
unless it is known that the "elsewhere" transport also uses
Internet domain addresses and maintains the envelope sender
address separately.
- ほかの場所のSMTP->SHOULDからのゲートウェイはリターンパスヘッダーを挿入します、「ほかの場所」という輸送がまた、インターネットドメインアドレスを使用して、別々に封筒送付者アドレスを維持するのが知られていない場合。
- a gateway from elsewhere->SMTP SHOULD delete any return-path
header present in the message, and either copy that information to
the SMTP envelope or combine it with information present in the
envelope of the other transport system to construct the reverse
path argument to the MAIL command in the SMTP envelope.
- SMTP封筒の->SMTP SHOULDが逆の経路議論を構成するためにメッセージに出席しているどんなリターンパスヘッダーも削除して、SMTP封筒にその情報をコピーするか、または情報が存在していた状態でもう片方の輸送システムの封筒でそれを結合するほかの場所からメールコマンドへのゲートウェイ。
The server must give special treatment to cases in which the processing following the end of mail data indication is only partially successful. This could happen if, after accepting several recipients and the mail data, the SMTP server finds that the mail data could be successfully delivered to some, but not all, of the recipients. In such cases, the response to the DATA command MUST be an OK reply. However, the SMTP server MUST compose and send an "undeliverable mail" notification message to the originator of the message.
サーバは単にメールデータ指示の終わりに続く処理が部分的にうまくいっている場合に特別な処理を与えなければなりません。 数人の受取人とメールデータを受け入れた後にSMTPサーバーが、首尾よくすべてではなく、何人かの受取人にメールデータを提供できたのがわかるなら、これは起こるかもしれません。 そのような場合、DATAコマンドへの応答はOK回答であるに違いありません。 しかしながら、SMTPサーバーは、「「非-提出物」メール」通知メッセージをメッセージの創始者に構成して、送らなければなりません。
Klensin Standards Track [Page 51] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[51ページ]RFC2821
A single notification listing all of the failed recipients or separate notification messages MUST be sent for each failed recipient. For economy of processing by the sender, the former is preferred when possible. All undeliverable mail notification messages are sent using the MAIL command (even if they result from processing the obsolete SEND, SOML, or SAML commands) and use a null return path as discussed in section 3.7.
それぞれの失敗した受取人のために失敗した受取人か別々の通知メッセージのすべてを記載するただ一つの通知を送らなければなりません。 可能であるときに、送付者による処理の経済のために、前者は好まれます。 すべての「非-提出物」メール通知メッセージが、メールコマンドを使用することで(時代遅れのSEND、SOML、またはSAMLが命令する処理から生じても)送られて、セクション3.7で議論するようにヌルリターンパスを使用します。
The time stamp line and the return path line are formally defined as follows:
タイムスタンプ系列とリターンパス線は以下の通り正式に定義されます:
Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
リターン経路線=、「リターンパス:」 FWS逆経路<CRLF>。
Time-stamp-line = "Received:" FWS Stamp <CRLF>
時間スタンプ線=「受け取りました」。 FWSは<CRLF>を押し込みます。
Stamp = From-domain By-domain Opt-info ";" FWS date-time
「インフォメーションを選んでドメインのそばのドメインの=を押し込んでください」;、」 FWS日付-時間
; where "date-time" is as defined in [32]
; but the "obs-" forms, especially two-digit
; years, are prohibited in SMTP and MUST NOT be used.
; 「日付-時間」が[32]で定義されるようにあるところで。 しかし、"obs"は特に2ケタで形成されます。 何年も、SMTPで禁止して、使用してはいけません。
From-domain = "FROM" FWS Extended-Domain CFWS
ドメインからの=“FROM" FWS拡張ドメインCFWS
By-domain = "BY" FWS Extended-Domain CFWS
ドメインのそばの=“BY" FWS拡張ドメインCFWS
Extended-Domain = Domain /
( Domain FWS "(" TCP-info ")" ) /
( Address-literal FWS "(" TCP-info ")" )
拡張ドメイン=ドメイン/(「(「TCP-インフォメーション」)」というドメインFWS)/(「(「TCP-インフォメーション」)」というアドレスリテラルFWS)
TCP-info = Address-literal / ( Domain FWS Address-literal )
; Information derived by server from TCP connection
; not client EHLO.
TCP-インフォメーションはアドレスリテラル/(ドメインFWSアドレスリテラル)と等しいです。 サーバによってTCP接続から引き出された情報。 クライアントEHLOでない。
Opt-info = [Via] [With] [ID] [For]
を通してインフォメーションを選んでいる=、[]、[With][ID][For]
Via = "VIA" FWS Link CFWS
FWSリンクCFWS「を通した」の=を通して
With = "WITH" FWS Protocol CFWS
=“WITH" FWSプロトコルCFWSと共に
ID = "ID" FWS String / msg-id CFWS
「ID」FWSエムエスジーストリング/イドID=CFWS
For = "FOR" FWS 1*( Path / Mailbox ) CFWS
=“FOR" FWS1*(経路/メールボックス)CFWSのために
Link = "TCP" / Addtl-Link
Addtl-Link = Atom
; Additional standard names for links are registered with the
; Internet Assigned Numbers Authority (IANA). "Via" is
; primarily of value with non-Internet transports. SMTP
Addtl="TCP"/リンクAddtl-リンク=原子をリンクしてください。 リンクへの追加標準の名前がともに記名される、。 インターネットは数の権威(IANA)を割り当てました。 を通して「」 あります。 主として非インターネット輸送がある価値について。 SMTP
Klensin Standards Track [Page 52] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[52ページ]RFC2821
; servers SHOULD NOT use unregistered names.
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
; Additional standard names for protocols are registered with the
; Internet Assigned Numbers Authority (IANA). SMTP servers
; SHOULD NOT use unregistered names.
; サーバSHOULD NOTは登録されていない名前を使用します。 Attdlプロトコル="ESMTP"/"SMTP"/プロトコルAttdl-プロトコルは原子と等しいです。 プロトコルのための追加標準の名前がともに記名される、。 インターネットは数の権威(IANA)を割り当てました。 SMTPサーバー。 SHOULD NOTは登録されていない名前を使用します。
4.5 Additional Implementation Issues
4.5 追加導入問題
4.5.1 Minimum Implementation
4.5.1 最小の実装
In order to make SMTP workable, the following minimum implementation is required for all receivers. The following commands MUST be supported to conform to this specification:
SMTPを実行可能にして、以下の最小の実装がすべての受信機に必要です。 この仕様に従うために以下のコマンドをサポートしなければなりません:
EHLO
HELO
MAIL
RCPT
DATA
RSET
NOOP
QUIT
VRFY
EHLO HELOメールRCPTデータRSET NOOPはVRFYをやめます。
Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox "postmaster" as a case- insensitive local name. This postmaster address is not strictly necessary if the server always returns 554 on connection opening (as described in section 3.1). The requirement to accept mail for postmaster implies that RCPT commands which specify a mailbox for postmaster at any of the domains for which the SMTP server provides mail service, as well as the special case of "RCPT TO:<Postmaster>" (with no domain specification), MUST be supported.
メールがリレーか配送であるとサポートするSMTPサーバーを含んでいるどんなシステムもケースの神経の鈍い地方名として予約されたメールボックス「郵便局長」をサポートしなければなりません。 サーバが接続始まりの上でいつも554を返すなら(セクション3.1で説明されるように)、この郵便局長アドレスは厳密に必要ではありません。 郵便局長へのメールを受け入れるという要件は、SMTPサーバーがメールサービスを提供するドメインのどれか、および「RCPT TO:<郵便局長>」(ドメイン仕様のない)の特別なケースで郵便局長にメールボックスを指定するRCPTコマンドをサポートしなければならないのを含意します。
SMTP systems are expected to make every reasonable effort to accept mail directed to Postmaster from any other system on the Internet. In extreme cases --such as to contain a denial of service attack or other breach of security-- an SMTP server may block mail directed to Postmaster. However, such arrangements SHOULD be narrowly tailored so as to avoid blocking messages which are not part of such attacks.
SMTPシステムがインターネットにいかなる他のシステムからもPostmasterに向けられたメールを受け入れるためのあらゆる妥当な努力をすると予想されます。 極端な場合(セキュリティのサービス不能攻撃か他の不履行を含むようなもの)では、SMTPサーバーはPostmasterに向けられたメールを妨げるかもしれません。 しかしながら、そのようなアレンジメントSHOULDは狭くそうです。そのような攻撃の一部でないメッセージを妨げるのを避けるために、仕立てられます。
4.5.2 Transparency
4.5.2 透明
Without some provision for data transparency, the character sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user. In general, users are not aware of such "forbidden" sequences. To
データ透明への何らかの支給がなければ、キャラクタシーケンス「<CRLF><CRLF>」を、メールテキストを終わらせて、ユーザは送ることができません。 一般に、ユーザは系列が「禁じられた」そのようなものを意識していません。 to
Klensin Standards Track [Page 53] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[53ページ]RFC2821
allow all user composed text to be transmitted transparently, the following procedures are used:
すべてのユーザに落ち着いたテキストを許容して、透過的に伝えられてください、以下の手順は使用されています:
- Before sending a line of mail text, the SMTP client checks the
first character of the line. If it is a period, one additional
period is inserted at the beginning of the line.
- メールテキストの系列を送る前に、SMTPクライアントは系列の最初のキャラクタをチェックします。 それが期間であるなら、ある追加期間は系列の始めに挿入されます。
- When a line of mail text is received by the SMTP server, it checks
the line. If the line is composed of a single period, it is
treated as the end of mail indicator. If the first character is a
period and there are other characters on the line, the first
character is deleted.
- メールテキストの台詞がSMTPサーバーによって受けられるとき、それは系列をチェックします。 系列がただ一つの期間で構成されるなら、メールインディケータの終わりとして扱われます。 最初のキャラクタが期間であり、他のキャラクタが系列にあれば、最初のキャラクタは削除されます。
The mail data may contain any of the 128 ASCII characters. All characters are to be delivered to the recipient's mailbox, including spaces, vertical and horizontal tabs, and other control characters. If the transmission channel provides an 8-bit byte (octet) data stream, the 7-bit ASCII codes are transmitted right justified in the octets, with the high order bits cleared to zero. See 3.7 for special treatment of these conditions in SMTP systems serving a relay function.
メールデータは128人のASCII文字のいずれも含むかもしれません。 すべてのキャラクタが空間、垂直で水平なタブ、および他の制御文字を含む受信者のメールボックスに提供されることになっています。 トランスミッションチャンネルがデータが流す8ビットのバイト(八重奏)を提供するなら、7ビットのASCIIコードは八重奏で正当化された、伝えられた権利です、高位のビットがゼロまできれいにされている状態で。 リレー機能を果たすSMTPシステムにおける、これらの状態の特別な処理に関して3.7を見てください。
In some systems it may be necessary to transform the data as it is received and stored. This may be necessary for hosts that use a different character set than ASCII as their local character set, that store data in records rather than strings, or which use special character sequences as delimiters inside mailboxes. If such transformations are necessary, they MUST be reversible, especially if they are applied to mail being relayed.
いくつかのシステムでは、それが受け取られて、保存されるとき、データを変えるのが必要であるかもしれません。 これが彼らのローカルキャラクターセットとしてのASCIIより異なった文字集合を使用するホストに必要であるかもしれません(ストリングよりむしろ記録にデータを保存するか、またはデリミタとしてメールボックスの中に特殊文字系列を使用します)。 そのような変換が必要であるなら、特にリレーされるメールに適用されるなら、それらはリバーシブルであるに違いありません。
4.5.3 Sizes and Timeouts
4.5.3 サイズとタイムアウト
4.5.3.1 Size limits and minimums
4.5.3.1 サイズ限界と最小限
There are several objects that have required minimum/maximum sizes. Every implementation MUST be able to receive objects of at least these sizes. Objects larger than these sizes SHOULD be avoided when possible. However, some Internet mail constructs such as encoded X.400 addresses [16] will often require larger objects: clients MAY attempt to transmit these, but MUST be prepared for a server to reject them if they cannot be handled by it. To the maximum extent possible, implementation techniques which impose no limits on the length of these objects should be used.
最小の、または、最大のサイズを必要としたいくつかの目的があります。 あらゆる実装が少なくともこれらのサイズのオブジェクトを受け取ることができなければなりません。 これらより大きい目的はSHOULDを大きさで分けます。可能であるときに、避けられます。 しかしながら、コード化されたX.400アドレス[16]などのいくつかのインターネット・メール構造物がしばしばより大きいオブジェクトを必要とするでしょう: クライアントは、これらを伝えるのを試みるかもしれませんが、それで彼らを扱うことができないなら、サーバが彼らを拒絶する用意ができていなければなりません。 可能な最大の範囲実装のテクニックに、どれがこれらのオブジェクトの長さに限界を全く課さないかは使用されるべきです。
local-part
The maximum total length of a user name or other local-part is 64
characters.
ユーザの最大の全長が命名する地方の部分か他の地方の部分が64のキャラクタです。
Klensin Standards Track [Page 54] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[54ページ]RFC2821
domain
The maximum total length of a domain name or number is 255
characters.
ドメイン、ドメイン名か数の最大の全長は255のキャラクタです。
path
The maximum total length of a reverse-path or forward-path is 256
characters (including the punctuation and element separators).
経路、逆経路かフォワードパスの最大の全長は256のキャラクタ(句読と要素分離符を含んでいて)です。
command line
The maximum total length of a command line including the command
word and the <CRLF> is 512 characters. SMTP extensions may be
used to increase this limit.
コマンドラインがコマンドを含む最大の全長が言い表すコマンドラインと<CRLF>は512のキャラクタです。 SMTP拡張子は、この限界を増強するのに使用されるかもしれません。
reply line
The maximum total length of a reply line including the reply code
and the <CRLF> is 512 characters. More information may be
conveyed through multiple-line replies.
回答コードと<CRLF>を含む回答の最大の全長が裏打ちする回答系列は512のキャラクタです。 詳しい情報は複数の系列回答で伝えられるかもしれません。
text line
The maximum total length of a text line including the <CRLF> is
1000 characters (not counting the leading dot duplicated for
transparency). This number may be increased by the use of SMTP
Service Extensions.
<CRLF>を含むテキストの最大の全長が裏打ちするテキスト系列は1000のキャラクタ(透明ためにコピーされた主なドットを数えないで)です。 この数はSMTP Service Extensionsの使用で増強されるかもしれません。
message content
The maximum total length of a message content (including any
message headers as well as the message body) MUST BE at least 64K
octets. Since the introduction of Internet standards for
multimedia mail [12], message lengths on the Internet have grown
dramatically, and message size restrictions should be avoided if
at all possible. SMTP server systems that must impose
restrictions SHOULD implement the "SIZE" service extension [18],
and SMTP client systems that will send large messages SHOULD
utilize it when possible.
メッセージの最大の全長が満足させる(メッセージ本体と同様にどんなメッセージヘッダーも含んでいます)メッセージ内容は少なくとも64Kの八重奏であるに違いありません。 マルチメディアメール[12]のインターネット標準の導入以来、インターネットのメッセージ長は劇的に成長しています、そして、できれば、メッセージサイズ制限は避けられるべきです。 制限SHOULDを課さなければならないSMTPサーバーシステムは、「サイズ」がサービス拡大[18]であると実装します、そして、可能であるときに、大きいメッセージを送るSMTPクライアントシステムはそれを利用するはずです。
recipients buffer
The minimum total number of recipients that must be buffered is
100 recipients. Rejection of messages (for excessive recipients)
with fewer than 100 RCPT commands is a violation of this
specification. The general principle that relaying SMTP servers
MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation
tests on message headers suggests that rejecting a message based
on the total number of recipients shown in header fields is to be
discouraged. A server which imposes a limit on the number of
recipients MUST behave in an orderly fashion, such as to reject
additional addresses over its limit rather than silently
discarding addresses previously accepted. A client that needs to
受取人はバッファリングされているのが、100人の受取人であるということであるに違いない受取人の最小の総数をバッファリングします。 100未満のRCPTコマンドによるメッセージ(過度の受取人のための)の拒絶はこの仕様の違反です。 SMTPをリレーして、サーバがそうしてはいけない配送SMTPプロトコルのサーバSHOULD NOTがメッセージヘッダーの合法化テストを実行するという一般的な原則は、ヘッダーフィールドで見せられた受取人の総数に基づくメッセージを拒絶するのがお勧めできないことになっていると示唆します。 規則的なファッション(静かに以前に受け入れられたアドレスを捨てるより限界の上でむしろ追加アドレスを拒絶するようなもの)で受取人の数で指し値するサーバは振る舞わなければなりません。 必要があるクライアント
Klensin Standards Track [Page 55] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[55ページ]RFC2821
deliver a message containing over 100 RCPT commands SHOULD be
prepared to transmit in 100-recipient "chunks" if the server
declines to accept more than 100 recipients in a single message.
サーバが、ただ一つのメッセージで100人以上の受取人を受け入れるのを断るなら100受取人の「塊」で伝えるために準備されていて、100のRCPTコマンドの上にSHOULDを含むメッセージを提供してください。
Errors due to exceeding these limits may be reported by using the reply codes. Some examples of reply codes are:
これらの限界を超えているのによる誤りは、回答コードを使用することによって、報告されるかもしれません。 回答コードに関するいくつかの例は以下の通りです。
500 Line too long.
or
501 Path too long
or
452 Too many recipients (see below)
or
552 Too much mail data.
500 あまりに長いときにあまりに長い間. 501Pathを裏打ちしてください。さもないと、452Too多くの受取人(以下を見ます)か552Tooはデータをたくさん郵送します。
RFC 821 [30] incorrectly listed the error where an SMTP server
exhausts its implementation limit on the number of RCPT commands
("too many recipients") as having reply code 552. The correct reply
code for this condition is 452. Clients SHOULD treat a 552 code in
this case as a temporary, rather than permanent, failure so the logic
below works.
RCPTコマンド(「あまりに多くの受取人」)の数における実装限界が回答コード552を持っているとしてSMTPサーバー的でくたくたになるところにRFC821[30]は不当に誤りを記載しました。 この状態のための正しい回答コードは452です。 クライアントSHOULDはこの場合552コードを永久的であるというよりむしろ一時的にaとして扱って、失敗は以下の論理が扱うそうです。
When a conforming SMTP server encounters this condition, it has at least 100 successful RCPT commands in its recipients buffer. If the server is able to accept the message, then at least these 100 addresses will be removed from the SMTP client's queue. When the client attempts retransmission of those addresses which received 452 responses, at least 100 of these will be able to fit in the SMTP server's recipients buffer. Each retransmission attempt which is able to deliver anything will be able to dispose of at least 100 of these recipients.
従うSMTPサーバーがこの状態に遭遇すると、それには、受取人バッファにおける少なくとも100のうまくいっているRCPTコマンドがあります。 そして、少なくともサーバがメッセージを受け入れることができると、SMTPクライアントの待ち行列からこれらの100のアドレスを取り除くでしょう。 クライアントが452の応答を受けたそれらのアドレスの「再-トランスミッション」を試みるとき、少なくともこれらの100はSMTPサーバーの受取人バッファをうまくはめ込むことができるでしょう。 何でも提供できるそれぞれの「再-トランスミッション」試みは少なくともこれらの100人の受取人を処分できるでしょう。
If an SMTP server has an implementation limit on the number of RCPT commands and this limit is exhausted, it MUST use a response code of 452 (but the client SHOULD also be prepared for a 552, as noted above). If the server has a configured site-policy limitation on the number of RCPT commands, it MAY instead use a 5XX response code. This would be most appropriate if the policy limitation was intended to apply if the total recipient count for a particular message body were enforced even if that message body was sent in multiple mail transactions.
SMTPサーバーがRCPTコマンドの数に実装限界を持って、この限界が疲れ果てるなら、452の応答コードを使用しなければならない、(クライアントSHOULD、また、552には、用意してください、上で述べたように) サーバがRCPTコマンドの数に構成されたサイト方針制限を持っているなら、それは代わりに5XX応答コードを使用するかもしれません。 複数のメールトランザクションでそのメッセージ本体を送ったとしても特定のメッセージ本体のための総受取人カウントを励行したなら方針制限が適用されるつもりであるなら、これは最も適切でしょうに。
4.5.3.2 Timeouts
4.5.3.2 タイムアウト
An SMTP client MUST provide a timeout mechanism. It MUST use per- command timeouts rather than somehow trying to time the entire mail transaction. Timeouts SHOULD be easily reconfigurable, preferably without recompiling the SMTP code. To implement this, a timer is set
SMTPクライアントはタイムアウトメカニズムを提供しなければなりません。 使用しなければならない、-、時間までどうにか全体のメールトランザクションを試みるよりむしろタイムアウトを命令してください。 タイムアウトSHOULDは容易にそうです。望ましくは、SMTPコードを再コンパイルしないで、再構成可能です。 これを実装するために、タイマは設定されます。
Klensin Standards Track [Page 56] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[56ページ]RFC2821
for each SMTP command and for each buffer of the data transfer. The latter means that the overall timeout is inherently proportional to the size of the message.
それぞれのSMTPコマンドとデータ転送に関する各バッファのために。 後者は、総合的なタイムアウトが本来メッセージのサイズに比例していることを意味します。
Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows:
忙しいメール中継ホストの広範囲の経験に基づいて1コマンドあたりの最小のタイムアウトはSHOULDを評価します。以下の通りになってください:
Initial 220 Message: 5 minutes
An SMTP client process needs to distinguish between a failed TCP
connection and a delay in receiving the initial 220 greeting
message. Many SMTP servers accept a TCP connection but delay
delivery of the 220 message until their system load permits more
mail to be processed.
220メッセージに頭文字をつけてください: 5分のAn SMTPクライアントプロセスは、初期の220あいさつメッセージを受け取る失敗したTCP接続と遅れを見分ける必要があります。 それらのシステム・ロードが、より多くのメールが処理されることを許可するまで、多くのSMTPサーバーが、TCP接続を受け入れますが、220メッセージの配送を遅らせます。
MAIL Command: 5 minutes
コマンドを郵送してください: 5分
RCPT Command: 5 minutes
A longer timeout is required if processing of mailing lists and
aliases is not deferred until after the message was accepted.
RCPTは命令します: メッセージを受け入れた後までメーリングリストと別名の処理が延期されないなら、5分間のAより長いタイムアウトが必要です。
DATA Initiation: 2 minutes
This is while awaiting the "354 Start Input" reply to a DATA
command.
データ開始: 2分のThisが「354スタート入力」回答をDATAコマンドにお待ちしている間、あります。
Data Block: 3 minutes
This is while awaiting the completion of each TCP SEND call
transmitting a chunk of data.
データ・ブロック: 3分のThisがデータの塊を伝えながらそれぞれのTCP SEND呼び出しの完成を待っている間、あります。
DATA Termination: 10 minutes.
This is while awaiting the "250 OK" reply. When the receiver gets
the final period terminating the message data, it typically
performs processing to deliver the message to a user mailbox. A
spurious timeout at this point would be very wasteful and would
typically result in delivery of multiple copies of the message,
since it has been successfully sent and the server has accepted
responsibility for delivery. See section 6.1 for additional
discussion.
データ終了: 10 書き留めます。 これは「250OK」回答をお待ちしている間、あります。 ファイナルピリオドが受信機でメッセージデータを終えるとき、それは、ユーザメールボックスにメッセージを提供するために処理を通常実行します。 ここの偽りのタイムアウトは、非常に無駄であるだろう、メッセージの複本の配送を通常もたらすでしょう、首尾よくそれを送って、サーバが配送への責任を引き受けたので。 追加議論に関してセクション6.1を見てください。
An SMTP server SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender.
少なくとも5分間のSHOULDがタイムアウトを持っているSMTPサーバーはそれである間、送付者から次のコマンドを待っています。
4.5.4 Retry Strategies
4.5.4 再試行戦略
The common structure of a host SMTP implementation includes user mailboxes, one or more areas for queuing messages in transit, and one or more daemon processes for sending and receiving mail. The exact structure will vary depending on the needs of the users on the host
ホストSMTP実装の一般的な構造はユーザメールボックス、トランジットにおけるメッセージを列に並ばせるための1つ以上の領域、および送受信メールのための1つ以上のデーモンプロセスを含んでいます。 ホストの上のユーザの必要性によって、正確な構造は異なるでしょう。
Klensin Standards Track [Page 57] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[57ページ]RFC2821
and the number and size of mailing lists supported by the host. We describe several optimizations that have proved helpful, particularly for mailers supporting high traffic levels.
ホストによってサポートされたメーリングリストの数とサイズ。 私たちは特に高いトラフィックがレベルであるとサポートする郵送者において役立っていると判明したいくつかの最適化について説明します。
Any queuing strategy MUST include timeouts on all activities on a per-command basis. A queuing strategy MUST NOT send error messages in response to error messages under any circumstances.
どんな列を作り戦略も1コマンドあたり1個のベースにおけるすべての活動でのタイムアウトを含まなければなりません。 列を作り戦略はどうあってもエラーメッセージに対応してエラーメッセージを送ってはいけません。
4.5.4.1 Sending Strategy
4.5.4.1 送付戦略
The general model for an SMTP client is one or more processes that periodically attempt to transmit outgoing mail. In a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender. A mail queue entry will include not only the message itself but also the envelope information.
SMTPクライアントのための一般的なモデルは定期的に送信するメールを伝えるのを試みる1つ以上のプロセスです。 典型的なシステムでは、メッセージを作成するプログラムは新しい送信するメールのためのすぐに伝えることができないメールを列に並ばせられて、定期的に再試行しなければならない間の応急手当を要求するための送付者による何らかのメソッドを持っています。 メール待ち行列項目はメッセージ自体だけではなく、封筒情報も含むでしょう。
The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery.
送付者は、1つの試みが失敗した後に特定の目的地を再試行するのを遅らせなければなりません。 一般に、少なくとも30が数分であったなら間隔SHOULDを再試行してください。 しかしながら、SMTPクライアントが非配送の理由を決定できるとき、より高度で可変な戦略は有益になるでしょう。
Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days. The parameters to the retry algorithm MUST be configurable.
メッセージが送られるか、または送付者があきらめるまで、再試行は続きます。 一般に、上にあきらめ時間は、少なくとも4-5日間である必要があります。 再試行アルゴリズムへのパラメタは構成可能であるに違いありません。
A client SHOULD keep a list of hosts it cannot reach and corresponding connection timeouts, rather than just retrying queued mail items.
SHOULDがそれが届くことができないホストとただ再試行するよりむしろ対応する接続タイムアウトのリストであることを保つクライアントはメール項目を列に並ばせました。
Experience suggests that failures are typically transient (the target system or its connection has crashed), favoring a policy of two connection attempts in the first hour the message is in the queue, and then backing off to one every two or three hours.
経験は、失敗が通常一時的であると示唆します(目標システムかその接続がダウンしました)、2時間か3時間毎にメッセージが待ち行列中である1時間目に2つの接続試みの方針を支持して、次に、1つに引き返して。
The SMTP client can shorten the queuing delay in cooperation with the SMTP server. For example, if mail is received from a particular address, it is likely that mail queued for that host can now be sent. Application of this principle may, in many cases, eliminate the requirement for an explicit "send queues now" function such as ETRN [9].
SMTPクライアントはSMTPサーバーと提携して列を作り遅れを短くすることができます。例えば、特定のアドレスからメールを受け取るなら、現在、そのホストのために列に並ばせられたメールは送ることができそうです。 多くの場合、この原則のアプリケーションはETRN[9]などの「現在の送信キュー」明白な機能のための要件を排除するかもしれません。
The strategy may be further modified as a result of multiple addresses per host (see below) to optimize delivery time vs. resource usage.
戦略は、複数のホスト(以下を見る)あたりのアドレスの結果、リソース用法に対して納期を最適化するようにさらに変更されるかもしれません。
Klensin Standards Track [Page 58] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[58ページ]RFC2821
An SMTP client may have a large queue of messages for each unavailable destination host. If all of these messages were retried in every retry cycle, there would be excessive Internet overhead and the sending system would be blocked for a long period. Note that an SMTP client can generally determine that a delivery attempt has failed only after a timeout of several minutes and even a one-minute timeout per connection will result in a very large delay if retries are repeated for dozens, or even hundreds, of queued messages to the same host.
SMTPクライアントには、それぞれの入手できないあて先ホストへのメッセージの大きい待ち行列があるかもしれません。 これらのメッセージのすべてがあらゆるリトライ・サイクルに再試行されるなら、過度のインターネット・オーバヘッドがあるでしょうに、そして、送付システムは長い間妨げられるでしょう。 一般に、SMTPクライアントが、再試行が同じホストに列に並ばせられたメッセージの数十、または何数百もさえ繰り返されると数分のタイムアウトと1接続あたり1回の1分のタイムアウトさえ非常に大きい遅れをもたらした後にだけ配送試みが失敗したと決心できることに注意してください。
At the same time, SMTP clients SHOULD use great care in caching negative responses from servers. In an extreme case, if EHLO is issued multiple times during the same SMTP connection, different answers may be returned by the server. More significantly, 5yz responses to the MAIL command MUST NOT be cached.
同時に、SMTPクライアントSHOULDはサーバから否定応答をキャッシュする際に高度の注意を使用します。 はなはだしきに至っては、同じSMTP接続の間の複数の回をEHLOに発行するなら、サーバは異なった答えを返すかもしれません。よりかなり、メールコマンドへの5yz応答をキャッシュしてはいけません。
When a mail message is to be delivered to multiple recipients, and the SMTP server to which a copy of the message is to be sent is the same for multiple recipients, then only one copy of the message SHOULD be transmitted. That is, the SMTP client SHOULD use the command sequence: MAIL, RCPT, RCPT,... RCPT, DATA instead of the sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. However, if there are very many addresses, a limit on the number of RCPT commands per MAIL command MAY be imposed. Implementation of this efficiency feature is strongly encouraged.
提供されるメール・メッセージがことであるときには、複数の受取人、およびメッセージのコピーが複数の受取人にとって、送るのが同じであり、次に、メッセージの唯一のコピー1部がSHOULDであるということであるSMTPサーバーに、伝えられてください。 すなわち、SMTPクライアントSHOULDはコマンド・シーケンスを使用します: メール、RCPT、RCPT… RCPT、系列の代わりにDATA: メール、RCPT、データ…, メール、RCPT、データ。 しかしながら、非常に多くのアドレスがあれば、メールコマンドあたりのRCPTコマンドの数における限界は課されるかもしれません。 この効率機能の実装は強く奨励されます。
Similarly, to achieve timely delivery, the SMTP client MAY support multiple concurrent outgoing mail transactions. However, some limit may be appropriate to protect the host from devoting all its resources to mail.
同様に、タイムリーな配送を達成するために、SMTPクライアントは、複数の同時発生の送信するメールがトランザクションであるとサポートするかもしれません。 しかしながら、何らかの限界はすべてのリソースをメールにささげるのからホストを保護するのが適切であるかもしれません。
4.5.4.2 Receiving Strategy
4.5.4.2 受信戦略
The SMTP server SHOULD attempt to keep a pending listen on the SMTP port at all times. This requires the support of multiple incoming TCP connections for SMTP. Some limit MAY be imposed but servers that cannot handle more than one SMTP transaction at a time are not in conformance with the intent of this specification.
未定のaを保つSMTPサーバーSHOULD試みはSMTPポートの上でいつも聴かれます。 これはSMTPのために複数の入って来るTCP接続のサポートを必要とします。 何らかの限界が課されるかもしれませんが、1つ以上のSMTPトランザクションを扱うことができないサーバは一度に、順応この仕様の意図を伴う中ではありません。
As discussed above, when the SMTP server receives mail from a particular host address, it could activate its own SMTP queuing mechanisms to retry any mail pending for that host address.
SMTPサーバーが特定のホスト・アドレスからメールを受け取るとき、上で議論するように、それはそのホスト・アドレスに、未定のどんなメールも再試行するためにメカニズムを列に並ばせるそれ自身のSMTPを動かすかもしれません。
4.5.5 Messages with a null reverse-path
4.5.5 逆経路であることでのヌルメッセージ
There are several types of notification messages which are required by existing and proposed standards to be sent with a null reverse path, namely non-delivery notifications as discussed in section 3.7,
存在することによって必要であるいくつかのタイプに関する通知メッセージとヌル逆の経路と共に送られる提案された標準、すなわち、非配送通知がセクション3.7で議論するようにあります。
Klensin Standards Track [Page 59] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[59ページ]RFC2821
other kinds of Delivery Status Notifications (DSNs) [24], and also Message Disposition Notifications (MDNs) [10]. All of these kinds of messages are notifications about a previous message, and they are sent to the reverse-path of the previous mail message. (If the delivery of such a notification message fails, that usually indicates a problem with the mail system of the host to which the notification message is addressed. For this reason, at some hosts the MTA is set up to forward such failed notification messages to someone who is able to fix problems with the mail system, e.g., via the postmaster alias.)
他の種類のDelivery Status Notifications(DSNs)[24]、およびMessage Disposition Notifications(MDNs)[10]も。 これらの種類に関するメッセージのすべてが前のメッセージに関する通知です、そして、前のメール・メッセージの逆経路にそれらを送ります。 (そのような通知メッセージの配送が失敗するなら、通常、それは通知メッセージが扱われるホストのメールシステムに関する問題を示します。 この理由で、何人かのホストでは、MTAはメールシステムで問題を解決できるだれかにそのような失敗した通知メッセージを転送するためにセットアップされます、例えば、郵便局長別名で。)
All other types of messages (i.e., any message which is not required by a standards-track RFC to have a null reverse-path) SHOULD be sent with with a valid, non-null reverse-path.
すべてのもう一方がタイプします。メッセージ(逆経路であるのにヌルを持つために標準化過程RFCによって必要とされないすなわちどんなメッセージも)SHOULDでは、有効で、非ヌルの逆経路と共に発信してください。
Implementors of automated email processors should be careful to make sure that the various kinds of messages with null reverse-path are handled correctly, in particular such systems SHOULD NOT reply to messages with null reverse-path.
自動化されたメールプロセッサの作成者は逆経路であることでのヌル様々な種類に関するメッセージが正しく扱われて、逆経路であることでヌル特に、そのようなシステムSHOULD NOTがメッセージに答えるのを確実にするのに慎重であるはずです。
5. Address Resolution and Mail Handling
5. 解決を扱ってください、そして、取り扱いを郵送してください。
Once an SMTP client lexically identifies a domain to which mail will be delivered for processing (as described in sections 3.6 and 3.7), a DNS lookup MUST be performed to resolve the domain name [22]. The names are expected to be fully-qualified domain names (FQDNs): mechanisms for inferring FQDNs from partial names or local aliases are outside of this specification and, due to a history of problems, are generally discouraged. The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name. If no MX records are found, but an A RR is found, the A RR is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any A RRs associated with that name unless they are located using the MX RRs; the "implicit MX" rule above applies only if there are no MX records present. If MX records are present, but none of them are usable, this situation MUST be reported as an error.
SMTPクライアントがいったん、辞書的に、メールが処理のために提供されるドメインを特定すると(セクション3.6と3.7で説明されるように)、ドメイン名[22]を決議するためにDNSルックアップを実行しなければなりません。 名前は完全修飾ドメイン名(FQDNs)であると予想されます: 部分的な名前かローカルの別名からFQDNsを推論するためのメカニズムは、この仕様の外にあって、一般に、問題の歴史のためがっかりしています。 ルックアップは、最初に、名前に関連しているMX記録の場所を見つけるのを試みます。 CNAME記録が代わりに見つけられるなら、結果として起こる名前はまるでそれが初期の名前であるかのように処理されます。 MX記録が全く見つけられませんが、A RRが見つけられるなら、まるでそれが内在しているMX RRに関連しているかのようにA RRは扱われます、0の優先で、そのホストを示して。 1MX RRsが名に関して見つけられて、彼らがMX RRsを使用することで見つけられていない場合、SMTPシステムはその名前に関連している少しのA RRsも利用してはいけません。 どんな存在しているMX記録もない場合にだけ、上の「内在しているMX」規則は適用されます。 MX記録が存在していますが、それらのいずれも使用可能でないなら、誤りとしてこの状況を報告しなければなりません。
When the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of multiple MX records, multihoming, or both. To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried. In any case, the SMTP client SHOULD try at least two addresses.
ルックアップが成功すると、マッピングはただ一つのアドレスよりむしろ代替の品物の配達先のリストをもたらすことができます、複数のMX記録、マルチホーミング、または両方のために。 信頼できるメール送信を提供するために、SMTPクライアントはこのリストのオーダーにおける、それぞれの関連アドレスを試みることができなければなりません(再試行してください)、配送試みが成功するまで。 しかしながら、また、構成可能な限界が試みることができる代替アドレスの数にあるかもしれません。 どのような場合でも、SMTPクライアントSHOULDは少なくとも2つのアドレスを試みます。
Klensin Standards Track [Page 60] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[60ページ]RFC2821
Two types of information is used to rank the host addresses: multiple MX records, and multihomed hosts.
2つのタイプの情報はホスト・アドレスを格付けするのに使用されます: 複数のMX記録、および「マルチ-家へ帰」っているホスト。
Multiple MX records contain a preference indication that MUST be used in sorting (see below). Lower numbers are more preferred than higher ones. If there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by recognition of an easily-reached address), then the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization.
複数のMX記録がソーティングに使用しなければならない好みの指示を含んでいます(以下を見てください)。 下側..数..以上..都合のよい..高い..もの 同じ好みがある複数の目的地があって、1つ(例えば、容易に達しているアドレスの認識による)を支持するどんな明確な理由もなければ、送付者-SMTP MUSTが、特定の組織のために複数のメール交換器の向こう側に負荷を広げるためにそれらをランダマイズします。
The destination host (perhaps taken from the preferred MX record) may be multihomed, in which case the domain name resolver will return a list of alternative IP addresses. It is the responsibility of the domain name resolver interface to have ordered this list by decreasing preference if necessary, and SMTP MUST try them in the order presented.
あて先ホスト(恐らく、都合のよいMX記録から、取る)は「マルチ-家へ帰」るかもしれません、その場合、ドメイン名レゾルバが代替のIPアドレスのリストを返すでしょう。 必要なら、好みを減少させることによってこのリストを注文したのが、ドメイン名レゾルバインタフェースの責任であり、SMTP MUSTは提示されたオーダーでそれらを試みます。
Although the capability to try multiple alternative addresses is required, specific installations may want to limit or disable the use of alternative addresses. The question of whether a sender should attempt retries using the different addresses of a multihomed host has been controversial. The main argument for using the multiple addresses is that it maximizes the probability of timely delivery, and indeed sometimes the probability of any delivery; the counter- argument is that it may result in unnecessary resource use. Note that resource use is also strongly determined by the sending strategy discussed in section 4.5.4.1.
複数の代替アドレスを試みる能力が必要ですが、特定のインストールは、代替アドレスの使用を制限したいか、または無効にしたがっているかもしれません。 送付者が「マルチ-家へ帰」っているホストの異なったアドレスを使用することで再試行を試みるべきであるかどうかに関する質問は論議を呼んでいます。 複数のアドレスを使用するための主な議論はタイムリーな配送の確率、および本当に時々どんな配送の確率も最大にするということです。 カウンタ議論は不要なリソース使用をもたらすかもしれないということです。 また、リソース使用がセクション4.5.4で.1に議論した送付戦略で強く決定することに注意してください。
If an SMTP server receives a message with a destination for which it is a designated Mail eXchanger, it MAY relay the message (potentially after having rewritten the MAIL FROM and/or RCPT TO addresses), make final delivery of the message, or hand it off using some mechanism outside the SMTP-provided transport environment. Of course, neither of the latter require that the list of MX records be examined further.
SMTPサーバーがそれがメールeXchangerに指定されたaである目的地でメッセージを受け取るなら、SMTPによって提供された輸送環境の外に何らかのメカニズムを使用して、それは、メッセージ(潜在的に、後にMAIL FROM、そして/または、RCPT TOアドレスを書き直した)をリレーするか、メッセージの最終的な配送をするか、またはそれを渡すかもしれません。 もちろん、後者のどちらもMX記録のリストがさらに調べられるのを必要としません。
If it determines that it should relay the message without rewriting the address, it MUST sort the MX records to determine candidates for delivery. The records are first ordered by preference, with the lowest-numbered records being most preferred. The relay host MUST then inspect the list for any of the names or addresses by which it might be known in mail transactions. If a matching record is found, all records at that preference level and higher-numbered ones MUST be discarded from consideration. If there are no records left at that point, it is an error condition, and the message MUST be returned as undeliverable. If records do remain, they SHOULD be tried, best preference first, as described above.
アドレスを書き直さないでメッセージをリレーするべきであることを決定するなら、それは、配送の候補を決定するためにMX記録を分類しなければなりません。 最も低く番号付の記録が最も好まれている状態で、記録は最初に、好みで注文されます。 そして、中継ホストはそれがメールトランザクションで知られているかもしれない名前かアドレスのいずれがないかどうかもリストを点検しなければなりません。 合っている記録が見つけられるなら、考慮からその好みのレベルと、より高く番号付のものにおけるすべての記録を捨てなければなりません。 記録が全くその時残っていないなら、それはエラー条件です、そして、「非-提出物」としてメッセージを返さなければなりません。 記録は残っていて、それらはSHOULDです。上で最初に、説明されるとしての試験済みの、そして、最も良い好みになってください。
Klensin Standards Track [Page 61] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[61ページ]RFC2821
6. Problem Detection and Handling
6. 問題検出と取り扱い
6.1 Reliable Delivery and Replies by Email
6.1 メールによる信頼できる配信と回答
When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously. It MUST NOT lose the message for frivolous reasons, such as because the host later crashes or because of a predictable resource shortage.
受信機-SMTPが1つのメール(データに対応して「250OK」メッセージを送るのによる)を受け入れるとき、それはメッセージを提供するか、またはリレーすることへの責任を引き受けています。 それは真剣にこの責任を受け止めなければなりません。 それはホストが後でダウンするか、予測できるリソース不足などの軽薄な理由でメッセージを失ってはいけません。
If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message. This
notification MUST be sent using a null ("<>") reverse path in the
envelope. The recipient of this notification MUST be the address
from the envelope return path (or the Return-Path: line). However,
if this address is null ("<>"), the receiver-SMTP MUST NOT send a
notification. Obviously, nothing in this section can or should
prohibit local decisions (i.e., as part of the same system
environment as the receiver-SMTP) to log or otherwise transmit
information about null address events locally if that is desired. If
the address is an explicit source route, it MUST be stripped down to
its final hop.
配信障害がメッセージの承認の後にあれば、受信機-SMTP MUSTは通知メッセージを定式化して、郵送します。 この通知に封筒のヌル(「<>」)逆の経路を使用させなければなりません。 この通知の受取人は封筒リターンパスからのアドレスであるに違いありません(Return-経路: 立ち並んでください)。 しかしながら、このアドレスがヌルであるなら(「<>」)、受信機-SMTPは通知書を送ってはいけません。 明らかに、禁止できるべきであるか、またはそれが望まれているなら、このセクションの何も局所的に空アドレスイベントの情報を登録するか、またはそうでなければ伝えるというローカルの決定(すなわち、受信機-SMTPと同じシステム環境の一部としての)を禁止するべきではありません。 アドレスが明白な送信元経路であるなら、それを最終的なホップまで剥取らなければなりません。
For example, suppose that an error notification must be sent for a message that arrived with:
例えば、以下と共に到着したメッセージのためにエラー通知を送らなければならないと仮定してください。
MAIL FROM:<@a,@b:user@d>
メール FROM:<@a 、@b: ユーザ@d>。
The notification message MUST be sent using:
使用を通知メッセージに送らなければなりません:
RCPT TO:<user@d>
RCPT TO:<user@d 、gt。
Some delivery failures after the message is accepted by SMTP will be unavoidable. For example, it may be impossible for the receiving SMTP server to validate all the delivery addresses in RCPT command(s) due to a "soft" domain system error, because the target is a mailing list (see earlier discussion of RCPT), or because the server is acting as a relay and has no immediate access to the delivering system.
メッセージがSMTPによって受け入れられた後にいくつかの配信障害が避けられなくなるでしょう。 例えば、受信SMTPサーバーが「柔らかい」ドメインシステム・エラーによるRCPTコマンドにおけるすべての品物の配達先を有効にするのは、不可能であるかもしれません、サーバが目標がメーリングリスト(RCPTの以前の議論を見る)である、リレーとして機能していて、またはどんな即座のアクセスも配送システムに持っていないので。
To avoid receiving duplicate messages as the result of timeouts, a receiver-SMTP MUST seek to minimize the time required to respond to the final <CRLF>.<CRLF> end of data indicator. See RFC 1047 [28] for a discussion of this problem.
CRLF>データインディケータの<CRLF>エンドを最終的な<に反応させるのに必要である時間を最小にするためにタイムアウトでは、受信機-SMTP MUSTが探すという結果として写しメッセージを受け取るのを避けるために。 この問題の議論のためのRFC1047[28]を見てください。
Klensin Standards Track [Page 62] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[62ページ]RFC2821
6.2 Loop Detection
6.2 輪の検出
Simple counting of the number of "Received:" headers in a message has proven to be an effective, although rarely optimal, method of detecting loops in mail systems. SMTP servers using this technique SHOULD use a large rejection threshold, normally at least 100 Received entries. Whatever mechanisms are used, servers MUST contain provisions for detecting and stopping trivial loops.
「受け取った」数の簡単な勘定 有効です、めったに最適ではありませんが、検出のメソッドはメールシステムで輪にされます。中のメッセージが判明したヘッダー、このテクニックSHOULDを使用するSMTPサーバーが大きい拒絶敷居、通常少なくとも100のReceivedエントリーを使用します。 いかなるメカニズムも使用されていても、サーバは些細な輪を検出して、止めるための条項を含まなければなりません。
6.3 Compensating for Irregularities
6.3 不規則を補うこと。
Unfortunately, variations, creative interpretations, and outright violations of Internet mail protocols do occur; some would suggest that they occur quite frequently. The debate as to whether a well- behaved SMTP receiver or relay should reject a malformed message, attempt to pass it on unchanged, or attempt to repair it to increase the odds of successful delivery (or subsequent reply) began almost with the dawn of structured network mail and shows no signs of abating. Advocates of rejection claim that attempted repairs are rarely completely adequate and that rejection of bad messages is the only way to get the offending software repaired. Advocates of "repair" or "deliver no matter what" argue that users prefer that mail go through it if at all possible and that there are significant market pressures in that direction. In practice, these market pressures may be more important to particular vendors than strict conformance to the standards, regardless of the preference of the actual developers.
残念ながら、インターネットメールプロトコルの変化、創造的な解釈、および完全な違反は起こります。 或るものは、それらがかなり頻出するのを示すでしょう。 よく振る舞っているSMTP受信機かリレーが、うまくいっている配送(または、その後の回答)の可能性を増強するために奇形のメッセージを拒絶するはずであるか、変わりがない状態でそれを伝えるのを試みるはずであるか、またはそれを修理するのを試みるはずであるかに関する討論はほとんど構造化されたネットワークメールとショーの夜明けで減少のサインを全く始めませんでした。 拒絶の支持者は試みられた修理が完全にめったに適切であるというわけではなく、悪いメッセージの拒絶が間違っているソフトウェアを修理させる唯一の方法であると主張します。 「修理」か「たとえ何があっても、配送してください」の支持者は、ユーザができれば、メールがひどい目に遭って、重要な市場圧がその方向にあるのを好むと主張します。 実際には、これらの市場圧は規格への厳しい順応より特定のベンダーに重要であるかもしれません、実際の開発者の好みにかかわらず。
The problems associated with ill-formed messages were exacerbated by the introduction of the split-UA mail reading protocols [3, 26, 5, 21]. These protocols have encouraged the use of SMTP as a posting protocol, and SMTP servers as relay systems for these client hosts (which are often only intermittently connected to the Internet). Historically, many of those client machines lacked some of the mechanisms and information assumed by SMTP (and indeed, by the mail format protocol [7]). Some could not keep adequate track of time; others had no concept of time zones; still others could not identify their own names or addresses; and, of course, none could satisfy the assumptions that underlay RFC 822's conception of authenticated addresses.
不適格なメッセージに関連している問題は分裂-UAメール読書プロトコル[3、26、5、21]の導入で悪化させられました。 これらのプロトコルは任命プロトコルとしてのSMTP、およびこれらのクライアントホストのリレー方式としてのSMTPサーバー(しばしば断続的にインターネットに関連づけられるだけである)の使用を奨励しました。 そして、歴史的に、それらのクライアントマシンの多くがSMTPによって想定されたメカニズムと何らかの情報を欠いていた、(本当に、メール書式で、[7])について議定書の中で述べてください。 或るものは時間の適切な道を保つことができませんでした。 他のものには、時間帯の概念が全くありませんでした。 それでも、他のものはそれら自身の名前かアドレスを特定できませんでした。 もちろん、そして、なにもRFC822の認証されたアドレスに関する概念を下に置いた仮定は満たすことができませんでした。
In response to these weak SMTP clients, many SMTP systems now complete messages that are delivered to them in incomplete or incorrect form. This strategy is generally considered appropriate when the server can identify or authenticate the client, and there are prior agreements between them. By contrast, there is at best great concern about fixes applied by a relay or delivery SMTP server that has little or no knowledge of the user or client machine.
これらの弱いSMTPクライアントに対応して、多くのSMTPシステムが今、不完全であるか不正確なフォームでそれらに提供されるメッセージを完成します。 サーバがクライアントを特定するか、または認証できて、それらの間に事前同意があるとき、一般に、この戦略は適切であると考えられます。 対照的に、まずユーザかクライアントマシンに関する知識を持っていないリレーか配送SMTPサーバによって適用されたフィックスに関してせいぜい大きな心配があります。
Klensin Standards Track [Page 63] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[63ページ]RFC2821
The following changes to a message being processed MAY be applied when necessary by an originating SMTP server, or one used as the target of SMTP as an initial posting protocol:
必要であるときに、処理されるメッセージへの以下の変化は起因するSMTPサーバー、または初期の任命プロトコルとしてのSMTPの目標として使用されるものによって適用されているかもしれません:
- Addition of a message-id field when none appears
- なにもであるときに、メッセージイド分野の追加は現れます。
- Addition of a date, time or time zone when none appears
- なにもであるときに、日付、時間または時間帯の追加は現れます。
- Correction of addresses to proper FQDN format
- 適切なFQDN形式へのアドレスの修正
The less information the server has about the client, the less likely these changes are to be correct and the more caution and conservatism should be applied when considering whether or not to perform fixes and how. These changes MUST NOT be applied by an SMTP server that provides an intermediate relay function.
サーバがクライアントに関して持っている情報が少なければ少ないほど、これらの変化は正しいことになっていなさそうにはありません、そして、フィックスとどのようにを実行するかどうか考えるとき、より多くの警告と保守主義は申し込まれるべきです。 これらの変化は中間的リレー機能を提供するSMTPサーバーによって当てはまられてはいけません。
In all cases, properly-operating clients supplying correct information are preferred to corrections by the SMTP server. In all cases, documentation of actions performed by the servers (in trace fields and/or header comments) is strongly encouraged.
すべての場合では、正確な情報を提供する適切に稼働しているクライアントは修正より. Inがすべてケースに入れるSMTPサーバーによって好まれて、サーバ(跡の分野、そして/または、ヘッダーコメントにおける)によって実行された動作のドキュメンテーションは強く奨励されます。
7. Security Considerations
7. セキュリティ問題
7.1 Mail Security and Spoofing
7.1 メールセキュリティとスプーフィング
SMTP mail is inherently insecure in that it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else. Constructing such a message so that the "spoofed" behavior cannot be detected by an expert is somewhat more difficult, but not sufficiently so as to be a deterrent to someone who is determined and knowledgeable. Consequently, as knowledge of Internet mail increases, so does the knowledge that SMTP mail inherently cannot be authenticated, or integrity checks provided, at the transport level. Real mail security lies only in end-to-end methods involving the message bodies, such as those which use digital signatures (see [14] and, e.g., PGP [4] or S/MIME [31]).
かなりカジュアルなユーザさえ直接、SMTPサーバーを受け取って、リレーすると交渉して、ナイーブな受取人が、他のどこかから来たと信じているようにだますメッセージを作成するのが、可能であるので、SMTPメールは本来不安定です。 そのようなメッセージを構成するのは、いくらか難しいのですが、専門家が「偽造している」振舞いを検出できないくらい断固としてだれか博識な人への抑止力になるように十分難しいというわけではありません。 その結果、インターネット・メールに関する知識が増加するのに従って、本来SMTPメールを認証できなかったか、または保全チェックが提供されたという知識もそうします、輸送レベルで。 そして、本当のメールセキュリティが単に終わりから終わりへのメッセージ本体を伴うメソッドであります、デジタル署名を使用するものなどのように([14]を見てください、例えば、PGP[4]かS/MIME[31])。
Various protocol extensions and configuration options that provide authentication at the transport level (e.g., from an SMTP client to an SMTP server) improve somewhat on the traditional situation described above. However, unless they are accompanied by careful handoffs of responsibility in a carefully-designed trust environment, they remain inherently weaker than end-to-end mechanisms which use digitally signed messages rather than depending on the integrity of the transport system.
輸送レベル(例えば、SMTPクライアントからSMTPサーバーまでの)で認証を提供する様々なプロトコル拡大と設定オプションが上で説明された伝統的な状況をいくらか改良します。 しかしながら、入念に設計された信頼環境における責任の慎重なhandoffsによって伴われない場合、それらは本来輸送システムの保全によるより終わりから終わりへのむしろデジタルに署名しているメッセージを使用するメカニズムより弱いままで残っています。
Klensin Standards Track [Page 64] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[64ページ]RFC2821
Efforts to make it more difficult for users to set envelope return path and header "From" fields to point to valid addresses other than their own are largely misguided: they frustrate legitimate applications in which mail is sent by one user on behalf of another or in which error (or normal) replies should be directed to a special address. (Systems that provide convenient ways for users to alter these fields on a per-message basis should attempt to establish a primary and permanent mailbox address for the user so that Sender fields within the message data can be generated sensibly.)
ユーザが、封筒リターンパスとヘッダー“From"分野にそれら自身のを除いた有効なアドレスを示すように設定するのをより難しくする取り組みは主に指導を誤られます: 彼らはメールが別のものを代表して1人のユーザによって送られるか、または誤り(または、標準)回答が特別なアドレスに向けられるべきである正統のアプリケーションをだめにします。 (ユーザが1メッセージあたり1個のベースでこれらの分野を変更する便利な方法を提供するシステムは、分別よくメッセージデータの中のSender分野を生成することができて、ユーザのためにプライマリの、そして、永久的なメールボックスアドレスを確立するのを試みるはずです。)
This specification does not further address the authentication issues associated with SMTP other than to advocate that useful functionality not be disabled in the hope of providing some small margin of protection against an ignorant user who is trying to fake mail.
この仕様はさらにメールを見せかけようとしている無知なユーザに対する保護の何らかのわずかなマージンを提供することを希望して提唱する以外の役に立つ機能性がないSMTPに関連している問題が無効にした認証を扱いません。
7.2 "Blind" Copies
7.2 「盲目」のコピー
Addresses that do not appear in the message headers may appear in the RCPT commands to an SMTP server for a number of reasons. The two most common involve the use of a mailing address as a "list exploder" (a single address that resolves into multiple addresses) and the appearance of "blind copies". Especially when more than one RCPT command is present, and in order to avoid defeating some of the purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy the full set of RCPT command arguments into the headers, either as part of trace headers or as informational or private-extension headers. Since this rule is often violated in practice, and cannot be enforced, sending SMTP systems that are aware of "bcc" use MAY find it helpful to send each blind copy as a separate message transaction containing only a single RCPT command.
メッセージヘッダーに現れないアドレスはRCPTコマンドにSMTPサーバーにおいて様々な意味で現れるかもしれません。 2、ほとんどのコモンが「リスト発破器」(複数のアドレスに変えるただ一つのアドレス)としての郵送先住所の使用と「盲目のコピー」の外観にかかわります。 特に1つ以上のRCPTコマンドが存在しているとき、これらのメカニズムの目的のいくつかをくつがえすのを避けるために、SMTPクライアントとサーバSHOULD NOTは跡のヘッダーの一部とした、または、ヘッダーか、情報としたRCPTコマンド議論か個人的な拡張ヘッダーのフルセットをコピーします。 この規則に実際にはしばしば違反して、励行できないので、"bcc"使用を意識している送付SMTPシステムは、ただ一つのRCPTコマンドだけを含む別々のメッセージトランザクションとしてそれぞれの盲目のコピーを送るのに役立っているのがわかるかもしれません。
There is no inherent relationship between either "reverse" (from
MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
transaction ("envelope") and the addresses in the headers. Receiving
systems SHOULD NOT attempt to deduce such relationships and use them
to alter the headers of the message for delivery. The popular
"Apparently-to" header is a violation of this principle as well as a
common source of unintended information disclosure and SHOULD NOT be
used.
SMTPトランザクション(「封筒」)の「逆(メール、SAMLなどからのコマンド)」の、または、「前進」の(RCPT)アドレスとアドレスとのどんな固有の関係もヘッダーにありません。 受電方式SHOULD NOTは配送へのメッセージのヘッダーを変更するのにそのような関係を推論して、それらを使用するのを試みます。 」 ヘッダーは故意でない情報公開とSHOULD NOTの共通ソースと同様にこの原則の違反です。ポピュラーである、「明らかである、-、使用されます。
7.3 VRFY, EXPN, and Security
7.3 VRFY、EXPN、およびセキュリティ
As discussed in section 3.5, individual sites may want to disable either or both of VRFY or EXPN for security reasons. As a corollary to the above, implementations that permit this MUST NOT appear to have verified addresses that are not, in fact, verified. If a site
セクション3.5で議論するように、個々のサイトは安全保障上の理由でVRFYかEXPNのどちらかか両方を無効にしたがっているかもしれません。 上記での推論として、これを可能にする実装は事実上、確かめられないアドレスについて確かめたように見えてはいけません。 サイトです。
Klensin Standards Track [Page 65] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[65ページ]RFC2821
disables these commands for security reasons, the SMTP server MUST return a 252 response, rather than a code that could be confused with successful or unsuccessful verification.
うまくいっているか失敗の検証に混乱できたコードよりむしろ252応答を安全保障上の理由で、SMTPサーバーが返さなければならないこれらのコマンドに無効にします。
Returning a 250 reply code with the address listed in the VRFY command after having checked it only for syntax violates this rule. Of course, an implementation that "supports" VRFY by always returning 550 whether or not the address is valid is equally not in conformance.
構文だけがないかどうかそれをチェックした後にアドレスがVRFYコマンドで記載されている状態で250回答コードを返すと、この規則は違反されます。 もちろん、アドレスが有効であるか否かに関係なく、VRFYをいつも戻っている550「サポートする」実装は順応で等しくそうしていません。
Within the last few years, the contents of mailing lists have become popular as an address information source for so-called "spammers." The use of EXPN to "harvest" addresses has increased as list administrators have installed protections against inappropriate uses of the lists themselves. Implementations SHOULD still provide support for EXPN, but sites SHOULD carefully evaluate the tradeoffs. As authentication mechanisms are introduced into SMTP, some sites may choose to make EXPN available only to authenticated requestors.
ここ数年以内に、メーリングリストの内容はいわゆる「スパマー」のためのアドレスの情報源としてポピュラーになりました。 リスト管理者がリスト自体の不適当な用途に対する保護をインストールするのに従って、「収穫」アドレスへのEXPNの使用は増加しました。 実装SHOULDはまだEXPNのサポートを提供していますが、サイトSHOULDは慎重に見返りを評価します。 認証機構がSMTPに紹介されるとき、いくつかのサイトが、EXPNを認証された要請者だけに利用可能にするのを選ぶかもしれません。
7.4 Information Disclosure in Announcements
7.4 発表における情報公開
There has been an ongoing debate about the tradeoffs between the debugging advantages of announcing server type and version (and, sometimes, even server domain name) in the greeting response or in response to the HELP command and the disadvantages of exposing information that might be useful in a potential hostile attack. The utility of the debugging information is beyond doubt. Those who argue for making it available point out that it is far better to actually secure an SMTP server rather than hope that trying to conceal known vulnerabilities by hiding the server's precise identity will provide more protection. Sites are encouraged to evaluate the tradeoff with that issue in mind; implementations are strongly encouraged to minimally provide for making type and version information available in some way to other network hosts.
挨拶応答かHELPコマンドに対応してサーバタイプとバージョン(そして、時々同等のサーバドメイン名)を発表するデバッグ有利な立場の間には、見返りの進行中の討論がありました、そして、情報がそれであると暴露する損失は潜在的敵対的な攻撃で役に立つかもしれません。 デバッグ情報に関するユーティリティは疑問を超えています。 それを利用可能にするように論争する人は、サーバの正確なアイデンティティを隠すことによって知られている脆弱性を隠そうとするなら、より多くの保護が提供されることを望んでいるより実際にむしろSMTPサーバーを保証するのがはるかに良いと指摘します。 サイトが念頭でその問題で見返りを評価するよう奨励されます。 実装が他のネットワークホストへの何らかの方法で手があいている作成タイプとバージョン情報に最少量で備えるよう強く奨励されます。
7.5 Information Disclosure in Trace Fields
7.5 跡の分野での情報公開
In some circumstances, such as when mail originates from within a LAN
whose hosts are not directly on the public Internet, trace
("Received") fields produced in conformance with this specification
may disclose host names and similar information that would not
normally be available. This ordinarily does not pose a problem, but
sites with special concerns about name disclosure should be aware of
it. Also, the optional FOR clause should be supplied with caution or
not at all when multiple recipients are involved lest it
inadvertently disclose the identities of "blind copy" recipients to
others.
メールが中から、ホストが直接公共のインターネットにいないLANを溯源する時などのいくつかの事情では、順応でこの仕様で生産された跡(「受信する」)の分野は通常、利用可能でないホスト名と同様の情報を明らかにするかもしれません。 これは通常問題を設定しませんが、名前公開に関する特別な心配があるサイトはそれを意識しているべきです。 また、うっかり「盲目のコピー」受取人のアイデンティティを他のものに明らかにするといけないので複数の受取人がかかわるとき、任意のFOR節を慎重か全く提供するべきではありません。
Klensin Standards Track [Page 66] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[66ページ]RFC2821
7.6 Information Disclosure in Message Forwarding
7.6 メッセージ推進における情報公開
As discussed in section 3.4, use of the 251 or 551 reply codes to identify the replacement address associated with a mailbox may inadvertently disclose sensitive information. Sites that are concerned about those issues should ensure that they select and configure servers appropriately.
セクション3.4で議論するように、メールボックスに関連している交換アドレスを特定する251か551の回答コードの使用はうっかり機密情報を明らかにするかもしれません。 それらの問題に関して心配しているサイトは適切にサーバを選択して、構成するのを確実にするべきです。
7.7 Scope of Operation of SMTP Servers
7.7 SMTPサーバの操作の範囲
It is a well-established principle that an SMTP server may refuse to accept mail for any operational or technical reason that makes sense to the site providing the server. However, cooperation among sites and installations makes the Internet possible. If sites take excessive advantage of the right to reject traffic, the ubiquity of email availability (one of the strengths of the Internet) will be threatened; considerable care should be taken and balance maintained if a site decides to be selective about the traffic it will accept and process.
サーバを提供するサイトに理解できるのは、SMTPサーバーが、どんな操作上的、または、技術的な理由でもメールを受け入れるのを拒否するかもしれないという安定している原則です。しかしながら、サイトとインストールの中の協力で、インターネットは可能になります。 サイトが過度の利点を活用すると、トラフィック、メールの有用性の偏在を拒絶する権利では、(インターネットの強さの1つ)は脅かされるでしょう。 かなりの注意が払われるべきであり、バランスはサイトが、トラフィックに関して選択していると決めると、それが受け入れて、処理されると主張しました。
In recent years, use of the relay function through arbitrary sites has been used as part of hostile efforts to hide the actual origins of mail. Some sites have decided to limit the use of the relay function to known or identifiable sources, and implementations SHOULD provide the capability to perform this type of filtering. When mail is rejected for these or other policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL, or RCPT as appropriate.
近年、任意のサイトを通したリレー機能の使用は、メールの実際の発生源を隠すのに敵対的な取り組みの一部として使用されました。 いくつかのサイトが、リレー機能の使用を知られているか身元保証可能なソースに制限すると決めました、そして、実装SHOULDはこのタイプのフィルタリングを実行する能力を前提とします。 メールがいつこれらのために拒絶されるか、そして、他の方針が推論します、550コードSHOULD。EHLO、メール、またはRCPTに対応して、適宜使用されてください。
8. IANA Considerations
8. IANA問題
IANA will maintain three registries in support of this specification. The first consists of SMTP service extensions with the associated keywords, and, as needed, parameters and verbs. As specified in section 2.2.2, no entry may be made in this registry that starts in an "X". Entries may be made only for service extensions (and associated keywords, parameters, or verbs) that are defined in standards-track or experimental RFCs specifically approved by the IESG for this purpose.
IANAはこの仕様を支持して3つの登録を維持するでしょう。 1番目は必要に応じて関連キーワード、パラメタ、および動詞でSMTPサービス拡張子から成ります。 セクション2.2.2で指定されるように、「X」で始まるこの登録でエントリーを全くしないかもしれません。 標準化過程かIESGによって明確にこのために承認された実験的なRFCsで定義されるサービス拡大(そして、関連キーワード、パラメタ、または動詞)のためだけにエントリーをするかもしれません。
The second registry consists of "tags" that identify forms of domain literals other than those for IPv4 addresses (specified in RFC 821 and in this document) and IPv6 addresses (specified in this document). Additional literal types require standardization before being used; none are anticipated at this time.
2番目の登録はIPv4アドレス(RFC821に本書では指定される)とIPv6アドレス(本書では指定される)のためのそれら以外のドメインリテラルのフォームを特定する「タグ」から成ります。 使用される前に追加文字通りのタイプは標準化を必要とします。 なにもこのとき、予期されません。
The third, established by RFC 821 and renewed by this specification,
is a registry of link and protocol identifiers to be used with the
"via" and "with" subclauses of the time stamp ("Received: header")
」 タイムスタンプの“with" subclausesを通してRFC821によって設立されて、この仕様で更新された3番目が使用されるリンクとプロトコル識別子の登録である、「。(「: ヘッダーを受けます」)
Klensin Standards Track [Page 67] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[67ページ]RFC2821
described in section 4.4. Link and protocol identifiers in addition to those specified in this document may be registered only by standardization or by way of an RFC-documented, IESG-approved, Experimental protocol extension.
セクション4.4で、説明されます。 リンクしてください。そうすれば、本書では指定されたものに加えたプロトコル識別子は単に標準化かRFCによって記録されて、IESGによって承認されたExperimentalプロトコル拡張子を通して登録されてもよいです。
9. References
9. 参照
[1] American National Standards Institute (formerly United States of
America Standards Institute), X3.4, 1968, "USA Code for
Information Interchange". ANSI X3.4-1968 has been replaced by
newer versions with slight modifications, but the 1968 version
remains definitive for the Internet.
[1]American National Standards Institut(以前アメリカ合衆国規格研究所)、X3.4、1968、「米国情報交換用符号。」 わずかな変更でANSI X3.4-1968をより新しいバージョンに取り替えましたが、1968年のバージョンはインターネットに決定的に残っています。
[2] Braden, R., "Requirements for Internet hosts - application and
support", STD 3, RFC 1123, October 1989.
[2] ブレーデンと、R.と、「インターネット・ホスト--アプリケーションのための要件とサポート」、STD3、RFC1123、10月1989日
[3] Butler, M., Chase, D., Goldberger, J., Postel, J. and J.
Reynolds, "Post Office Protocol - version 2", RFC 937, February
1985.
[3] バトラー、M.、チェイス、D.、Goldberger(J.、ポステル、J.、およびJ.レイノルズ)は「バージョン2インチ、RFC937、1985年オフィスプロトコル--2月を掲示します」。
[4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
Message Format", RFC 2440, November 1998.
[4] カラスとJ.とDonnerhackeとL.とフィニーとH.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC2440、1998年11月。
[5] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC
1176, August 1990.
[5] クリスピン、M.、「バージョン2インチ、RFC1176、1990年対話的なメールアクセス・プロトコル--8月。」
[6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC
2060, December 1996.
[6] クリスピン、M.、「バージョン4インチ、RFC2060、1996年インターネットメッセージアクセス・プロトコル--12月。」
[7] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", RFC 822, August 1982.
[7] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、RFC822、1982年8月。
[8] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[8] クロッカーとD.とP.Overell、Eds、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[9] De Winter, J., "SMTP Service Extension for Remote Message Queue
Starting", RFC 1985, August 1996.
[9] De冬、J.、「リモートメッセージキュー始めのためのSMTPサービス拡張子」、RFC1985、1996年8月。
[10] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998.
[10]Fajman、R.、「メッセージ気質通知のための広げることができるメッセージ・フォーマット」、RFC2298、1998年3月。
[11] Freed, N, "Behavior of and Requirements for Internet Firewalls",
RFC 2979, October 2000.
解放された[11]、N、「インターネットのための振舞いと要件ファイアウォール」、RFC2979、2000年10月。
[12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, December 1996.
解放された[12]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年12月。
Klensin Standards Track [Page 68] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[68ページ]RFC2821
[13] Freed, N., "SMTP Service Extension for Command Pipelining", RFC
2920, September 2000.
解放された[13]、N.、「コマンド連続送信のためのSMTPサービス拡張子」、RFC2920、2000年9月。
[14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995.
[14] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「サインされて複合の/がコード化した複合/」、RFC1847、1995年10月。
[15] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
December 1998.
[15]GellensとR.とJ.Klensin、「メッセージ提案」、RFC2476、1998年12月。
[16] Kille, S., "Mapping between X.400 and RFC822/MIME", RFC 2156,
January 1998.
[16]Kille、S.、「X.400とRFC822/MIMEの間のマッピング」、RFC2156、1998年1月。
[17] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[17]HindenとRとS.デアリング、Eds。 「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[18] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for
Message Size Declaration", STD 10, RFC 1870, November 1995.
Klensin(J.)が解放した[18]、N.、およびK.ムーア、「SMTPはメッセージサイズ宣言のための拡大を修理します」、STD10、RFC1870、1995年11月。
[19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
"SMTP Service Extensions", STD 10, RFC 1869, November 1995.
Klensin(J.)が解放した[19]、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPは拡大を修理します」、STD10、RFC1869、1995年11月。
[20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
"SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July
1994.
Klensin(J.)が解放した[20]、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPは8ビット-MIMEtransportのために拡大を修理します」、RFC1652、1994年7月。
[21] Lambert, M., "PCMAIL: A distributed mail system for personal
computers", RFC 1056, July 1988.
[21] ランバート、M.、「PCMAIL:」 「パーソナルコンピュータの分配されたメールシステム」、RFC1056、1988年7月。
[22] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[22]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
December 1996.
[23] ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年12月。
[24] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC 1891, January 1996.
[24] ムーア、K.、「配送状態通知のためのSMTPサービス拡張子」、RFC1891、1996年1月。
[25] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 1894, January 1996.
[25] ムーア、K.、およびG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC1894、1996年1月。
[26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
53, RFC 1939, May 1996.
[26] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」
Klensin Standards Track [Page 69] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[69ページ]RFC2821
[27] Partridge, C., "Mail routing and the domain system", RFC 974,
January 1986.
[27] ヤマウズラ、C.が「ルーティングとドメインシステムを郵送する」、RFC974、1月1986日
[28] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February
1988.
[28] ヤマウズラ、C.が「メッセージとSMTPをコピーする」、RFC1047、2月1988日
[29] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", STD 7, RFC 793, September 1981.
[29] ポステル、J.、教育、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD7、RFC793、9月1981日
[30] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August
1982.
[30] ポステル、J.、「簡単なメール転送プロトコル」、RFC821、1982年8月。
[31] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[31]Ramsdell、B.、エド、「S/MIMEバージョン3メッセージ仕様」、RFC2633、6月1999日
[32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April
2001.
[32] レズニック、P.、エド、「インターネットメッセージ・フォーマット」、RFC2822、4月2001日
[33] Vaudreuil, G., "SMTP Service Extensions for Transmission of
Large and Binary MIME Messages", RFC 1830, August 1995.
[33] ボードルイ、G.、「大きくて2進のMIMEメッセージの伝達のためのSMTPサービス拡張子」、RFC1830、1995年8月。
[34] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
January 1996.
[34] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC1893、1996年1月。
10. Editor's Address
10. エディタのアドレス
John C. Klensin AT&T Laboratories 99 Bedford St Boston, MA 02111 USA
ジョンC.Klensin AT&T研究所99ベッドフォード・St MA02111ボストン(米国)
Phone: 617-574-3076 EMail: klensin@research.att.com
以下に電話をしてください。 617-574-3076 メールしてください: klensin@research.att.com
11. Acknowledgments
11. 承認
Many people worked long and hard on the many iterations of this document. There was wide-ranging debate in the IETF DRUMS Working Group, both on its mailing list and in face to face discussions, about many technical issues and the role of a revised standard for Internet mail transport, and many contributors helped form the wording in this specification. The hundreds of participants in the many discussions since RFC 821 was produced are too numerous to mention, but they all helped this document become what it is.
多くの人々がこのドキュメントの多くの繰り返しのときに長時間懸命に働きました。 IETF DRUMS作業部会には広範囲の討論がありました、メーリングリストと面と向かって議論における両方、インターネット・メール輸送の改訂された規格の多くの専門的な問題と役割に関して、そして、多くの貢献者がこの仕様で言葉遣いを形成するのを助けました。 RFC821が生産されたので、多くの議論の何百人もの関係者が言及できないくらい非常に多いのですが、それらは皆、このドキュメントがそれが何であるかということになるのを助けました。
Klensin Standards Track [Page 70] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[70ページ]RFC2821
APPENDICES
付録
A. TCP Transport Service
A。 TCP輸送サービス
The TCP connection supports the transmission of 8-bit bytes. The SMTP data is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte with the high-order bit cleared to zero. Service extensions may modify this rule to permit transmission of full 8-bit data bytes as part of the message body, but not in SMTP commands or responses.
TCP接続は8ビットのバイトの送信を支持します。 SMTPデータは7ビットのASCII文字です。 高位のビットがゼロまできれいにされている状態で、各キャラクタは8ビットのバイトとして伝えられます。 サービス拡大は、メッセージ身体の一部として完全な8ビットのデータバイトの送信を可能にするようにこの規則を変更しますが、SMTPコマンドか応答で変更するかもしれないというわけではありません。
B. Generating SMTP Commands from RFC 822 Headers
B。 RFC822ヘッダーからSMTPコマンドを発生させます。
Some systems use RFC 822 headers (only) in a mail submission protocol, or otherwise generate SMTP commands from RFC 822 headers when such a message is handed to an MTA from a UA. While the MTA-UA protocol is a private matter, not covered by any Internet Standard, there are problems with this approach. For example, there have been repeated problems with proper handling of "bcc" copies and redistribution lists when information that conceptually belongs to a mail envelopes is not separated early in processing from header information (and kept separate).
いくつかのシステムがメール服従プロトコルだけにRFC822ヘッダーを使用するか、またはさもなければ、RFCからSMTPコマンドを発生させてください。そのようなメッセージがUAからMTAに手渡される822個のヘッダー。 MTA-UAプロトコルはどんなインターネットStandardでも覆われるのではなく、個人的な問題ですが、このアプローチに関する問題があります。 概念的にメール封筒に属す情報が早くヘッダー情報(そして、別々のままである)と処理で切り離されないとき、例えば、"bcc"コピーと再分配リストの適切な取り扱いに関する繰り返された問題がありました。
It is recommended that the UA provide its initial ("submission
client") MTA with an envelope separate from the message itself.
However, if the envelope is not supplied, SMTP commands SHOULD be
generated as follows:
UAが(「服従クライアント」)初期のMTAをメッセージ自体から別々の封筒に供給するのは、お勧めです。 SMTPが封筒が供給されないならどのようにSHOULDを命令しても、以下の通り発生してください:
1. Each recipient address from a TO, CC, or BCC header field SHOULD
be copied to a RCPT command (generating multiple message copies if
that is required for queuing or delivery). This includes any
addresses listed in a RFC 822 "group". Any BCC fields SHOULD then
be removed from the headers. Once this process is completed, the
remaining headers SHOULD be checked to verify that at least one
To:, Cc:, or Bcc: header remains. If none do, then a bcc: header
with no additional information SHOULD be inserted as specified in
[32].
1. 各受取人はTO、CC、またはBCCからヘッダーフィールドSHOULDを記述します。RCPTコマンド(それが列を作りに必要であるなら複数のメッセージコピーを発生させるか、配送)にコピーされてください。 これはRFC822「グループ」で記載されたどんなアドレスも含んでいます。 どんなBCCもSHOULDをさばいて、次に、ヘッダーから取り外されてください。 一度、この過程が完了している、ヘッダーSHOULDのままで残っていて、チェックされて、そんなに少なくとも1つTo:、Cc:、またはBcc:について確かめてください。 ヘッダーは残っています。 そして、なにもbcc:をしません。 [32]の追加情報がないSHOULDが指定されるとして挿入されているヘッダー。
2. The return address in the MAIL command SHOULD, if possible, be
derived from the system's identity for the submitting (local)
user, and the "From:" header field otherwise. If there is a
system identity available, it SHOULD also be copied to the Sender
header field if it is different from the address in the From
header field. (Any Sender field that was already there SHOULD be
removed.) Systems may provide a way for submitters to override
the envelope return address, but may want to restrict its use to
privileged users. This will not prevent mail forgery, but may
lessen its incidence; see section 7.1.
2. メールコマンドSHOULD、できれば提出のためにシステムのアイデンティティから派生している(地方の)ユーザ、および「From:」の返送先 そうでなければ、ヘッダーはさばきます。 アイデンティティ利用可能なシステムがあります、また、それはSHOULDです。それがFromヘッダーフィールドにおけるアドレスと異なるなら、Senderヘッダーフィールドにコピーされてください。 既に、SHOULDがありました。(どんなSenderもそれをさばく、取り除く、) システムは、submittersが封筒返送先をくつがえす方法を提供しますが、使用を特権ユーザに制限したがっているかもしれません。 これは、メール偽造を防ぎませんが、発生を少なくするかもしれません。 セクション7.1を見てください。
Klensin Standards Track [Page 71] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[71ページ]RFC2821
When an MTA is being used in this way, it bears responsibility for ensuring that the message being transmitted is valid. The mechanisms for checking that validity, and for handling (or returning) messages that are not valid at the time of arrival, are part of the MUA-MTA interface and not covered by this specification.
MTAがこのように使用されているとき、それは、送られるメッセージが確実に有効になるようにするために責任を負います。 この仕様によってその正当性をチェックする、および到着時点で有効でない取り扱い(または、帰り)メッセージのためのメカニズムはMUA-MTAインタフェースであって覆われないことの一部です。
A submission protocol based on Standard RFC 822 information alone MUST NOT be used to gateway a message from a foreign (non-SMTP) mail system into an SMTP environment. Additional information to construct an envelope must come from some source in the other environment, whether supplemental headers or the foreign system's envelope.
SMTP環境への外国(非SMTPの)のメールシステムからのゲートウェイaメッセージに単独でStandard RFC822情報に基づく服従プロトコルを使用してはいけません。 封筒を組み立てる追加情報はソースからもう片方の環境で来なければなりません、補足のヘッダーか外国システムの封筒であることにかかわらず。
Attempts to gateway messages using only their header "to" and "cc" fields have repeatedly caused mail loops and other behavior adverse to the proper functioning of the Internet mail environment. These problems have been especially common when the message originates from an Internet mailing list and is distributed into the foreign environment using envelope information. When these messages are then processed by a header-only remailer, loops back to the Internet environment (and the mailing list) are almost inevitable.
それらのヘッダー“to"だけを使用するゲートウェイメッセージと「cc」分野への試みは繰り返してインターネット・メール環境の適切な機能に不利なメール輪と他の振舞いを引き起こしました。 メッセージがインターネットメーリングリストから発して、封筒情報を使用することで外国環境に分配されるとき、これらの問題は特に一般的です。 次に、これらのメッセージがヘッダーだけ「再-郵送者」が処理されるとき、インターネット環境(そして、メーリングリスト)への輪はほとんど必然です。
C. Source Routes
C。 送信元経路
Historically, the <reverse-path> was a reverse source routing list of hosts and a source mailbox. The first host in the <reverse-path> SHOULD be the host sending the MAIL command. Similarly, the <forward-path> may be a source routing lists of hosts and a destination mailbox. However, in general, the <forward-path> SHOULD contain only a mailbox and domain name, relying on the domain name system to supply routing information if required. The use of source routes is deprecated; while servers MUST be prepared to receive and handle them as discussed in section 3.3 and F.2, clients SHOULD NOT transmit them and this section was included only to provide context.
<逆経路>は歴史的に、ホストの逆のソースルーティングリストとソースメールボックスでした。 1番目はホスト発信がメールコマンドであったなら<逆経路で>SHOULDを接待します。 同様に、<フォワードパス>はホストのリストとあて先メールボックスを発送するソースであるかもしれません。 しかしながら、一般に、<フォワードパス>SHOULDはメールボックスとドメイン名だけを含んでいます、必要なら、ルーティング情報を提供するためにドメイン名システムを当てにして。 送信元経路の使用は推奨しないです。 セクション3.3とF.2で論じられるようにそれらを受けて、扱うようにサーバを準備しなければならない間、クライアントSHOULD NOTは彼らを伝えます、そして、このセクションは含まれていましたが、文脈を提供しました。
For relay purposes, the forward-path may be a source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully- qualified domain names. This form is used to emphasize the distinction between an address and a route. The mailbox is an absolute address, and the route is information about how to get there. The two concepts should not be confused.
「: リレー目的のために、フォワードパスは」 形式の送信元経路が@1であったならそうするかもしれなくて、@TWOは JOE@THREE です」、1、2、および3が完全に適切なドメイン名であるに違いないところで。 このフォームは、アドレスとルートの区別を強調するのに使用されます。 メールボックスは絶対アドレスです、そして、ルートはどうそこに到着するかの情報です。 2つの概念は混乱するべきではありません。
If source routes are used, RFC 821 and the text below should be consulted for the mechanisms for constructing and updating the forward- and reverse-paths.
送信元経路が使用されているなら、RFC821と以下のテキストはフォワードと逆経路を組み立てて、アップデートするためのメカニズムのために参照されるべきです。
Klensin Standards Track [Page 72] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[72ページ]RFC2821
The SMTP server transforms the command arguments by moving its own identifier (its domain name or that of any domain for which it is acting as a mail exchanger), if it appears, from the forward-path to the beginning of the reverse-path.
SMTPサーバーはそれ自身の識別子(それがメール交換器として機能しているどんなドメインのドメイン名かものも)を動かすことによって、コマンド議論を変えます、現れるなら、フォワードパスから逆経路の始まりまで。
Notice that the forward-path and reverse-path appear in the SMTP commands and replies, but not necessarily in the message. That is, there is no need for these paths and especially this syntax to appear in the "To:" , "From:", "CC:", etc. fields of the message header. Conversely, SMTP servers MUST NOT derive final message delivery information from message header fields.
フォワードパスと逆経路がメッセージにSMTPコマンドと回答に現れますが、必ず現れるというわけではないのに注意してください。 すなわち、これらの経路と特にこの構文が「To:」に現れる必要は全くありません。 , 「From:」、「CC:」、メッセージヘッダーのなど分野。 逆に、SMTPサーバーが最終的なメッセージ配送情報にメッセージヘッダーフィールドに由来していてはいけません。
When the list of hosts is present, it is a "reverse" source route and indicates that the mail was relayed through each host on the list (the first host in the list was the most recent relay). This list is used as a source route to return non-delivery notices to the sender. As each relay host adds itself to the beginning of the list, it MUST use its name as known in the transport environment to which it is relaying the mail rather than that of the transport environment from which the mail came (if they are different).
ホストのリストが存在しているとき、それは、「逆」の送信元経路であり、メールがリストの上の各ホストを通してリレーされたのを示します(第1代リストにおけるホストは最新のリレーでした)。 このリストは、非引渡通告書を送付者に返すのに送信元経路として使用されます。 各中継ホストがリストの始まりにそれ自体を加えるとき、それはそれがメールが来た輸送環境のものよりむしろメールをリレーしている輸送環境で知られているように(それらが異なるなら)人の名前を引合いに出さなければなりません。
D. Scenarios
D。 シナリオ
This section presents complete scenarios of several types of SMTP sessions. In the examples, "C:" indicates what is said by the SMTP client, and "S:" indicates what is said by the SMTP server.
このセクションはいくつかのタイプのSMTPセッションの完全なシナリオを提示します。 例で「C:」 そして、SMTPクライアントによって言われていることを示す、「S:」 SMTPサーバーによって言われていることを示します。
D.1 A Typical SMTP Transaction Scenario
D.1は典型的なSMTP取引シナリオです。
This SMTP example shows mail sent by Smith at host bar.com, to Jones, Green, and Brown at host foo.com. Here we assume that host bar.com contacts host foo.com directly. The mail is accepted for Jones and Brown. Green does not have a mailbox at host foo.com.
このSMTPの例はホストfoo.comにスミスによってホストbar.comに送られたメールをジョーンズ、グリーン、およびブラウンに示しています。 ここで、私たちは、ホストbar.comが直接ホストfoo.comに連絡すると思います。 ジョーンズとブラウンのためにメールを受け入れます。 グリーンはホストfoo.comにメールボックスを持っていません。
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: RCPT TO:<Brown@foo.com>
S: 220 foo.com SimpleメールTransfer Service Ready C: EHLO bar.com S: 250-foo.comはbar.com Sに挨拶します: 250-8BITMIME S: 250サイズS: 250-DSN S: 250はCを助けます: FROM:<Smith@bar.com に郵送してください、gt;、S: 250 OK C: RCPT TO:<Jones@foo.com 、gt;、S: 250 OK C: RCPT TO:<Green@foo.com 、gt;、S: ここのそのような550人のユーザでない、C: RCPT TO:<Brown@foo.com 、gt。
Klensin Standards Track [Page 73] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[73ページ]RFC2821
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah...
C: ...etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
S: 250 OK C: データS: 354 メール入力を始めてください。 <CRLF><CRLF>Cで、終わってください: 何のかの… C: ...などなどなど C: . S: 250 OK C: Sをやめてください: 221 トランスミッションを終えるfoo.com Serviceが精神を集中します。
D.2 Aborted SMTP Transaction Scenario
D.2はSMTP取引シナリオを中止しました。
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: RSET
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
S: 220 foo.com SimpleメールTransfer Service Ready C: EHLO bar.com S: 250-foo.comはbar.com Sに挨拶します: 250-8BITMIME S: 250サイズS: 250-DSN S: 250はCを助けます: FROM:<Smith@bar.com に郵送してください、gt;、S: 250 OK C: RCPT TO:<Jones@foo.com 、gt;、S: 250 OK C: RCPT TO:<Green@foo.com 、gt;、S: ここのそのような550人のユーザでない、C: RSET S: 250 OK C: Sをやめてください: 221 トランスミッションを終えるfoo.com Serviceが精神を集中します。
D.3 Relayed Mail Scenario
D.3はメールシナリオをリレーしました。
Step 1 -- Source Host to Relay Host
ステップ1--中継ホストの送信元ホスト
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<JQP@bar.com>
S: 250 OK
C: RCPT TO:<@foo.com:Jones@XYZ.COM>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Date: Thu, 21 May 1998 05:33:29 -0700
S: 220 foo.com SimpleメールTransfer Service Ready C: EHLO bar.com S: 250-foo.comはbar.com Sに挨拶します: 250-8BITMIME S: 250サイズS: 250-DSN S: 250はCを助けます: FROM:<JQP@bar.com に郵送してください、gt;、S: 250 OK C: RCPT TO:<@foo.com : ジョーンズ@XYZ.COM>S: 250 OK C: データS: 354 メール入力を始めてください。 <CRLF><CRLF>Cで、終わってください: 日付: 木曜日、1998年5月21日05:33:29 -0700
Klensin Standards Track [Page 74] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[74ページ]RFC2821
C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C: John.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
C: From: ジョンQ. Public <JQP@bar.com 、gt;、C: Subject: 次の重役会の会合C: To: Jones@xyz.com C: C: ビル: C: 次の取締役会はCになるでしょう: 火曜日に。 C: ジョン。 C: . S: 250 OK C: Sをやめてください: 221 トランスミッションを終えるfoo.com Serviceが精神を集中します。
Step 2 -- Relay Host to Destination Host
ステップ2--あて先ホストの中継ホスト
S: 220 xyz.com Simple Mail Transfer Service Ready
C: EHLO foo.com
S: 250 xyz.com is on the air
C: MAIL FROM:<@foo.com:JQP@bar.com>
S: 250 OK
C: RCPT TO:<Jones@XYZ.COM>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Received: from bar.com by foo.com ; Thu, 21 May 1998
C: 05:33:29 -0700
C: Date: Thu, 21 May 1998 05:33:22 -0700
C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C: John.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
S: 220 xyz.com SimpleメールTransfer Service Ready C: EHLO foo.com S: 250 xyz.comは放送されたCです: メール FROM:<@foo.com : JQP@bar.com>S: 250 OK C: RCPT TO:<Jones@XYZ.COM 、gt;、S: 250 OK C: データS: 354 メール入力を始めてください。 <CRLF><CRLF>Cで、終わってください: 受け取られている: foo.comによるbar.comから。 木曜日、1998年5月21日C: 05:33:29 -0700C: 日付: 木曜日、1998年5月21日の05:33:22 -0700C: From: ジョンQ. Public <JQP@bar.com 、gt;、C: Subject: 次の重役会の会合C: To: Jones@xyz.com C: C: ビル: C: 次の取締役会はCになるでしょう: 火曜日に。 C: ジョン。 C: . S: 250 OK C: Sをやめてください: 221 トランスミッションを終えるfoo.com Serviceが精神を集中します。
D.4 Verifying and Sending Scenario
シナリオを確かめて、送るD.4
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 220 foo.com SimpleメールTransfer Service Ready C: EHLO bar.com S: 250-foo.comはbar.com Sに挨拶します: 250-8BITMIME S: 250サイズS: 250-DSN
Klensin Standards Track [Page 75] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[75ページ]RFC2821
S: 250-VRFY
S: 250 HELP
C: VRFY Crispin
S: 250 Mark Crispin <Admin.MRC@foo.com>
C: SEND FROM:<EAK@bar.com>
S: 250 OK
C: RCPT TO:<Admin.MRC@foo.com>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah...
C: ...etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
S: 250-VRFY S: 250はCを助けます: VRFYクリスピンS: 250が Crispin <Admin.MRC@foo.com をマークする、gt;、C: FROM:<EAK@bar.com を送ってください、gt;、S: 250 OK C: RCPT TO:<Admin.MRC@foo.com 、gt;、S: 250 OK C: データS: 354 メール入力を始めてください。 <CRLF><CRLF>Cで、終わってください: 何のかの… C: ...などなどなど C: . S: 250 OK C: Sをやめてください: 221 トランスミッションを終えるfoo.com Serviceが精神を集中します。
E. Other Gateway Issues
E。 他のゲートウェイ問題
In general, gateways between the Internet and other mail systems SHOULD attempt to preserve any layering semantics across the boundaries between the two mail systems involved. Gateway- translation approaches that attempt to take shortcuts by mapping, (such as envelope information from one system to the message headers or body of another) have generally proven to be inadequate in important ways. Systems translating between environments that do not support both envelopes and headers and Internet mail must be written with the understanding that some information loss is almost inevitable.
一般に、インターネットと他のメールシステムSHOULDの間のゲートウェイは、2台のメールシステムの間の境界の向こう側の意味論がかかわったどんなレイヤリングも保存するのを試みます。 ゲートウェイ翻訳はマッピングで近道を取るその試みにアプローチして、一般に、(別のもののメッセージヘッダーか1台のシステムからボディーまでの封筒情報としてのそのようなもの)は重要な方法で不十分であると判明しました。 いくらかの情報の損失がほとんど必然であるという条件で封筒とヘッダーの両方を支えない環境の間で翻訳されるシステムとインターネット・メールを書かなければなりません。
F. Deprecated Features of RFC 821
F。 RFC821の推奨しない特徴
A few features of RFC 821 have proven to be problematic and SHOULD NOT be used in Internet mail.
RFC821の特徴が問題が多いと立証したいくつかとSHOULD NOT、インターネット・メールで使用されてください。
F.1 TURN
F.1はターンします。
This command, described in RFC 821, raises important security issues since, in the absence of strong authentication of the host requesting that the client and server switch roles, it can easily be used to divert mail from its correct destination. Its use is deprecated; SMTP systems SHOULD NOT use it unless the server can authenticate the client.
RFC821で説明されたこのコマンドは、クライアントとサーバが役割を切り換えるよう要求するホストの強い認証がないとき正しい目的地からのメールを紛らすのに容易にそれを使用できるので、重要な安全保障問題を提起します。 使用は推奨しないです。 サーバがクライアントを認証できないなら、SMTPシステムSHOULD NOTはそれを使用します。
Klensin Standards Track [Page 76] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[76ページ]RFC2821
F.2 Source Routing
F.2ソースルート設定
RFC 821 utilized the concept of explicit source routing to get mail from one host to another via a series of relays. The requirement to utilize source routes in regular mail traffic was eliminated by the introduction of the domain name system "MX" record and the last significant justification for them was eliminated by the introduction, in RFC 1123, of a clear requirement that addresses following an "@" must all be fully-qualified domain names. Consequently, the only remaining justifications for the use of source routes are support for very old SMTP clients or MUAs and in mail system debugging. They can, however, still be useful in the latter circumstance and for routing mail around serious, but temporary, problems such as problems with the relevant DNS records.
RFC821は、一連のリレーで1人のホストから別のホストまでメールを受け取るのに明白なソースルーティングの概念を利用しました。 通常のメール交通で送信元経路を利用するという要件はドメイン名システム「Mx」記録の導入で排除されました、そして、それらのための最後の重要な正当化は"@"に続くアドレスがすべて、完全修飾ドメイン名であるに違いないという明確な要件についてRFC1123の序論で排除されました。 その結果、送信元経路の使用のための唯一の残っている正当化は非常に年上のSMTPクライアントかMUAsとメールシステムデバッグでサポートです。 しかしながら、それらはまだ後者の状況と問題などの重大な、しかし、一時的な問題の周りの関連DNS記録があるルーティングメールの役に立っている場合があります。
SMTP servers MUST continue to accept source route syntax as specified in the main body of this document and in RFC 1123. They MAY, if necessary, ignore the routes and utilize only the target domain in the address. If they do utilize the source route, the message MUST be sent to the first domain shown in the address. In particular, a server MUST NOT guess at shortcuts within the source route.
SMTPサーバーは、送信元経路構文がこのドキュメントの本体とRFC1123で指定されていると受け入れ続けなければなりません。 彼らは、必要なら、ルートを無視して、アドレスでターゲット・ドメインだけを利用するかもしれません。 彼らが送信元経路を利用するなら、アドレスに示された最初のドメインにメッセージを送らなければなりません。 特に、サーバは送信元経路の中で近道を推測してはいけません。
Clients SHOULD NOT utilize explicit source routing except under unusual circumstances, such as debugging or potentially relaying around firewall or mail system configuration errors.
珍しい状況を除いて、クライアントSHOULD NOTは明白なソースルーティングを利用します、ファイアウォールの周りのデバッグか潜在的にリレーやメールシステム構成誤りなどのように。
F.3 HELO
F.3 HELO
As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to HELO when the server will accept the former. Servers must continue to accept and process HELO in order to support older clients.
サーバが前者を受け入れるとき、セクション3.1と4.1.1で議論するように、EHLOはHELOより強く好まれます。 サーバは、より年取ったクライアントを支持するためにHELOを受け入れて、処理し続けなければなりません。
F.4 #-literals
F.4#誤字誤植
RFC 821 provided for specifying an Internet address as a decimal integer host number prefixed by a pound sign, "#". In practice, that form has been obsolete since the introduction of TCP/IP. It is deprecated and MUST NOT be used.
RFC821は、「#」と1ポンドのサインによって前に置かれた10進整数ホスト番号としてインターネット・アドレスを指定するのに前提としました。 実際には、TCP/IPの導入以来そのフォームは時代遅れです。 それは、推奨しなく、使用されてはいけません。
F.5 Dates and Years
F.5日付と何年も
When dates are inserted into messages by SMTP clients or servers (e.g., in trace fields), four-digit years MUST BE used. Two-digit years are deprecated; three-digit years were never permitted in the Internet mail system.
SMTPクライアントかサーバ(例えば、跡の分野の)によって日付がメッセージに挿入されるとき、4ケタの年を費やさなければなりません。 2ケタの年は推奨しないです。 3ケタの年はインターネット・メールシステムで決して受入れられませんでした。
Klensin Standards Track [Page 77] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[77ページ]RFC2821
F.6 Sending versus Mailing
郵送に対して発信するF.6
In addition to specifying a mechanism for delivering messages to user's mailboxes, RFC 821 provided additional, optional, commands to deliver messages directly to the user's terminal screen. These commands (SEND, SAML, SOML) were rarely implemented, and changes in workstation technology and the introduction of other protocols may have rendered them obsolete even where they are implemented.
ユーザのメールボックスにメッセージを渡すのにメカニズムを指定することに加えて、RFC821は直接ユーザの端末のスクリーンにメッセージを渡す追加していて、任意のコマンドを提供しました。 これらのコマンド(SEND、SAML、SOML)はめったに実行されませんでした、そして、それらが実行さえされるところでワークステーション技術における変化と他のプロトコルの導入はそれらを時代遅れにしたかもしれません。
Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers MAY implement them. If they are implemented by servers, the implementation model specified in RFC 821 MUST be used and the command names MUST be published in the response to the EHLO command.
クライアントSHOULD NOTはサービスとしてSEND、SAML、またはSOMLを提供します。 サーバはそれらを実行するかもしれません。 それらがサーバによって実行されるなら、RFC821で指定された実現モデルを使用しなければなりません、そして、EHLOコマンドへの応答でコマンド名を発表しなければなりません。
Klensin Standards Track [Page 78] RFC 2821 Simple Mail Transfer Protocol April 2001
メール転送プロトコル2001年4月に簡単なKlensin標準化過程[78ページ]RFC2821
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Klensin Standards Track [Page 79]
Klensin標準化過程[79ページ]
一覧
スポンサーリンク
