Network Working Group J. Klensin, Editor
Request for Comments: 2821 AT&T Laboratories
Obsoletes: 821, 974, 1869 April 2001
Updates: 1123
Category: Standards Track
Simple Mail Transfer Protocol
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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],
- RFC 821の元のSMTP（簡易メール転送プロトコル）仕様[30]、
- domain name system requirements and implications for mail transport from RFC 1035 [22] and RFC 974 [27],
- ドメインネームシステム要件およびRFC 1035からのメール転送のための含意[22]とRFC 974 [27]、
- the clarifications and applicability statements in RFC 1123 [2], and
- RFC 1123で明確化と適用ステートメント[2]、および
- material drawn from the SMTP Extension mechanisms [19].
- SMTP拡張メカニズム[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.
これは、RFC 821、RFC 974を廃止、および更新のRFC 1123は、（RFC 1123のメール輸送材料を置き換えます）。しかし、RFC 821は、1990年代半ばで、いくつかの追加輸送モデル（付録に）インターネットでの重要な用途ではなかったいくつかの機能を指定します。これらのセクションは、明確さと簡潔さのために、ここでは省略されています。それらを必要とする読者は、RFC 821を参照してください。
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.
また、増幅を必要とRFC 1123からいくつかの追加の材料を含んでいます。この材料は、主に、さまざまなリストやニュースグループと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]。追加提出の問題は、RFC 2476 [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
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
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
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上での輸送を議論しながら、他のトランスポートが可能です。 RFC 821の付録は、それらのいくつかを説明します。
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の重要な特徴は、（セクション3.8を参照）、通常は「SMTPのメールリレー」と呼ばれ、ネットワークを介してメールを輸送する能力です。ネットワークは、公共のインターネット上で相互にTCPアクセス可能なホストで構成され、非TCPトランスポート・レベルを利用するいくつかの他のLANまたはWAN環境でのファイアウォール-孤立TCP / IPイントラネット、またはホスト上で相互にTCPアクセス可能なホストプロトコル。使い方
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）のメールエクスチェンジ機構が搬送されるメッセージのために適切な次のホップ先を識別するために使用されます。
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
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サーバーへの双方向送信チャネルを確立します。 SMTPクライアントの責任は、一つ以上の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 ones, and their destinations, are expected to support all of the queuing, retrying, and alternate address functions discussed in this specification.
メールメッセージがSMTPクライアントに提示する手段、およびどのようにそのクライアントがメールメッセージがある転送するためのドメイン名（複数可）を決定するには、ローカルな問題であり、この文書によって対処されていません。いくつかのケースでは、ドメイン名（複数可）に転送し、又はによる決定は、SMTPクライアントは、メールメッセージの最終宛先（複数可）を特定します。他の場合には、POPの実装に関連付けられているSMTPクライアントと共通の[3、26]またはIMAP [6]のプロトコル、またはSMTPクライアントは、単離されたトランスポート・サービス環境内にある場合、決定ドメイン名がそこを通って中間宛先を特定しますすべてのメールメッセージが中継されることになっています。個々のメッセージに関連付けられたターゲット・ドメイン名に関係なく、すべてのトラフィックを転送する、またはそれが最初に完了することができません再試行メッセージ送信のためのキューを維持していないSMTPクライアントは、そうでない場合は、この仕様に準拠していてもよいが、完全に対応とはみなされません。これら少ないできるもので使用リレー、及び目的地を含む完全可能なSMTP実装は、キューイング、再試行、および本明細書で論じられる代替アドレス機能のすべてをサポートすることが期待されます。
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サーバーのIDを決定し、その転送を行うには、この文書で覆われています。 SMTPサーバーへのメール転送を行うために、SMTPクライアントはそのSMTPサーバーへの双方向の伝送チャネルを確立します。 SMTPクライアントは、中間のメールエクスチェンジャホストまたは最終ターゲットホストのいずれかに宛先ドメイン名を解決することにより、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クライアントは、通常、メールトランザクションを開始します。そのようなトランザクションは、それ自体（任意のヘッダまたは他の構造を含む）メッセージ内容のメールや送信の発信元と送信先を指定するための一連のコマンドで構成されています。同じメッセージが複数の受信者に送信されると、このプロトコルは、同じ宛先（または中間リレー）ホストのすべての受信者のためのデータの唯一のコピーの送信を促進します。
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].
サーバーは応答して、各コマンドに応答します。返信は、追加のコマンドが期待されていることを、コマンドが受け入れられたことを示すことがあり、あるいは一時的または永久的なエラー条件が存在していること。セクション2.2で議論するように送信者または受信者を指定するコマンドは、サーバー許可SMTPサービス拡張の要求を含むことができます。ダイアログは、意図的にロックステップ、1つずつ、このようなコマンドパイプライン[13]のように相互に合意された拡張要求によって変更することができません。
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クライアントは、電子メールアドレスやメーリングリスト加入者アドレスの検索の検証として、補助的なサービスのための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.
上記で示唆したように、このプロトコルは、メールの送信のためのメカニズムを提供します。二つのホストが同じ輸送サービスに接続されている場合、この送信は、通常、受信者のホストへの送信者のホストから直接生じます。それらが同じ輸送サービスに接続されていない場合は、送信が一台の以上のリレーSMTPサーバを経由して行われます。いずれかのSMTPリレーとしてまたはいくつかの他の伝送環境へのゲートウェイとして機能する中間宿主は、通常、ドメインネームサービス（DNS）メールエクスチェンジ・メカニズムを使用することによって選択されます。
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の付録）によって決定されます。
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.
RFC 821が完了した後、1990年に開始した努力、約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実装は、基本的な拡張メカニズムをサポートしなければなりません。例えば、サーバーは、任意の特定の拡張子を実装していないと、クライアントが優先EHLOではなくHELOを利用した場合でも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は広く展開されており、高品質の実装は非常に堅牢であることが判明しました。しかし、インターネットコミュニティは現在、いくつかのサービスは、プロトコルが最初に設計されたときに想定していなかったことが重要であると考えています。これらのサービスのサポートが追加される場合、それは許容できる作業を継続するために古い実装が可能な方法で行われなければなりません。拡張フレームワークの構成は次のとおりです。
- The SMTP command EHLO, superseding the earlier HELO,
- SMTPコマンドEHLO、以前のHELOに取って代わります、
- 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]。
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サービスを拡張するコストが便益を上回る可能性が高いでしょう。
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キーワード値は、各拡張子に関連付けられています。 IANAに登録された各サービス拡張は、正式な標準化過程かIESGが承認した実験プロトコル文書で定義する必要があります。定義が含まれている必要があります
- 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);
- 拡張機能に関連付けられた任意の追加SMTP動詞（追加の動詞が通常であろう、しかし、EHLOキーワード値と同じである必要はありません）。
- any new parameters the extension associates with the MAIL or RCPT verbs;
- 任意の新しいパラメータMAILや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の最大長さを増加させる増加。
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」-prefixedキーワード値を提供してはいけません。
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」で始まらない動詞は常に登録する必要があります。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります以下に説明するように解釈されます。
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
1.この単語、または用語「REQUIRED」または「SHALL」は、定義が仕様の絶対的な要件であることを意味しなければなりません。
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
2.このフレーズ、または句「SHALL NOT」は、定義が仕様の絶対禁止であることを意味してはなりません。
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.この単語、あるいは形容詞「推奨」は、特定の項目を無視する特定の事情の正当な理由が存在し得ることを意味する必要がありますが、完全な意味合いは異なるコースを選択する前に理解し、慎重に検討する必要があります。
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.「推奨しない」このフレーズ、または句は、特定の行動が、許容できるかさえも有用であるが、完全な意味合いを理解すべきであるとする場合は慎重に任意の動作を実装する前に計量したときに、特定の状況では正当な理由が存在し得ることを意味すべきではありませんこのラベルで説明しました。
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 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.)
5.この単語、あるいは形容詞「OPTIONAL」は、項目が本当に任意であることを意味するかもしれません。一つのベンダーは、ベンダーが他のベンダーは同じ項目を省略するかもしれないが、それは製品を強化することを感じているので、特定の市場がそれを必要とするため、または項目を含めるように選択することができます。特定のオプションを含まない実装を低減機能をけれども、おそらく、オプションが含まれています別の実装と相互運用するために準備されなければなりません。同じ静脈内の特定のオプションを含んでい実装オプションが含まれていない別の実装と相互運用するために準備されなければならない（もちろん、オプションが提供する機能のために、除いて）。
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プロトコルユニットの系列として送信されます。これは、（エラーレポートが向けられる先の）発信元アドレスで構成されています。一つ以上の受信者のアドレス。そしてオプションのプロトコル拡張材料。歴史的には、受信者のアドレス指定コマンド（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プロトコルユニットに送信され、二つの部分有している：ヘッダとボディを。コンテンツは、他の現代の規格に準拠している場合、ヘッダーはメッセージフォーマット仕様のように構造化フィールド/値のペアのコレクションを形成する[32]。本体は、構造場合、MIME [12]に従って定義されます。コンテンツは、自然の中で、テキストである、[1] US-ASCIIレパートリーを使用して表現。 （例えば「8BITMIME」として[20]）SMTP拡張は、コンテンツ本体は、この制限を緩和することができるが、コンテンツのヘッダは常にUS-ASCIIレパートリーを使用して符号化されます。 MIME拡張は、[23]は、依然としてUS-ASCIIレパートリーを使用してそれらを符号化しながら、US-ASCIIレパートリー外部ヘッダ値を表現するためのアルゴリズムを定義します。
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.
RFC 821では、SMTPトランザクションに参加する二つのホストが「SMTP送信者」と「SMTP受信機」と記載しました。この文書は、それぞれ、現在の業界の専門用語を反映するように変更となり、「SMTPクライアント」（または時々ちょうど「クライアント」）と「SMTPサーバ」（または単に「サーバ」）としてそれらを参照されました。指定したホストは、明確にするために必要な場合、「受信機」と「送信者」の用語がまだ使用され、リレーの状況で、サーバーとクライアントの両方として作用することができるので。
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 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.
RFC 821が公開されたと、どこ便利な、本明細書中で使用された後に追加のメールシステム用語が一般的になりました。具体的には、SMTPサーバーとクライアントは、メール転送サービスを提供するため、「メール転送エージェント」（のMTA）として機能します。 「メールユーザーエージェント」（のMUAかのUA）は、通常のメールのソースおよびターゲットとして考えられています。ソースに、MUAは、ユーザから送信されるメールを収集する可能性があり、MTAにそれを渡します。 （「送達」）最終MTAは、MUAにオフメールを渡すとして（又は少なくともそれに責任を転送する、例えば、「メッセージストア」のメッセージを堆積させることによって）と考えるであろう。しかし、これらの用語は、他の環境で高精度の少なくとも外観で使用されている間、のMUAとMTA間の暗黙の境界は、多くの場合、正確に共通一致していない、とインターネットメールで、プラクティスを適合する。したがって、読者はこれらの用語は、他の場所で使用された場合に暗示される可能性があります強力な関係と責任を推論については慎重でなければなりません。
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プロトコルをサポートします。ホストは（「ドメイン」を参照）の名前で知られています。数値アドレスによってそれらを識別することは推奨されません。
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]）[1]をASCII文字セットから引き出された文字、数字、およびハイフンのシーケンスで構成するSMTPのために制限されています。ドメイン名は、ホストのドメイン名の階層内の他のエンティティの名前として使用されています。例えば、ドメインは、エイリアス（CNAME RRのラベル）やメールを配信する代わりにホスト名を表すために使用されるメールエクスチェンジレコードのラベルを参照することができます。 [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トランザクションに現れてはいけません。
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セッションは、両当事者は慎重に現在の状態の一般的な見解を維持して、ステートフルです。この文書では、「バッファ」とするためにクライアントによって使用されてもよいサーバ上の「状態テーブル」仮想によってこの状態をモデル化する、例えば、「状態テーブルをリセット」「バッファをクリア」または情報を引き起こしますバッファで廃棄されると状態は、いくつかの以前の状態に戻すことが。
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文字「CR」（16進値0D）で終了ゼロ以上のデータ文字のASCII文字「LF」（16進値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>シーケンスとしてそれらを伝えなければなりません。
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.
この仕様は、これらのシステムは、電子メールを送信するに果たす役割に基づいてSMTPシステムの4種類、の間で区別されます。 （時々、SMTP発信元と呼ばれる）「発信元」システムは、輸送サービス環境に、または、より一般的にインターネットへのメールを紹介します。 「送達」SMTPシステムは、トランスポートサービス環境からメールを受信し、メールユーザエージェントがその後のアクセスが予想されるメッセージストア内のメールユーザエージェントまたは堆積それに渡すものです。 （通常は単に「中継」と呼ぶ）「リレー」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リレーシステムに許可されていないメッセージへの変換を実行することを必要とするかもしれません。本明細書の目的のために、アドレスを書き換えるファイアウォールは（[11]参照）、SMTPをそれらの両側に使用しても、ゲートウェイとして考慮されるべきです。
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]構造化メッセージ本文のための標準的なメカニズムを提供します。
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.
本明細書中で使用されるように、「アドレス」は、メールが送信されますか、どのメールに場所が堆積割り当て対象ユーザを識別する文字列です。用語「メールボックス」は、その供託を指します。メールが置かれる場所（メールボックス）と、それへの参照（アドレス）との間の区別が重要でない限り、二つの用語は、典型的には、交換可能に使用されます。アドレスは通常、ユーザーとドメインの仕様で構成されています。現代的な使い方が簡単な「ユーザー名」よりもアプリケーションのはるかに広いセットを許可：標準のメールボックスの命名規則は、「ローカルパート@ドメイン」になるように定義されます。これにより、中間ホストがそれらを変更することにより、輸送を最適化することを試みてきた問題の長い歴史のために、局所的な部分のみアドレスのドメイン部分に指定されたホストによってセマンティクスを解釈し、割り当てられなければなりません。
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]の補足とより具体的な完了コードの使用を含む応答ストリングのさらなる構造を指定しています。
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コマンドと応答は剛性の構文を持っています。すべてのコマンドは、コマンド動詞で始まります。すべての返信は3桁の数字コードで始まります。いくつかのコマンドと応答では、引数は動詞またはリプライコードに従わなければなりません。いくつかのコマンドは、自由形式のテキストで、時には必要に応じて、（動詞の後に）引数を受け入れていない、といくつかのリプライコードが続いています。どちらの場合も、テキストが表示される場所、それが空白文字によって動詞またはリプライコードから分離されています。コマンドと応答の完全な定義はセクション4に表示されます。
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.
動詞と引数の値（例えば、「TO：」または「へ：」RCPTコマンドと拡張名のキーワードでは）（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.
本明細書（及びRFC 821）に違反していくつかのSMTPサーバーは、コマンド動詞が大文字でクライアントによってコードされることを必要とします。実装は、これらのサーバーに対応するために、このエンコーディングを使用したいかもしれません。
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 set other than US-ASCII; receiving systems SHOULD reject such commands, normally using "500 syntax error - invalid character" replies.
コマンドと応答はASCII文字セットの文字で構成されている[1]。トランスポートサービスが8ビットバイト（オクテット）伝送チャネルを提供する場合、それぞれ7ビットの文字はゼロにクリア上位ビットとオクテットで右揃え送信されます。具体的には、拡張されていないSMTPサービスは7ビットの輸送を提供します。成功した特定のサーバーとの適切な拡張子を交渉していない元のSMTPクライアントは、オクテットの最上位ビットの情報を含むメッセージを送信してはなりません。このようなメッセージは、この規則に違反して送信されている場合は、SMTPサーバーを受信する上位ビットをクリアするか、または無効としてメッセージを拒否するかもしれません。一般的には、リレーSMTPは、受信したメッセージの内容が有効であることを前提とすべきであると、エンベロープがそうする許可と仮定して、その内容を検査せずに、それを中継します。コンテンツが誤ってラベル付けされ、データパスが実際のコンテンツを受け入れることができない場合はもちろん、これは、受信者に深刻な文字化けメッセージの最終的な送達をもたらすことができます。配信SMTPシステムは、そのようなメッセージを（「バウンス」）拒否ではなく、それらを配信することができます。いいえ、送信SMTPシステムがUS-ASCII以外の任意の文字セットで封筒のコマンドを送信することが許可されていません。回答 - 受信システムは、通常、「無効な文字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は、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.
この文書で使用されているメタ言語表記は他のインターネットメールシステムの文書で使用される「増補BNF」に対応します。その構文に精通していない読者はABNF仕様に相談すべきである[8]。テキストの実行に使用されるメタ言語用語は、明確にするために括弧（例えば、<CRLF>）で囲まれています。
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に提示されています
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
554応答は、このアプローチを取って、サーバがまだ送信するために、クライアントのを待たなければならない代わりに、220の初期接続口メッセージで与えられてもよい：SMTPプロトコルは、次のように、まだ初期の接続を可能にしながら、サーバが正式に取引を拒否することができます接続を閉じる前に（セクション4.1.1.10を参照）QUITとして任意の介在するコマンドに応答すべき
"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接続を行うための試みがエラーである可能性がありますので、接続口に554応答を返すサーバは、送信側システムのデバッグを容易にするために、応答テキストに十分な情報を提供する必要があります。
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.
サーバが歓迎のメッセージを送信し、クライアントがそれを受け取った後、クライアントは通常、クライアントのIDを示し、サーバーへのEHLOコマンドを送信します。セッションを開くことに加えて、EHLOを使用すると、クライアントはサーバがサポートしている拡張子のリストを提供するサービス拡張と要求を処理することが可能であることを示しています。開始されてメールセッションにサービス拡張を必要としないサービス拡張と現代的なクライアントをサポートすることができない古いSMTPシステムは、HELOの代わりにEHLOを使用するかもしれません。サーバはHELOコマンドの拡張EHLOスタイルの応答を返してはなりません。サーバはEHLOへの「コマンドが認識されない」応答を返す場合、特定の接続の試みのために、クライアントはフォールバックし、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の場合）。
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つのステップがあります。トランザクションは、送信者の識別を与えるMAILコマンドで起動します。一つ以上のRCPTコマンドの一連の受信情報を与え、以下;（セクション4.1.4を参照。なしメールトランザクションが進行中でない場合にのみ、一般的に、メールコマンドが送信されてもよいです）。そして、DATAコマンドはメールデータの転送を開始しても、トランザクションを確認し、データ指標、「メールの終わり」で終了します。
The first step in the procedure is the MAIL command.
手順の最初のステップはMAILコマンドです。
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
<リバースパス> SP <メールパラメータ> <CRLF> FROM MAIL
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 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.
このコマンドは、新しいメールトランザクションが開始され、任意の受信者またはメールデータを含むすべての状態テーブルおよびバッファをリセットすることをSMTP-受信機に指示します。 <リバースパス>最初または唯一の引数の部分がエラーを報告するために使用することができる（「<」と「>」括弧の間に）元のメールボックスを、（エラー報告の説明はセクション4.2を参照）を含みます。受け入れた場合、SMTPサーバーは250 OK応答を返します。メールボックスの仕様が何らかの理由で受け入れられない場合、サーバは障害が永続的（クライアントが再度同じアドレスを送信しようとした場合、すなわち、再び発生します）、または一時的であるかどうかを示す応答を返さなければならない（つまり、アドレスが受け入れられるかもしれませんクライアントは、後で再試行している場合）。この要件の見かけの範囲にもかかわらず、（RCPTコマンドで）は、1つまたは複数のフォワードパスを調べることができるまで、リバースパスの良否が判別できない可能性のある状況があります。そのような場合、サーバは、合理的に（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).
歴史的に、<リバースパス>ただメールボックス以上のものを含むことができ、しかし、現代のシステムは、（付録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.
このコマンドの最初または唯一の引数は、一つの受信者を識別するフォワードパス（常に「<」と「>」括弧で囲まれた通常のメールボックスとドメイン）が含まれます。受け入れた場合、SMTPサーバーは250 OK応答を返し、フォワードパスを格納します。 （他の状況及び応答コードが可能である）とメールボックス名 - 受信者が送達アドレスではないと分かっている場合、SMTPサーバは、典型的には、「そのようなユーザNO」などの文字列と、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).
<フォワードパス>単なるメールボックス以上のものを含めることができます。歴史的には、<フォワードパス>（付録Cを参照）しかしながら、現代のSMTPクライアントはソースルートを利用するべきではない、ホストのソースルーティングリストと宛先メールボックスとすることができます。サーバは、往路でソースルートのリストに遭遇する準備しなければなりませんが、ルートを無視すべきであるか、彼らが意味するものではリレーをサポートするために低下する可能性があります。同様に、サーバは、他のホストやシステム宛てのメールを受け入れるために低下する可能性があります。これらの制限は、完全なSMTP機能をサポートしないクライアント用のリレーとしてサーバが無用にします。その結果、制限された機能のクライアントは、インターネット上の任意のSMTPサーバがメール処理（中継）サイトとして使用することができると仮定してはいけません。 RCPTコマンドは、以前のMAILコマンドなしで表示された場合は、サーバが応答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コマンド（またはサービス拡張で指定されたいくつかの別）です。
DATA <CRLF>
DATA <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サーバーは354中間応答を返し、メッセージテキストするメールデータ終了インジケータを含む、すべての後続の行までではなく、と考えています。テキストの端が正常に受信され、格納されるときSMTPレシーバは、250 OK応答を送信します。
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だけを含む行を送信することにより、メールデータの終わりを示します「」 （ピリオドまたはフルストップ）。透明手順は、ユーザーのテキストとの干渉から、これを防止するために使用される（セクション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サーバーは250 OK応答を返します。 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.
- 何MAIL、または全くRCPTコマンド、またはそのようなすべてのコマンドが拒否されましたがなかった場合、サーバ「は、配列のうちコマンド」（503）を返したり、「有効な受信者」（554）は、DATAコマンドに応答して返信しません。これらの応答（または任意の他の5yz応答）のいずれかが受信された場合、クライアントはメッセージデータを送ってはいけません。 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.
しかし、実際には、いくつかのサーバは、メッセージテキストが受信されるまで受信者の検証を行いません。これらのサーバは「その後の失敗」のような1つまたは複数の受信者のために、障害を治療し、（または同等の）データが受け入れられた後、それが困難にコードを返信「が見つかりません550メールボックス」を使用してセクション6で説明したようにメールメッセージを返すべきまたは失敗した受信者を決定するために、クライアントのために不可能。
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,
RFC 822フォーマット[7、32]を使用している場合、メールデータは、日付、件名としてメモヘッダ項目から、CC、にを含みます。サーバSMTPシステムは、RFC 822またはMIME [12]メッセージヘッダ又はメッセージ本文に知覚される欠陥に基づいてメッセージを拒否すべきではありません。特に、
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-せずに表示されるメッセージを拒否してはなりません。
Mail transaction commands MUST be used in the order discussed above.
メールトランザクションコマンドは、上記の順番で使用しなければなりません。
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.
サポートの転送ほとんどの場合内のアドレスを統合して簡素化するために必要な、またはそれに相対され、いくつかの企業とそれほど頻繁に現在のもので、人の前にアドレスをリンクするアドレスを確立します。 （送信者にサーバ通知なし）メッセージのサイレント転送は、セキュリティや非開示の目的のために、現代のインターネットでは一般的です。
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プロトコルを介して「最終」アドレスの曝露に対して主張しています。最終アドレスにも送信者が到達可能でないかもしれないとき、これは特に重要であろう。従って、RCPTからRFC 821のセクション3.2に記載された「転送」機構、及び特に251（補正先）と551の応答コードは、これらの構成のシステムによって、それらが利用可能である場合、実装者によって慎重に評価しなければなりません。
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.
*彼らはアドレスの変更を認識しているとき、サーバーがメッセージを転送することができます。彼らがそうするとき、彼らは251のコードでアドレスの更新情報を提供することができるのいずれか、または「静かに」転送すると250コードを返すことがあります。 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サーバの実装が強く、彼らは望ましくない情報を開示することを結論サイトでは、その使用を無効にするか、または制限することができるように設定メカニズムを提供することが奨励されています。
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コマンドで行われます。実装は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
ユーザー名<ローカル部@ドメイン>ローカルパート@ドメイン
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の引数であるネームサーバが曖昧に注意したり代替案を識別することができるのいずれか、複数のメールボックスを特定することができました。つまり、次のいずれかが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-ジョー・スミス<jsmith@foo.com> 553-ハリー・スミス<hsmith@foo.com> 553メルビン・スミス<dweep@foo.com>
or
または
553-Ambiguous; Possibilities 553- <jsmith@foo.com> 553- <hsmith@foo.com> 553 <dweep@foo.com>
553-あいまい。可能性553- <jsmith@foo.com> 553- <hsmith@foo.com> 553 <dweep@foo.com>
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 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.
通常の状況下では、553応答を受信したクライアントは、ユーザーに結果を公開することが期待されます。必要に応じて与えられた正確な形態の使用、および「ユーザー曖昧」または多分に記載されているような拡張応答コードで補足「曖昧」のキーワード、[34]は、他の言語に自動翻訳を促進します。もちろん、高度に自動化されたか、それが英語より別の言語で動作していたクライアントは、返信のリテラルテキストよりも、ユーザーにいくつかの他の表示を返すために、またはいくつかの自動化された行動を取るために、応答を翻訳しようとすることを選択するかもしれませんそのようなユーザーに報告する前に、追加情報については、ディレクトリサービスをコンサルティングなど。
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つのメールボックスを含むメーリングリストを有することが可能です。リクエストがメーリングリストにVRFYを適用するためになされた場合のメッセージは非常にリストの全員に配信されるだろう対処した場合、肯定応答が（それ以外の場合はエラーが報告されるべきで、与えられる例えば、「メーリングリストで550を、ないユーザー」または 『）』メーリングリストのメンバーを確認することができませんでした252。要求は、ユーザ名を展開するためになされた場合、サーバは、一名を含むリストからなる肯定応答を返してもよいし、エラーが報告されてもよい（例えば、「ユーザ名ではなく、メーリングリストである550」）。
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コマンドの実装では、「ユーザー名」としてローカルのメールボックスの少なくとも認識を含まなければなりません。現在のインターネットの練習は、多くの場合、複数のドメイン、ホスト、この機能を提供し、特にホストのためのメールを処理する単一のホストにつながるので、「ユーザー名」と「ローカル部@ドメイン」の形式を受け入れるべきです。ホストはまた、「ユーザー名」など、他の文字列を認識することを選択するかもしれません。
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@isi.edu> S：250-フレッドFonebone <Fonebone@physics.foo-u.edu> S：250サムQ.スミス<SQSmith@specific.generic。コム>
or
または
C: EXPN Executive-Washroom-List S: 550 Access Denied to You.
C：EXPNエグゼクティブ・洗面所・リストS：あなたに拒否されました550アクセス。
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コマンドの引数がメーリングリストを含むファイルのファイル名にすることが適切かもしれませんが、再度、インターネットのファイル命名規則の様々なものがあります。同様に、これらのコマンドによって戻されるものの歴史的変動は、応答が全く場合は、非常に慎重に解釈されるべきであり、一般的にのみ診断目的のために使用されるべきであるようなものです。
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.
通常の（2yzまたは551）応答はVRFYまたはEXPN要求から返された場合、応答は通常、メールボックス名を含み、すなわち、「<ローカル部@ドメイン>」、「ドメイン」は、完全修飾ドメイン名である場合には、表示されなければなりません。構文インチこの仕様の意図に違反し正当化するのに十分な例外的な状況では、自由形式のテキストが返されることがあります。コンピュータと人間の両方で解析を容易にするために、アドレスが括弧に表示されます。アドレスではなく、自由形式のデバッグ情報は、返却された場合、EXPNとVRFYは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.
サーバ実装はVRFYとEXPNの両方をサポートする必要があります。セキュリティ上の理由から、実装は、ローカルインストールに設定オプションまたは同等を通じて、これらのコマンドのいずれかまたは両方を無効にする方法を提供することができます。これらのコマンドがサポートされている場合は、それらがサポートされているリレーするとき、リレー間で動作する必要はありません。彼らはRFC 821で両方のオプションだったので、それらがサポートされている場合、彼らは、EHLO応答におけるサービスの拡張としてリストされなければなりません。
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（構文エラー、認識されないコマンド）が返されるべきです。他の場所で述べたように、VRFYとEXPNの（実際のアドレスを確認し、情報を返すという意味での）実装が強く推奨されています。したがって、VRFY 500または502を返す実装は、この仕様に完全に準拠していません。
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.
サーバーが別のサーバーやドメインのメール交換器として機能している場合は特に、アドレスが有効であるように思われるが、合理的にリアルタイムで確認することができない状況があるかもしれません。この場合の「見かけの有効性」は、通常、少なくとも構文チェックを伴うだろうし、指定した任意のドメインがホストがメールを中継することができると期待するものであったことが検証を必要とするかもしれません。このような状況では、コード252が返されるべきで返信。これらの場合は、セクション2.1で議論RCPT検証の議論が平行です。同様に、セクション3.4で議論は認識されるが、それは転送またはバウンスされるアドレスを示すためにVRFY（およびEXPN）と応答コード251及び551の使用に適用されたメールであった彼らのために受け取りました。実装は、一般的に、それがそうするように少し時間がかかる場合でも、RCPTの場合よりもVRFYの場合のアドレス検証についてより積極的であるべきである（SHOULD）。
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レコードを持つ）、メールボックス（ローカルホストの別名の様々なタイプ）のため、様々なプロキシの手配のホストのためのインターネット上のメールでのエイリアシングシステムの伝播が、それはほとんど不可能これらの戦略が機能するために作られています一貫して、メールシステムはそれらを試みるべきではありません。
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で使用されている場合にのみ解決可能、完全修飾ドメイン名（FQDN）が許可されています。そのターゲット解決することができ、ひいては、MX又は資源レコードにCNAMEのRRであるように、他の言葉で、（セクション5で説明したように）MXのRRまたはのRRに解決することができる名前は、許可されています。ローカルニックネームまたは非修飾名を使用してはいけません。 FQDNを必要とするルールには、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.
- EHLOコマンドで指定されたドメイン名は、プライマリホスト名ホストが何名、セクション4.1.1.1に記載されるようなリテラルアドレスを持っていない場合、または（A RRに解決されるドメイン名）のいずれかでなければなりません。
- 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コマンドで使用することができる（セクション4.1.1.3を参照）ので、使用される場合に受け入れなければなりません。
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]は、インターネットメールシステムでは、明示的なソースルートの使用が不要になります。彼らの解釈と多くの歴史的な問題は、それらの使用は望ましくない作られています。 SMTPクライアントは、異常な状況を除いて、明示的なソースルートを生成するべきではありません。 SMTPサーバは、メールリレーとして機能するか、ソースルートを指定したアドレスを受け入れるために低下する可能性があります。ルート情報に遭遇すると、SMTPサーバは、ルート情報を無視し、単にルートの最後の要素として、指定された最終的な宛先に送信することが許可されており、そうするべきです。送信者がすべての問題を解決するためにソースルーティングで指定された中間宿主を頼りにして、送信先の名前としてDNSには表示されません名前を使用しての不正な練習がありました。ソースルートが取り除かれている場合、このような行為は故障の原因となります。これは、SMTPクライアントが無効なソースルートを生成したり、名前のシリアル解像度に依存してはなりませんいくつかの理由の一つです。
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.
ソースルートを使用しない場合、往路と逆の経路を構築するためのRFC 821に記載された方法が適用されないと配信時の逆パスは、単にMAILコマンドに登場アドレスあろう。
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クライアントとなる（セクション5の規則に従って）DNSで指定された次のSMTPサーバに伝送チャネルを確立し、それをメールを送信します。それは政策上の理由から、特定のアドレスにメールを中継するために拒否した場合、550応答が返されます。
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は、ここで指定したように、理想的にこの役割に適していない、との仕事は、最終的には、現在の慣行に取って代わる可能性がある標準化されたメール送信プロトコルに進行中です。これらの構成がプライベートであり、この仕様の範囲外にあるので、いずれにせよ、彼らはここに記載されていません。
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]を参照します）。
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サーバは、通知メッセージを輸送問題についての通知メッセージを送ってはいけません。エラー報告でループを防止するための一つの方法は、通知メッセージのMAILコマンドでヌル逆パスを指定することです。そのようなメッセージが送信されると逆の経路は、（追加の議論についてはセクション4.5.5を参照）をnullに設定しなければなりません。次のようにヌルリバースパスを持つMAILコマンドが表示されます。
MAIL FROM:<>
MAIL 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を参照してください）。
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サーバが一つのトランスポートサービスと他との間の変換機能を実行することを必要とするかもしれません。このようなシステムは、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.
そのような別のメールフォーマットやプロトコル等の異なるメール環境との間のゲートウェイメールが複雑であり、容易に標準化し得ません。しかし、いくつかの一般的な要件は、インターネットや他のメール環境間のゲートウェイのために与えられてもよいです。
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.
メッセージがメール環境の境界を越えて、ゲートウェイ処理されているように、ヘッダフィールドは、必要なときに書き換えられます。これは、メッセージボディを検査またはセクション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).
インターネットへのゲートウェイさ他のメールシステムは、多くの場合、RFC 822のヘッダーのサブセットを使用するか、別の構文と同様の機能を提供しますが、これらのメールの一部は、システムは、SMTPエンベロープに相当するものはありません。メッセージがインターネット環境を離れるときしたがって、メッセージヘッダにSMTPエンベロープ情報を折り畳むことが必要であり得ます。可能な解決策は、エンベロープ情報（：と「X-SMTP-RCPT：」例えば、「X-SMTP-MAIL」）を運ぶために新しいヘッダフィールドを作成することであろう。しかし、これは外国の環境でメールプログラムの変更を必要とし、個人情報の開示を危険にさらす可能性がある（7.2節を参照してください）。
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:" 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.
「受信：」他の環境から発信されたメッセージのフィールドは、この仕様に厳密に準拠しない場合があります。しかし、受信の最も重要な用途：行は、メールの障害をデバッグするためであり、このデバッグは厳しく、受信した「修正」しようとする善意のゲートウェイによって妨害することができます：行を。非SMTP環境で発生するトレースフィールドの別の結果として、システムを受信するトレースフィールドのフォーマットに基づいてメールを拒否してはならないと予想外の情報や、それらの分野の形式の光の中で非常に堅牢であるべきである（SHOULD）。
The gateway SHOULD indicate the environment and protocol in the "via" clauses of Received field(s) that it supplies.
ゲートウェイは、それが供給する受信電界の「経由」の句（S）環境およびプロトコルを示すべきです。
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.
インターネット側からは、ゲートウェイはSMTPコマンドでとRFC 822のヘッダー内のすべての有効なアドレス形式、およびすべての有効なRFC 822件のメッセージを受け入れる必要があります。ゲートウェイによって生成されたアドレスとヘッダが（これとRFC 822を含む）に適用インターネット標準に従わなければなりません。ゲートウェイは、勿論、3.3節の他のSMTPシステムのために記載されたもののようなソースルートを処理するための同じ規則の対象となっています。
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.
ゲートウェイは、インターネットメール環境に転送したメッセージの全てのヘッダフィールドは、インターネットメールのための要件を満たしていることを確認しなければなりません。具体的には、「から：」内のすべてのアドレス「：を」、「CC：」、などは、フィールドは唯一の完全修飾ドメイン名を参照する必要があり、RFC 822の構文を満たすために（必要ならば）変換しなければならない、とでなければなりません効果的かつ応答を送信するのに便利。フィールド（または：外国のメール環境からそのエラー・メッセージを確認する必要があります別の環境のプロトコルへのインターネットプロトコルからのメールを変換するために使用される変換アルゴリズムはない「から」に記載されている送信者に、SMTPエンベロープからリターンパスに配信されますRFC 822メッセージの他のフィールド）。
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.
インターネットに別の環境からのメッセージを転送するとき、外来環境によって供給された場合、同様に、ゲートウェイは、エラーメッセージのリターンアドレスに従ってエンベロープリターンパスを設定する必要があります。外国人の環境は全く同等の概念を持っていない場合は、ゲートウェイは、最後のデフォルトとしてメッセージの発信元のアドレスで、最良の近似を選択して使用する必要があります。
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応答を発行し、クライアントからのさらなる指示を待って、未知のコマンドの寛容であると予想されます。
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サーバーが終了する前に、SMTPクライアントに421応答コードを含む行を送信しようとすべきです。 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応答を受信し、それに応じて行動していた場合。
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.
SMTP対応のホストは、別名と複数の配信用アドレス拡張のリストモデルの両方をサポートする必要があります。メッセージが配信または拡張リスト形式の各アドレスに転送されると、エンベロープ内のリターンアドレス（「からのメールは：」）のリストを管理している人や他のエンティティのアドレスに変更しなければなりません。しかし、この場合には、メッセージヘッダ[32]まましなければなりません。具体的には、メッセージヘッダの「から」フィールドは影響を受けません。
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.
重要なメール機能は、宛先メールボックスアドレスのリストに擬似メールボックスのアドレスを変換する（または「拡張」または「爆発」）により、単一のメッセージの同報配信するための機構です。メッセージが（時々「発破」と呼ばれる）、このような疑似メールボックスに送信されると、コピーが展開されたリスト内の各メールボックスに転送または再配布されます。サーバは単にリスト上のアドレスを利用すべきです。そのような発信者のようないくつかのアドレスを、排除する経験則または他のマッチングルールの適用は、強く推奨されます。私たちは、拡張ルールに応じて、「エイリアス」または「リスト」のような疑似メールボックスを分類します。
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.
エイリアスを展開するには、受信者のメーラは、単に順番に拡大したアドレスのそれぞれに封筒で疑似メールボックスアドレスを置き換えます。エンベロープとメッセージ本体の残りの部分は変更されません。メッセージは、配信または各拡張アドレスに転送されます。
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 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.
メーリングリストは「再配布」でなく、「転送」することによって動作すると言うことができます。リストを展開するには、受信者のメーラーは、拡張アドレスの全てを封筒で疑似メールボックスアドレスを置き換えます。最終配達によって生成されたすべてのエラーメッセージはリスト管理者に返却されるように封筒にリターンアドレスではなく、一般的にリストの内容を管理していないと、一般的なエラーメッセージ迷惑を見つけるメッセージの発信に、変更されました。
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>で終了する文字列です。コマンド自体はパラメータが続くと<CRLF>そうでない場合は、<SP>によって終了アルファベット文字です。 （改善相互運用性の関心では、SMTPの受信機は、終端<CRLF>の前に空白を末尾容認することをお勧めします。）メールボックスのローカル部分の構文は、サイトの規則およびセクション4.1.2で指定された構文を受信機に適合しなければなりません。 SMTPコマンドは以下で議論されています。 SMTPの応答はセクション4.2に記載されています。
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.
メールトランザクションは、別のコマンドの引数として伝達されるいくつかのデータオブジェクトを含みます。リバースパスはMAILコマンドの引数は、フォワードパスは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）はパラメータを許可しないように指定されています。クライアントがサーバによって提供され、受け入れられた固有の拡張機能がない場合には、クライアントがそのようなパラメータを送ってはいけませんし、サーバーは、無効な構文を持つものとしてそれらを含むコマンドを拒否すべきです。
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 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.
これらのコマンドは、SMTPサーバにSMTPクライアントを識別するために使用されています。 1が利用可能な場合、引数フィールドには、SMTPクライアントの完全修飾ドメイン名が含まれています。状況ではここでSMTPクライアントシステムは、（例えば、そのアドレスが動的に割り当てられ、全く逆引きレコードが利用できない場合）、クライアントはリテラルアドレスを送るべきである意味のあるドメイン名を持っていません（セクション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は、EHLOコマンドを発行してSMTPセッションを開始する必要があります。 SMTPサーバがSMTPサービス拡張をサポートしている場合、それは成功したレスポンス、失敗応答、またはエラー応答が得られます。 SMTPサーバーは、この仕様に違反して、任意のSMTPサービス拡張をサポートしていない場合には、エラー応答を生成します。 （RFC 821で指定されるように）古いクライアントSMTPシステムは、上述したように、代わりにEHLOのHELOを使用することができ、サーバは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.
これらのコマンド、およびそれらの一つに「250 OK」応答は、SMTPクライアントとSMTPサーバーの両方が初期状態であることを確認、つまり、そこにはトランザクションが進行中でないと、すべての状態テーブルとバッファがクリアされます。
Syntax:
構文：
ehlo = "EHLO" SP Domain CRLF helo = "HELO" SP Domain CRLF
EHLO = "EHLO" SPドメイン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）と、すべてが、最後の行、およびコードと最後の行のためのスペースをハイフンに従ってください。肯定応答の構文は、ABNF記法と[8]の終端記号を使用して、次のとおりです。
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-OK-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
EHLO-挨拶= 1 *（％d0-9 /％d11-12 /％d14-127）。 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キーワード=（ALPHA / DIGIT）*（ALPHA / DIGIT / " - "）; EHLO-のparamsの追加構文が依存します。 EHLOキーワード
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。制御文字（US-ASCII 0〜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キーワードが上下、または混合場合に指定することができるが、それらは常に認識され、大文字と小文字を区別しない方法で処理されなければなりません。これは単に、RFC 821およびセクション2.4.1で指定されたプラクティスを拡張したものです。
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サーバーに配信されたメールトランザクションを開始するために使用されます。引数フィールドにはリバースパスが含まれており、オプションのパラメータが含まれていてもよいです。一般的には、MAILコマンドにはメールトランザクションが進行中でないときにのみ、セクション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を参照）が推奨されていません。返信メールのループ（例えば、メール配信と不達通知）を引き起こす可能性があるため、メッセージを報告するいくつかのタイプでは、逆パス（セクション3.7を参照）はnullであってもよいです。
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.
サービス拡張が交渉された場合は、MAILコマンドは、特定のサービス拡張に関連するパラメータを運ぶことができます。
Syntax:
構文：
"MAIL FROM:" ("<>" / Reverse-Path) [SP Mail-parameters] CRLF
"MAIL FROM："（ "<>" /パスリバース）[SPメールパラメータ] CRLF
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 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.
フォワードパスは、通常は、必要な送信先のメールボックスで構成されています。送信システムは、送信元経路として知られているホストのオプションのリストを生成してはなりません。受信システムは、ソースルートの構文を認識しなければならないが、ソースルートの指定を取り除き、元のルートが用意されていなかったかのようにメールボックスに関連付けられたドメイン名を利用すべきです。
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.
同様に、中継ホストは、ストリップまたはソースルートを無視し、名前はリバースパスにコピーしてはいけませんべきです。メールがその最終的な目的地を（フォワードパスだけ先のメールボックスが含まれている）に達すると、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>
<userx@y.foo.org> RCPT TO：<@ hosta.int、@ jkl.org：userc@d.bar.org> FROM MAIL
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>
<userx@y.foo.org> RCPT TO：<userc@d.bar.org> FROM MAIL
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>
<userx@y.foo.org> RCPT TO：<@ hosta.int、@ jkl.org：userc@d.bar.org> FROM MAIL
or to jkl.org, using the envelope commands
または封筒のコマンドを使用して、jkl.orgします
MAIL FROM:<userx@y.foo.org> RCPT TO:<@jkl.org:userc@d.bar.org>
<userx@y.foo.org> RCPT TO：<@ jkl.org:userc@d.bar.org> FROM MAIL
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").
ホストが全くメールを中継するために必要とされないので（これは、「ポリシーの理由」であるため）もちろん、xyz.comは、550のコードを使用して、RCPTコマンドを受信した全体メッセージをも拒絶することができます。
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
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.
受信機は、通常、DATAに354応答を送信し、送信元からのメールデータとしてコマンド次の行（<CRLF>配列で終わるストリング、セクション2.3.7に記載したように）を扱います。このコマンドは、メールデータは、メールデータバッファに追加されます。経験がSP、HT、CR、およびLF以外の制御文字の使用は問題を引き起こす可能性があり、可能な時に回避されるべきであることを示しているが、メールデータは、128 ASCII文字コードのいずれかが含まれていてもよいです。
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.
のみ<LF>で終わる受諾ラインの習慣は、いくつかのUNIXシステムの一部に不適合行動への譲歩として、それは解決よりも多くの相互運用性の問題を引き起こすことが証明されていて、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で議論するように、続いて診断されたエラーは、メールメッセージで報告されなければなりません。
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サーバが中継するか、最終的な送達のためのいずれかのメッセージを受け付けると、そのメールデータの先頭に（また、「タイムスタンプライン」または「受信」ラインと互換的に呼ばれる）トレースレコードを挿入します。このトレース・レコードは、メッセージ、メッセージを受信し（このタイムスタンプを挿入している）ホストのID、およびメッセージが受信された日付と時刻を送ったホストのIDを示します。中継されたメッセージは、複数のタイムスタンプ行を持っています。その構文を含め、これらの線の形成のための詳細については、セクション4.4で指定されています。
Additional discussion about the operation of the DATA command appears in section 3.3.
DATAコマンドの操作に関する追加の議論は、セクション3.3に表示されます。
Syntax: "DATA" CRLF
構文： "DATA" CRLF
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).
このコマンドは、現在のメールトランザクションが中止されることを指定します。任意の保存された送信者、受信者、およびメールデータを捨てなければなりませんし、すべてのバッファと状態テーブルはクリア。受信機は、引数なしでRSETコマンドに「250 OK」応答を送らなければなりません。リセットコマンドは、いつでもクライアントによって発行することができます。それはNOOPに効果的に等価である（すなわち、何の効果も持っていない場合）EHLOはセッションで発行される前に、エンドオブデータインジケータが送信され、肯定応答、又は直ちに終了する前にされた後に、EHLOの直後に発行された場合。 SMTPサーバーはRSETを受信した結果として、接続を閉じてはなりません。そのアクションは、（セクション4.1.1.10を参照）QUITのために予約されています。
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サーバーでは、この条件のために準備されるべきであるとの接続が消えた前にQUITを受信したかのように扱うべきです。
Syntax: "RSET" CRLF
構文： "RSET" CRLF
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
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
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サーバは、引数なしでHELPをサポートすべきであると引数でそれをサポートするかもしれません。
Syntax: "HELP" [ SP String ] CRLF
構文： "HELP" [SP文字列] CRLF
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回答を送ること以外に何のアクションを指定します。
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.
このコマンドはリバースパスバッファ、フォワードパスバッファ、またはメールデータバッファには影響しませんし、いつでも発行することができます。パラメータ文字列が指定されている場合、サーバはそれを無視すべきです。
Syntax: "NOOP" [ SP String ] CRLF
構文： "NOOP" [SP文字列] CRLF
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コマンドを送信するまで、意図的に伝送チャネルを閉じてはならないし、それが（前のコマンドにエラー応答があった場合でも）、応答を受信するまで待つ必要があります。接続が原因上記のシステムまたはネットワーク障害が発生した違反に途中で閉じている場合、サーバーは保留中のトランザクションを取り消す必要がありますが、進行中のコマンドまたはトランザクションが一時的に受け取っていたかのように行動しなければならない、一般的に、以前に完了したトランザクションを取り消し、そしてありませんエラー（すなわち、4yz応答）。
The QUIT command may be issued at any time.
QUITコマンドはいつでも発行することができます。
Syntax: "QUIT" CRLF
構文：CRLFを "QUIT"
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]適用可能な場合に指定された構文を使用して）の引数フィールドの構文は以下のとおりです。そのような「コア」構文で定義される通りであるALPHA、DIGIT、SP、CR、LF、CRLF、このドキュメントで定義されていない付録C.ターミナルに記載の下記の生産の一部のみソースルートに関連して使用されています[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) 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]
逆パス=パス往路=パスpath = "<" [A-D-L "："]メールボックス ">" A-D-L =でドメイン（* ""-D-L）。この形態は、いわゆる「送信元経路」ことに留意されたいです。 、受理されなければならない生成すべきではないとされるべきです。無視。アットドメイン= "@" ドメインのメールパラメータ= ESMTP-のparam *（SPのESMTP-PARAM）RCPTパラメータ= ESMTP-のparam *（SPのESMTP-PARAM）ESMTP-PARAM = ESMTPキーワード[ "=" ESMTP値] ESMTPキーワード=（ALPHA / DIGIT）*（ALPHA / DIGIT / " - "）ESMTP値= 1 *（％d33-60 /％d62-127）。 "="、SP、および制御文字キーワード= LDH-str引数=アトムドメイン=（サブドメイン1 *（ "" サブドメイン））/アドレスリテラルのサブドメインは=ましょう-掘るを除く任意のCHAR [LDH -str]
address-literal = "[" IPv4-address-literal / IPv6-address-literal / General-address-literal "]" ; See section 4.1.3
アドレスリテラル=「[」のIPv4アドレスリテラル/ IPv6のアドレスリテラル/汎用アドレスリテラル「]」。セクション4.1.3を参照してください。
Mailbox = Local-part "@" Domain
ドメイン「@」メールボックス=ローカルパート
Local-part = Dot-string / Quoted-string ; MAY be case-sensitive
ローカル・パート=ドット列/引用符で囲まれた文字列。大文字と小文字を区別してもよい（MAY）
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.
ローカル部分の上記定義は比較的寛容であるが、最大の相互運用性のため、メールを受信することを期待するホストは、ローカル部分が必要（または使用）メールボックス引用符で囲まれた文字列形式又はローカル部分がそうであるの定義は避けるべき感受性。発生またはローカル部分（例えば、特定のメールボックス名に）を比較が必要な目的のために、すべての引用された形態が同等に扱わなければならなくて、送信システムが可能クォート最小値を使用するフォームを送信しなければなりません。
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文字（いずれかに設定上位ビットを有するオクテット）またはASCII「制御文字」（10進値0-31、および127）のSMTPでの使用を要求するようなシステムは、そのような方法で、メールボックスを定義してはいけません。これらの文字は、MAILや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つの文字のユーザフィールドを示します。
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]のセクション2.3.1を参照）、アルファのセット以外の文字、数字、およびを促進するために、ハイフンは、SMTPクライアントまたはサーバのドメイン名ラベルに現れてはいけません。具体的には、アンダースコア文字は許可されていません。無効な文字コードが採用されており、そしてそのための拒絶のための他の理由が存在しないするコマンドを受け取るSMTPサーバーは、501応答でそのコマンドを拒絶しなければなりません。
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アドレスのため、この形式は、ドットで区切られた4つの小さな小数の整数を使用し、そのような配列のオクテット形で（IPv4）のインターネットアドレスを示している、[123.255.37.2]として括弧で囲ま。 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のアドレスリテラル= SNUM 3（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進整数を表します。 255までの範囲0の値がしてみましょう-DIG = ALPHA / DIGIT LDH-STR = *（ALPHA / DIGIT / " - "）してみましょう-DIG
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のフル/ IPv6の-COMP / IPv6v4フル/ IPv6v4-COMPのIPv6-ヘクス= 1 * 4HEXDIG IPv6のフル= IPv6にヘクス7（ "：" のIPv6-ヘクス）のIPv6-COMP = [IPv6のヘキサ* 5（ "：" のIPv6-ヘクス） "::" [IPv6のヘキサ* 5（ "：" のIPv6-ヘクス）]。 「::」のゼロの少なくとも2つの16ビットのグループを表します。これ以上に加えて、6つのグループよりも「::」であってもよいです。本IPv6v4フル= IPv6にヘクス5（ "：" のIPv6-ヘクス） "：" のIPv4アドレスリテラルIPv6v4-COMP = [IPv6にヘクス* 3（ "：" のIPv6-ヘクス） "::"
[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
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コマンドを使用して初期化しなければなりません。 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コマンドが発行されたかのように正確な状態をリセットします。言い換えれば、RSETの配列はEHLO直後は冗長が、不必要なコマンドを実行のパフォーマンスコスト以外で有害ではありません。
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個の故障応答が適切に戻されなければなりません。 SMTPサーバーは、EHLOを受信していた各これらの応答を送信した後、同じ状態にとどまらなければなりません。
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アドレスに対応することを確認することができます。ただし、サーバーは検証が失敗した場合にこのような理由のためのメッセージを受け入れることを拒否してはならない（MUST NOT）：検証の失敗に関する情報は、ロギングおよびトレースだけのためです。
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、HELP、EXPN、VRFY、およびRSETコマンドはセッション中の任意の時点で、または以前にセッションを初期化せずに使用することができます。 SMTPサーバにはEHLOコマンドがまだ受信されていない場合でも（つまり、503コードを返さない）、通常はこれらを処理しなければなりません。クライアントは、これらのコマンドを送信する前にEHLOでセッションを開いてください。
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の前またはアクセスの拒否は、クライアントのIPアドレス、または他の認証に基づいてされていない限り、EXPNコマンドに応答して、「あなたに拒否された550のアクセス」を示しRFC 821の例が正しくありませんまたは認可決定のメカニズム。
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.
MAILコマンド（または時代遅れのSEND、SOML、またはSAMLコマンド）はメールトランザクションを開始します。一度起動、メールトランザクションは、そのためには、コマンド、一つ以上のRCPTコマンド、およびDATAコマンドを開始するトランザクションで構成されています。メールトランザクションはRSET（または新しいEHLO）コマンドによって中止することができます。セッション中にゼロまたは複数のトランザクションがあるかもしれません。 MAIL（またはSEND、SOML、またはSAML）メールトランザクションが既に開いている場合は送ってはいけませんが、すなわち、メールトランザクションが前の1が正常に成功したと結論付けたセッションで開始していないか、またはされていた場合にのみ送信する必要がありますDATAコマンド、または以前の1はRSETで中止された場合。
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コマンドは、セッション内の他の時点で使用することはできませんが、何のセッション開放コマンドが送信されていないと受け入れられた場合でも、接続閉鎖を要求するために、クライアントのSMTPで使用されるべきです。
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サーバは「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の要求事項に従わなければなりません。
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つの応答を生成しなければなりません。
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で定義される）：正式に、応答は配列であると定義されます。以来、この仕様に違反して、テキストは時々、（または末尾のスペース文字なし）のみでコードを処理するために準備する必要があります受信しないクライアントは送信されません。のみEHLO、EXPN、およびHELPコマンドは通常の状況では複数行応答をもたらすことが期待されているが、複数行の応答は、任意のコマンドのために許可されています。
In ABNF, server responses are:
ABNFでは、サーバーの応答は以下のとおりです。
Greeting = "220 " Domain [ SP text ] CRLF Reply-line = Reply-code [ SP text ] CRLF
挨拶= "220" ドメイン[SPテキスト] CRLF返信ライン=返信コードを[SPテキスト] 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.
SMTPサーバーは、この文書に記載されている唯一の応答コードを送るべきです。 SMTPサーバーは、適切な時はいつでも例に示されているテキストを使用すべきです。
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.
SMTPクライアントは、（「住所変更」251及び551と、必要に応じて、220、221、及び421個の応答を除く）のみ応答コードによってではなく、テキストによってその作用を決定しなければなりません。一般的な場合には、まったくテキストを含まない任意のテキストは、（送信者が裸のコードを送るべきではありませんが）、許容可能でなければなりません。リプライコードに続くスペース（空白）が、テキストの一部とみなされます。可能な限り、受信側SMTPは、応答コードの最初の数字（重症度指標）をテストする必要があります。
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.
下の表示されたコードのリストは永久的なものと解釈してはなりません。新しいコードの添加が好ましい応答のテキスト部分の補足情報と、稀で有意な活性であるべきであるが、新しいコードは、新しい標準または標準トラック仕様の結果として添加してもよいです。このため、送信側SMTPは、この文書に指定されていないコードを処理するために準備しなければなりませんし、唯一の最初の数字を解釈することによって、そうしなければなりません。
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桁の数字は、それぞれ特別な意味を持っています。最初の数字は、応答が、良い悪いか、不完全であるかを示しています。素朴なSMTPクライアント、または予期しないコードを受信一つは、この最初の桁を調べることによって（計画通りなど、retrench、やり直し、進む）、その次のアクションを決定することができるであろう。エラーの種類が発生し、およそ何知りたいSMTPクライアントは、（例えば、メールシステムエラー、コマンド構文エラー）が二桁目を調べることができます。 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コマンドが受理された返信が、要求されたアクションは、停止状態のままで保持されている、この応答の情報の確認を保留。 SMTPクライアントは、アクションを続行するか中止するかどうかを指定する別のコマンドを送信する必要があります。注意：未伸長SMTPが応答のこのタイプを許可する任意のコマンドを持っていない、ので、続行するか中止するコマンドを持っていません。
2yz Positive Completion reply The requested action has been successfully completed. A new request may be initiated.
肯定完了2yz要求されたアクションが正常に完了した返信。新しい要求を開始することができます。
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陽性中間体は、コマンドが受け付けられた応答が、要求されたアクションは、さらに情報の受信を保留し、一時停止状態に保持されています。 SMTPクライアントは、この情報を指定して別のコマンドを送信する必要があります。この応答は、（すなわち、DATA IN）コマンドシーケンスグループで使用されています。
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 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.)
コマンドを返信4yz一時否定完了は受け入れられなかった、と要求されたアクションは発生しませんでした。しかし、エラー状態は一時的なものであり、アクションが再度要求することができます。送信者はコマンドシーケンス（もしあれば）の先頭に戻る必要があります。 2つの異なるサイト（receiver-と送信側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恒久的否定完了は、コマンドが受け入れられなかったと要求されたアクションが発生していない返事します。 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桁目で指定された各カテゴリにおける意味の細かいグラデーションを与えます。回答のリストは、このことを示しています。各応答テキストはなく、必須よりも推奨され、さらには、それが関連付けられているコマンドに応じて変更してもよいです。一方、応答コードは、厳密には、このセクションの仕様に従わなければなりません。受信機の実装は、ここで説明したものと多少異なる状況のために新しいコードを発明し、むしろ既に定義されたコードを適応させるべきではありません。
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.
たとえば、正常に実行さSMTPクライアントに新しい情報を提供しないNOOP、などのコマンドは、250応答を返します。コマンドが実装されていない非サイト固有のアクションを要求したときの応答が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>の直後。上述したように、サーバが送るべきである<SP>後続のテキストが送信されない場合、それは省略されるため、クライアントが準備しなければなりません。
For example:
例えば：
123-First line 123-Second line 123-234 text beginning with numbers 123 The last line
123から234テキストは番号123の最後の行で始まる行123-セカンドライン123-ファースト
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>が続くと、先行するすべての行を無視で始まる行を検索する必要があります。いくつかのケースでは、返事「テキスト」で、クライアントのための重要なデータがあります。クライアントは、現在のコンテキストからこれらのケースを識別することができるようになります。
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
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ヘルプメッセージ（受信機または特定の非標準コマンドの意味を使用する方法についての情報は、この応答は人間のユーザに便利です）
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 <ドメイン>サービス準備ができて221 <ドメイン>サービス終了の伝送路421 <ドメイン>サービスは利用できません、伝送チャネルを閉じる（サービスのシャットダウンが必要な場合、これは任意のコマンドへの応答でもよいです）
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要求されたメールアクション大丈夫、地元のない251ユーザーを完了しました。メールボックス使用できない（たとえば、メールボックスビジー）550要求されたアクション：252はできませんVRFYユーザーが、メッセージを受け入れ、配信を試みます（セクション3.5.3を参照してください）450要求されたメールアクション取られていない（3.4節を参照してください）<フォワードパス>に転送されます取られない：メールボックス使用できない（たとえば、メールボックスが見つからない、アクセス権なし、またはコマンド政策上の理由で拒否された）451要求されたアクションが中止：エラーをローカルではない551ユーザーの処理中に、試してみてください。<フォワードパス>は452要求されたアクションが取られていない（3.4節を参照してください）：552要求されたメールアクションは中止されまし不十分なシステムストレージ：553要求されたアクションが取られていないストレージの割り当てを超えて：メールボックス名が許可されていない（例えば、メールボックスの構文正しくない）354のスタートメール入力; <CRLF>。<CRLF> 554の取引で終わりではなかった（あるいは、接続-開く応答、「ここにはSMTPサービス」の場合）
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)
354 Start mail input; end with <CRLF>.<CRLF>
354開始メール入力; <CRLF>で終了する。<CRLF>
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 <ドメイン>サービスは、450要求されたメールアクションは取られない伝送チャネルを閉じる（サービスのシャットダウンが必要な場合、これは任意のコマンドへの応答でもよい）は利用できません：使用できないメールボックスを（例えば、メールボックスビジー）451要求されたアクションは中止：ローカルとらない処理452要求されたアクションでエラー：不十分なシステムストレージ500構文エラーが、認識されないコマンド実装されていないパラメータ又は引数502コマンド501構文エラー（これは、コマンドラインが長すぎるなどのエラーを含んでいてもよい）（セクション4.2.4を参照）503バート一連のコマンド504コマンドパラメータが実装されていない550要求されたアクション取られない：（政策上の理由で拒否された例えば、メールボックスが見つからない、アクセス権なし、またはコマンド）メールボックスが利用できないローカルではない551ユーザーを。 552要求されたメールアクションは中止され（セクション3.4を参照してください）<フォワードパス>試してみてください：許可されていないメールボックス名（たとえば、メールボックスの構文正しくない）554トランザクションは失敗した（あるいは、接続の場合：553要求されたアクションが取られていないストレージの割り当てを超えて）「ここにはSMTPサービス」、応答がありません - オープニング
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は、（コマンドが実装されていない）他のコードに優先して戻される必要があるときにとして提起されています。コマンドが実際にSMTPサーバによって認識が、実装されていない場合502を使用すべきです。コマンドが認識されない場合は、コード500が返されます。拡張SMTPシステムは、彼らが502（または500）の応答を返します。そのためEHLOに応答する機能をリストしてはなりません。
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>で終了した後、SMTPサーバが正完了ステータス（2yzコード）を返したときに<CRLF>、それはのために責任を負います。
- 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で指定されたメッセージを配信しようとする試みは、間隔をおいて倍のいくつかの合理的な数、再試行配信を過渡状態に起因する失敗した場合。
- 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メール・コマンド内のアドレスを使用して）元のメッセージの送信者に適切な通知を返す、過渡状態に起因する失敗した場合。
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).
SMTPサーバーは、永続的なエラー状態（5yz）コードを返した場合、DATAコマンドがで完了した後に、<CRLF>。<CRLF>、それはそのメッセージを届けるために、後続の試みをしてはなりません。 SMTPクライアントはそのメッセージの配信のための責任を保持し、それをユーザーに返すか、その後の試み（セクション4.5.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.
メッセージを発信したユーザは、永久的な障害が解釈されるのと同じように、不着指示として（メールメッセージまたはその他によって）一時的な障害の状態の復帰を解釈することができるべきです。クライアント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コマンドを用いて完全にした後、SMTPサーバが永久的なエラー状態（5yz）コードを返した場合、<CRLF>。<CRLF>、それはメッセージを配信する後続試行してはなりません。一時的なエラーステータスコードと同じように、SMTPクライアントは、メッセージの責任を保持しているが、再びユーザーレビューとメッセージの介入なしに同じサーバに配信を試みるべきではありません。
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.
一つの重要な回答は接続挨拶です。接続が完了すると、通常、受信機は220「Service ready」応答を送信します。送信者は任意のコマンドを送信する前に、このグリーティングメッセージを待つべき。
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を参照してください。
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
220 ISIF.USC.EDUサービス準備または220 mail.foo.com SuperSMTP V 6.1.2準備Serviceまたは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.
以下の表は、各コマンドの代替成功と失敗の応答を示しています。これらは厳密に付着されるべきである。受信機は返信にテキストを置換してもよいが、コード番号によって、特定のコマンド応答シーケンスにより暗示意味およびアクションを変更することはできません。
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.
各コマンドは、その通常の可能な応答で表示されます。可能な応答の前に使用プレフィックスは「I」成功のための中間のために、「S」、および「E」のエラーのためのものです。一部のサーバーは、特殊な状況下で、他の応答を生成することができ、そして将来の拡張を可能にするために、SMTPクライアントは、可能な場合は、返信の唯一の最初の数字を解釈すべきであり、唯一の最初の数字を解釈することによって認識されない応答コードに対処するために準備しなければなりません。ので、セクション2.2で説明したメカニズムを使用して拡張しない限り、SMTPサーバは、2〜5までの間の数字で始まらない3桁またはそれ以外のSMTPクライアントに応答コードを送信してはなりません。
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-アドバタイズ拡張機能の非存在下で供給される場合に将来の拡張を提供するために、引数（DATA、RSET、QUIT）を受け付けないように、この文書で指定されたコマンドは、501メッセージを返すべきです。
421 Service shutting down and closing transmission channel
421サービスがシャットダウンして伝送チャネルを閉じます
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：220 E：554 EHLOまたはHELO S：250 E：504、550 MAILのS：250 E：552、451、452、550、553、503 RCPT S：250、251（しかしの議論についてはセクション3.4を参照してください251および551）E：550、551、552、553、450、451、452、503、550 DATA I：354 - >データ - > 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
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.
- 、EHLOコマンドと、（2）アドレス、ソースのIPアドレスを含むリテラルで提示から決定されるようにSMTP環境で供給されなければならないからフィールドは、ソース・ホストの双方（1）名を含むべきですTCP接続。
- The ID field MAY contain an "@" as suggested in RFC 822, but this is not required.
- RFC 822で提案されているようIDフィールドには、「@」を含んでいてもよいが、これは必須ではありません。
- 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コマンドが与えられたとき、フィールドの<パス>エントリのリストを含むかもしれません。これは、いくつかのセキュリティ問題を提起し、通常は望ましくないこと。 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.
以前にメッセージヘッダに追加された行：インターネットメールプログラムは、受信を変更しないでください。 SMTPサーバーは、メッセージに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.
インターネットが成長するにつれて、受信フィールドの比較は、特に低速リレーの問題を検出するために重要です。受信したフィールドを作成するSMTPサーバではなく、あらゆるタイプのタイムゾーン名よりも、日付（例えば、-0800）に明示的なオフセットを使用すべきです。 （オフセット付き）現地時間は、可能な場合UTに好ましいです。この製剤は、現地の状況についてわずかにより多くの情報を指定することを可能にします。 UTが必要な場合、受信機は、単に値を変換するためにいくつかの簡単な計算を行う必要が。 UTの使用は、サーバーのタイムゾーンの位置に関する情報を失います。それはタイムゾーン名を供給することが望まれるならば、それはコメントに含まれるべきです。
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サーバがメッセージの「最終配信」を作る際には、メールデータの先頭にリターンパス行を挿入します。リターンパスのこの使用が必要です。メールシステムはそれをサポートしなければなりません。リターンパスラインは、MAILコマンドから<逆経路>の情報を保存します。ここでは、最終的な配信は、メッセージが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].
テキストは、上記の最後のメールデータが一つ以上のタイムスタンプ行が続き、リターンパスラインで始まることを意味します。これらの線は、[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, 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.
SMTPサーバが転送またはメッセージが配信のために受理された後に他の動作が発生する可能性があるので、それは最終的な配信を行っているか否かを判断することが困難な場合があります。従って、更なる（転送、ゲートウェイ、または中継）システムは、リターンパスを削除し、正確に一つのそのような行が配信されたメッセージに表示されていることを保証するために、必要に応じてメールコマンドを再構築してもよい（MAY）。
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.
メッセージ発信SMTPシステムが既にリターンパスヘッダを含むメッセージを送るべきではありません。中継機能を実行するSMTPサーバーは、リターンパスヘッダが存在するかどうかを決定するのに必要な程度に、メッセージデータを検査し、そして特にないてはいけません。最終的な配送を行うSMTPサーバーでは、独自に追加する前に、リターンパスヘッダを削除することができます。
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.
リターンパスの主な目的は、非送達または他のメールシステム障害を示すメッセージが送信されるべきアドレスを指定することです。これは明白であるためにメッセージが配信されたときに、正確に1つの戻り経路が存在しなければなりません。非SMTPトランスポートとRFC 822の構文を使用して、システムがエラーレポート（例えば、配信不能メッセージ）が送信されなければならないため、トランスポート・エンベロープ、関連付けられた一義的なアドレスを指定すべきです。
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.
ヒストリカルノート：RFC 822でのテキストのエラー・メッセージの宛先としてリターンパスヘッダの使用（または封筒MAILコマンドからパスアドレスを逆に）矛盾するように見える、インターネット上では適用されません。逆の経路アドレス（リターンパスにコピーされるように）配信エラーメッセージを含むすべてのメールの標的として使用されなければなりません。
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-からゲートウェイ>は、リターンパスヘッダを挿入する必要があります。
- 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.
- elsewhere-からゲートウェイ> SMTPがメッセージ中に存在する任意のリターンパスヘッダを削除し、いずれかのSMTPエンベロープにその情報をコピーしたり、逆パス引数を構築するために他の輸送システムのエンベロープ内に存在する情報とを組み合わせるべきですSMTPエンベロープ内MAILコマンド。
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サーバーが構成し、メッセージの発信元に「配信不能メール」の通知メッセージを送らなければなりません。
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.
失敗した受信者または別の通知メッセージのすべてをリスト単一の通知が失敗した各受信者のために送らなければなりません。送信者による処理の経済については、前者が可能な場合に好適です。すべての配信不能メール通知メッセージは、MAILコマンドを使用して送信される（これらは、SOMLを廃止SEND処理から生じる場合であっても、または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.
From-domain = "FROM" FWS Extended-Domain CFWS
ドメイン= FWS拡張ドメインCFWS「FROM」
By-domain = "BY" FWS Extended-Domain CFWS
バイ・ドメイン= FWS拡張ドメインCFWS「BY」
Extended-Domain = Domain / ( Domain FWS "(" TCP-info ")" ) / ( Address-literal FWS "(" TCP-info ")" )
拡張ドメイン=ドメイン/（ドメインFWS "（" TCP-情報 "）"）/（住所リテラルFWS "（" TCP-情報 "）"）
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]
オプト情報= [経由] [付] [ID] [用]
Via = "VIA" FWS Link CFWS
暴力= "VIOLENCE" ライトリンクSFOS
With = "WITH" FWS Protocol CFWS
FWSプロトコルCFWS "WITH" =付き
ID = "ID" FWS String / msg-id CFWS
ID = "ID" FWS文字列/ MSG-ID CFWS
For = "FOR" FWS 1*( Path / Mailbox ) CFWS
フォート= "FOUR" LIGHT 1 *（ラパス/ Mailvox）SFOS
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
=アトムリンク=「TCP」/ AddtlリンクAddtlリンク。リンクのための追加の標準名が登録されています。 IANA（Internet Assigned Numbers Authority）に。 「経由」です。主に非インターネットトランスポートと値の。 SMTP
; 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.
;サーバーは、未登録の名前を使用しないでください。プロトコル= "ESMTP" / "SMTP" / Attdl-プロトコルAttdl-プロトコル=原子でありますプロトコルのための追加の標準名が登録されています。 IANA（Internet Assigned Numbers Authority）に。 SMTPサーバ。未登録の名前を使用しないでください。
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 MAIL RCPT、DATA 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サーバを含む任意のシステムでは、大文字と小文字を区別しないローカル名として予約メールボックス「ポストマスター」をサポートしなければなりません。 （セクション3.1で説明したように）サーバは常に接続口に554を返す場合、このポストマスタアドレスは厳密には必要ではありません。ドメインのない（：ポストマスターのメールを受け入れるための要件は、RCPTがSMTPサーバがメールサービスだけでなく、「<ポストマスター> RCPT TO」の特殊なケースを提供するためにドメインのいずれかでポストマスターのメールボックスを指定するコマンドことを意味します仕様では）、サポートしなければなりません。
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システムは、インターネット上の他のシステムからポストマスターに向けメールを受け入れるためにあらゆる合理的な努力をすることが期待されています。極端な例では、サービスの攻撃やポストマスターに向けたメールをブロックすることがありsecurity-- SMTPサーバの他の違反の拒否を含むよう--such。このような攻撃の一部ではないメッセージをブロックしないように、しかし、そのような構成は狭く合わせて調整する必要があります。
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 allow all user composed text to be transmitted transparently, the following procedures are used:
データの透明性のためのいくつかの規定がなければ、文字列「<CRLF>。<CRLF>」メールテキストを終了し、ユーザーが送信することはできません。一般的には、ユーザーは、「禁止」配列を認識していません。すべてのユーザーで構成されるテキストは透過的に伝送することができるようにするには、以下の手順が使用されます。
- 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とは異なる文字セットを使用するホストのために必要があるかもしれません。このような変換が必要な場合は、それらが中継されるメールに適用されている場合は特に、彼らは、可逆的でなければなりません。
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.
最小/最大サイズを必要としているいくつかのオブジェクトがあります。すべての実装は、少なくともこれらのサイズのオブジェクトを受け取ることができなければなりません。可能な場合、これらのサイズは避けるべきよりも大きなオブジェクト。しかし、このような符号化されたX.400アドレスなど、いくつかのインターネットメール構造物[16]は、多くの場合、より大きなオブジェクトが必要になります：クライアントは、これらを送信しようとするかもしれないが、彼らはそれが扱うことができない場合は、それらを拒否するようにサーバーのために準備しなければなりません。可能な限り、これらのオブジェクトの長さに制限を課していない実装技術が使用されるべきです。
local-part The maximum total length of a user name or other local-part is 64 characters.
ローカル部分は、ユーザ名または他のローカル部分の最大合計長さは64個の文字です。
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サービス拡張を使用することにより増加させることができます。
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]ので、メッセージは、インターネット上で長劇的に成長している、とメッセージサイズの制限は、すべての可能であれば避けるべきです。制限を課す必要がありますSMTPサーバシステムは、「SIZE」サービス拡張[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 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の未満のRCPTコマンドで（過剰な受信者のための）メッセージの拒否は、本明細書の違反です。 SMTPサーバを中継している一般的な原理はならず、ヘッダフィールドに示されている受信者の合計数に基づいてメッセージを拒否することは推奨されるべきであることを示唆している配信SMTPサーバーは、メッセージヘッダの検証テストを実行しないでください。サイレントアドレスが以前に受け入れられた廃棄するのではなく、その制限を超えて追加のアドレスを拒否するような受信者の数に制限を課すサーバは、規則的に動作しなければなりません。サーバは、単一のメッセージで100人の以上の受信者を受け入れることを拒否した場合、100以上のRCPTコマンドを含むメッセージを配信する必要があるクライアントは、100-受信者「チャンク」に送信するために準備する必要があります。
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行が長すぎます。または501パスが長すぎるか、452人の受信者が多すぎます（下記参照）または552のが多すぎるメールデータ。
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.
RFC 821 [30]が誤って応答コード552を有するものとしてSMTPサーバーがRCPTコマンド（「あまりにも多くの受信者」）の数に実装限界を排出エラーを列挙し、この条件に対する正しい応答コードは、452クライアントで扱うべきです一時的ではなく、永久的な障害として、この場合の552コード作品以下ロジックので。
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コマンドがあります。サーバーがメッセージを受け入れることができる場合には、少なくともこれらの100のアドレスは、SMTPクライアントのキューから削除されます。クライアントは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の応答コードを使用しなければならない（ただし、上記のように、クライアントはまた、552のために準備されるべきです）。サーバがRCPTコマンドの数で構成されたサイトポリシーの制限がある場合、それは代わりに5XX応答コードを使用するかもしれません。ポリシーの制限は、特定のメッセージ本文の総受信者数は、そのメッセージ本体が複数のメールトランザクションで送信された場合でも、強制された場合に適用することを意図していた場合、これは最も適切であろう。
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 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クライアントはタイムアウトメカニズムを提供しなければなりません。それは何らかの形で全体のメールトランザクションを時間を計るしようとするのではなく、コマンド毎のタイムアウトを使用しなければなりません。タイムアウトは、好ましくは、SMTPコードを再コンパイルすることなく、容易に再構成可能であるべきです。これを実装するために、タイマーは、各SMTPコマンドに対して、データ転送の各バッファのために設定されています。後者は、全体的なタイムアウトがメッセージのサイズに本質的に比例することを意味します。
Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows:
多忙なメール中継ホストと豊富な経験に基づき、次のように最低限のコマンドごとのタイムアウト値は次のようになります。
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分SMTPクライアントプロセスが失敗したTCP接続と初期の220グリーティングメッセージを受信する際の遅延を区別する必要があります。多くのSMTPサーバーはTCP接続を受け入れるが、そのシステムの負荷を処理する複数のメールを許可するまで220メッセージの配信を遅らせます。
MAIL Command: 5 minutes
MAILコマンド：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分長いタイムアウトが必要です。
DATA Initiation: 2 minutes This is while awaiting the "354 Start Input" reply to a DATA command.
DATA開始：DATAコマンドに対する「354 Start Input」応答を待つ間これは2分。
Data Block: 3 minutes This is while awaiting the completion of each TCP SEND call transmitting a chunk of data.
データブロック：データのチャンクを送信する各TCP SEND呼び出しの完了を待つ間、3分です。
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分。 「250 OK」応答を待つ間です。受信機は、メッセージデータを終端の最終期間を取得すると、それは、典型的には、ユーザのメールボックスにメッセージを配信する処理を行います。この時点でスプリアスタイムアウトは非常に無駄だろうし、それが正常に送信された、サーバーが配信のための責任を受け入れているので、一般的に、メッセージの複数のコピーの配信につながります。追加の議論については6.1節を参照してください。
An SMTP server SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender.
それは、送信者からの次のコマンドを待っている間にSMTPサーバーは、少なくとも5分のタイムアウトを持つべきである（SHOULD）。
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 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.
ホストSMTP実装の一般的な構造は、メールを送受信するためのユーザのメールボックス、輸送中にメッセージをキューイングするための1つの以上の領域、および1つまたは複数のデーモンプロセスを含みます。正確な構造は、ホストとホストでサポートされているメーリングリストの数とサイズ上のユーザーのニーズに応じて異なります。私たちは、特に高いトラフィックレベルをサポートするメーラーのために、役立つことが証明されているいくつかの最適化について説明します。
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.
任意のキューイング方式は、コマンドごとにすべての活動にタイムアウトを含まなければなりません。キューイング方式は、どのような状況下で、エラーメッセージへの応答にエラーメッセージを送ってはいけません。
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.
一つの試みが失敗した後、送信者は、再試行に特定の宛先を遅らせなければなりません。一般に、再試行間隔は少なくとも30分であるべきです。 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.
クライアントは、単に再試行は、メールアイテムをキューに入れられたのではなく、それは到達できないホストと対応する接続タイムアウトのリストを維持する必要があります。
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時間バックオフ。
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.
戦略は、さらに、リソース使用量対配達時間を最適化するために（下記参照）ホストごとに複数のアドレスの結果として変更されてもよいです。
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分のタイムアウト後に失敗したと判断できることに注意してください同じホストへのメッセージ。
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クライアントはサーバからの負の応答をキャッシュに細心の注意を使用すべきです。 EHLOが同じSMTP接続中に複数回発行された場合、極端な場合には、別の答えは、サーバーによって返されることがあります。もっと重要なのは、MAILコマンドへの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.
メールメッセージが複数の受信者に配信され、メッセージのコピーが送信される先のSMTPサーバが複数の受信者に対して同じである場合、そのメッセージの唯一のコピーが送信されなければなりません。つまり、SMTPクライアントがコマンドシーケンスを使用する必要があります。MAIL、RCPT、RCPT、... RCPT、DATAの代わりに一連の：MAIL、RCPT、DATA、...、MAIL、RCPT、DATA。非常に多くのアドレスがある場合は、MAILコマンドごとの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クライアントは複数の同時送信メールトランザクションをサポートするかもしれません。しかし、いくつかの制限がメールに、すべてのリソースを注いでからホストを保護するために適切かもしれません。
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.
SMTPサーバーは、常にSMTPポートをリッスン保留中を維持しようとすべきです。これは、SMTPのために複数の着信TCP接続のサポートを必要とします。いくつかの制限が課されますが、一度に複数の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キューイングメカニズムを活性化できます。
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で議論するようにヌル逆経路で送信される既存の及び提案された規格、すなわち非配信通知によって要求される通知メッセージのいくつかの種類があり、
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.)
また、配信状態通知（DSN）[24]、およびメッセージ気質通知（開封通知）の他の種類[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によって必要とされない任意のメッセージ）が有効、非ヌル逆経路とを用いて送信されるべきです。
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.
自動化された電子メールプロセッサの実装者は、特定のそのようなシステムがnullのリバースパスでメッセージに返信すべきではないでヌルリバースパスでメッセージの様々な種類が、正しく処理されていることを確認するために注意しなければなりません。
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に記載されているように）メール処理のために送達するためのドメインを特定したら、DNSルックアップは、ドメイン名[22]を解決するために行われなければなりません。名前は、完全修飾ドメイン名（FQDN）であることが期待される：起因する問題の履歴を、外部本明細書のある部分名前またはローカルエイリアスからのFQDNを推測するためのメカニズムと、一般的に推奨されています。ルックアップは最初の名前に関連付けられたMXレコードを検索しようとします。 CNAMEレコードが代わりに発見された場合、それは最初の名前であるかのように、結果の名前が処理されます。 MXレコードが見つからないが、A RRが見つかった場合、それがそのホストを指し、0の嗜好と、暗黙的なMX RRと関連していたかのように、A RRが処理されます。一つ以上のMXのRRが与えられた名前のために発見された場合、それらはMX RRを使用して配置されていない限り、SMTPシステムは、その名前に関連付けられた任意のA RRを利用してはいけません。 「暗黙の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クライアントは、少なくとも2つのアドレスを試してみてください。
Two types of information is used to rank the host addresses: multiple MX records, and multihomed hosts.
複数の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は、特定のために複数のメール交換機に負荷を分散するためにそれらをランダム化しなければなりません会社。
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は提示された順序でそれらを試みなければなりません。
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サーバは、指定されたメール交換器でいる宛先のメッセージを受信した場合、それは、（潜在的にアドレスにRCPTから、および/またはMAILを書き換えた後）メッセージを中継することができる、メッセージの最終的な配信を行うこと、またはそれを手SMTP-設けられた搬送環境の外にいくつかのメカニズムを使用してオフにします。もちろん、後者のどちらも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レコードをソートしなければなりません。最も低い番号のレコードが最も好ましいレコードは最初に、優先順に並べられています。リレーホストは、それがメール取引で知られるかもしれないことにより、名前や住所のいずれかのためのリストを検査しなければなりません。一致するレコードが見つかった場合、その優先度と高い番号のもので、すべてのレコードが考慮から捨てなければなりません。その時点で残ってレコードがない場合は、エラー状態である、とのメッセージが配信不能として返されなければなりません。記録が残っているならば、上記のように、彼らは、最高の好みまず、試行すべきです。
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は（データに応答して「250 OK」メッセージを送信することによって）郵便物を受け付けたとき、それはメッセージを配信又は中継する責任を受け入れています。それは真剣にこの責任を取る必要があります。それは、そのようなホストは、後にクラッシュしたりので、予測可能な資源不足のためとして軽薄な理由でメッセージを失ってはなりません。
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は、策定し、通知メッセージを郵送しなければなりません。この通知は、エンベロープにヌル（「<>」）逆の経路を使用して送信されなければなりません。この通知の受信者は、エンベロープリターンパス（：ラインまたはリターンパス）からのアドレスであるに違いありません。このアドレスがnullである場合は、（「<>」）、受信側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 MAIL：<@ A、B @：ユーザー@ dを>
The notification message MUST be sent using:
通知メッセージを使用させなければなりません。
RCPT TO:<user@d>
RCPT TO：<ユーザー@ dを>
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.
タイムアウトの結果として、重複メッセージを受信しないようにするには、受信側SMTPは、データ・インジケータの最後の<CRLF>。<CRLF>端に応答するために必要な時間を最小限にするために求めなければなりません。この問題の議論のための[28] RFC 1047を参照してください。
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.
単純な数のカウント「受付：」メッセージのヘッダーは、メールシステム内のループを検出するのに有効な、まれに最適であるが、この方法であることが証明されました。この技術を使用してSMTPサーバーには、通常、少なくとも100個の受信エントリを大拒否のしきい値を使用すべきです。どのようなメカニズムが使用されている、サーバーは、些細なループを検出して停止するための規定を含まなければなりません。
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の使用を奨励してきました。歴史的に、これらのクライアントの多くのマシンは（[7]メールフォーマットプロトコルによって、実際と）SMTPが想定メカニズムと情報の一部を欠いていました。いくつかは、時間の十分な経過を追うことができませんでした。他の人は、タイムゾーンの概念がありませんでした。まだ他の人は、自分の名前や住所を特定することができませんでした。そして、もちろん、どれも認証されたアドレスのRFC 822の概念を根底に仮定を満たすことができませんでした。
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サーバーによって適用される修正に関するせいぜい大きな懸念があります。
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サーバ、または1つによって処理されるメッセージに以下の変更が適用されてもよいです。
- Addition of a message-id field when none appears
- メッセージIDフィールドの追加どれが表示されません
- 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.
全ての場合において、正しい情報を提供適切に動作するクライアントは、SMTPサーバによって補正に好適です。すべての場合において、アクションのドキュメントが強く推奨される（トレースフィールドおよび/またはヘッダのコメントで）サーバによって実行されます。
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サーバへ）で認証を提供するコンフィグレーションオプション。彼らは慎重に設計された信頼環境における責任の慎重なハンドオフを伴っている場合を除きしかし、彼らはデジタル署名されたメッセージを使用して、エンドツーエンドのメカニズムではなくより輸送システムの整合性に応じて、本質的に弱いまま。
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.)
自分自身以外の有効なアドレスを指すように、フィールド「から」ユーザーが封筒のリターンパスとヘッダーを設定することがより困難にする努力は大部分が誤っている：彼らは、メールが別のまたは内に代わって一人のユーザーによって送信された正当なアプリケーションをくじきますどのエラー（または正常）応答特別なアドレスに送られるべきです。 （ユーザーがメッセージごとに、これらのフィールドを変更するための便利な方法を提供するシステムは、メッセージデータ内の送信者フィールドが賢明生成することができるように、ユーザーのプライマリおよび永久的なメールボックスアドレスを確立することを試みる必要があります。）
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に関連した認証の問題に対処していません。
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.
メッセージヘッダに表示されていないアドレスがいくつかの理由のためにSMTPサーバーへのRCPTコマンドで表示されることがあります。二つの最も一般的なのは（複数のアドレスに解決単一のアドレス）「リストエクスプローダ」と「ブラインドコピー」の外観として、メールアドレスの使用を含みます。特に、複数のRCPTコマンドが存在し、これらのメカニズムの目的の一部を破っ避けるために、SMTPクライアントとサーバは、いずれかのトレースヘッダの一部として、またはとして、ヘッダにRCPTコマンドの引数のフルセットをコピーすべきではありませんとき情報提供や民間の拡張ヘッダー。このルールは、多くの場合、実際には破られ、それが役に立つだけで、単一のRCPTコマンドを含む別のメッセージトランザクションとして各ブラインドコピーを送信するかもしれない「BCC」の使用を認識しているSMTPシステムを送信、強制することはできませんので。
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.
「リバース」（などMAIL、SAML、から、コマンド）または「フォワード」（RCPT）SMTPトランザクション（「エンベロープ」）のアドレスとヘッダ内のアドレスのいずれかとの間には固有の関係はありません。システムを受信すると、そのような関係を推定し、配信のためにメッセージのヘッダを変更するためにそれらを使用することを試みるべきではありません。人気の「どうやら-に」ヘッダはこの原則の違反だけでなく、意図しない情報開示の一般的な原因であるため、使用しないでください。
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 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.
セクション3.5で説明したように、個々のサイトでは、セキュリティ上の理由でVRFYまたはEXPNのいずれかまたは両方を無効にすることができます。上記の当然の結果として、これを許可する実装が確認され、実際には、ないアドレスを確認しているように見えてはなりません。サイトはセキュリティ上の理由から、これらのコマンドを無効にした場合は、SMTPサーバーではなく、成功または失敗した検証と混同される可能性がコードよりも、252応答を返さなければなりません。
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応答コードを返すことは、この規則に違反します。もちろん、常にアドレスが有効であるか否かが550を返すことによってVRFYを「サポート」という実装が適合しても同様ではありません。
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に「収穫」のアドレスの使用が増加しています。実装はまだEXPNのサポートを提供する必要がありますが、サイトは慎重にトレードオフを評価する必要があります。認証メカニズムは、SMTPに導入されたように、いくつかのサイトでは唯一、認証要求者へのEXPNを利用可能にすることもできます。
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サーバーを保護ではなく、サーバの正確な身元を隠すことで、既知の脆弱性を隠蔽しようとしていることは多くの保護を提供することを願っていますし、はるかに良いであることを指摘しています。サイトは念頭に置いてその問題とのトレードオフを評価することをお勧めします。実装は強く最小限に他のネットワークホストに何らかの方法で種類とバージョン情報を利用可能にするために提供することが奨励されています。
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句は全く注意して供給したりする必要があります。
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応答コードの使用は、誤っ機密情報を開示することができます。これらの問題を懸念しているサイトでは、彼らが選択していることを確認し、適切なサーバを設定する必要があります。
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.
近年では、任意のサイトを通じてリレー機能を使用すると、メールの実際の起源を隠すために敵対的な取り組みの一環として使用されています。いくつかのサイトは、既知の又は識別可能なソースへの中継機能の使用を制限することを決定しており、実装は、この種のフィルタリングを実行する能力を提供すべきです。メールがこれら又は他のポリシー上の理由で拒否された場合、550コードが適宜EHLO、MAIL、またはRCPTに応じて使用されるべきです。
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つのレジストリを維持します。最初は、SMTPサービスに関連するキーワードでの拡張、および、必要に応じて、パラメータや動詞などで構成されています。セクション2.2.2で指定されているように、エントリは「X」で始まり、このレジストリに行われないことがあります。エントリーは特にこの目的のためにIESGによって承認された標準化過程または実験のRFCで定義されているサービス拡張（および関連するキーワード、パラメータ、または動詞）のために行うことができます。
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.
第二のレジストリは、（RFC 821にこの文書で指定された）のIPv4アドレス（この文書で指定された）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") 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 821によって確立され、本明細書によって更新（「ヘッダを受信された」）タイムスタンプの節「と」「を介して」と一緒に使用するリンクおよびプロトコル識別子のレジストリです。この文書で指定されたものに加えて、リンクとプロトコル識別子は、唯一の標準化によって、またはRFC-文書化、IESGが承認し、実験プロトコル拡張の方法によって登録することができます。
[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]米国規格協会（アメリカ規格協会の旧米国）、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.、 "インターネットホストのための要件 - アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[3] Butler, M., Chase, D., Goldberger, J., Postel, J. and J. Reynolds, "Post Office Protocol - version 2", RFC 937, February 1985.
[3]バトラー、M.、チェイス、D.、ゴールドバーガー、J.、ポステル、J.、およびJ.レイノルズ、 "ポストオフィスプロトコル - バージョン2"、RFC 937、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のメッセージフォーマット"、RFC 2440、1998年11月。
[5] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC 1176, August 1990.
[5]クリスピン、M.、 "インタラクティブメールアクセスプロトコル - バージョン2"、RFC 1176、1990年8月。
[6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC 2060, December 1996.
[6]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4"、RFC 2060、1996年12月。
[7] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982.
[7]クロッカー、D.、RFC 822、1982年8月 "標準アルパインターネットテキストメッセージの形式について"。
[8] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[8]クロッカー、D.、およびP. Overell、編、 "構文仕様のための増大しているBNF：ABNF"。、RFC 2234、1997年11月。
[9] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996.
[9]デ・冬、J.、 "リモートメッセージキューの開始のためのSMTPサービス拡張"、RFC 1985、1996年8月。
[10] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[10] Fajman、R.、RFC 2298、1998年3月の "メッセージ処分通知のための広げることができるメッセージフォーマット"。
[11] Freed, N, "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
"インターネットファイアウォールのための行動と要件" [11]フリード、N、RFC 2979、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）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年12月。
[13] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2920, September 2000.
[13]フリード、N.、 "コマンドパイプラインのためのSMTPサービス拡張"、RFC 2920、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マルチパートのセキュリティ：マルチパート/署名およびマルチパート/暗号化"、RFC 1847、1995年10月。
[15] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[15] Gellens、R.及びJ. Klensin、 "メッセージ送信"、RFC 2476、1998年12月。
[16] Kille, S., "Mapping between X.400 and RFC822/MIME", RFC 2156, January 1998.
[16] Kille、S.、RFC 2156 "X.400とRFC822 / MIMEの間のマッピング"、1998年1月。
[17] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[17] HindenとRとS.デアリング、編。 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[18] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995.
[18] Klensin、J.、フリード、N.およびK.ムーア、 "SMTPサービス拡張メッセージのサイズ宣言"、STD 10、RFC 1870、1995年11月。
[19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[19] Klensin、J.、フリード、N.、ローズ、M.、Stefferud、E.およびD.クロッカー、 "SMTPサービス拡張"、STD 10、RFC 1869、1995年11月。
[20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[20] Klensin、J.、フリード、N.、ローズ、M.、Stefferud、E.およびD.クロッカー、 "8ビット・MIMEtransportためのSMTPサービス拡張"、RFC 1652、1994年7月。
[21] Lambert, M., "PCMAIL: A distributed mail system for personal computers", RFC 1056, July 1988.
[21]ランバート、M.、 "PCMAIL：パソコン用分散型メールシステム"、RFC 1056、1988年7月。
[22] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[22] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, December 1996.
[23]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、1996年12月。
[24] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
[24]ムーア、K.、 "配送状態通知のためのSMTPサービス拡張"、RFC 1891、1996年1月。
[25] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.
[25]ムーア、K.、およびG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、RFC 1894、1996年1月。
[26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[26]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月。
[27] Partridge, C., "Mail routing and the domain system", RFC 974, January 1986.
ヤマウズラ、C.、 "メール・ルーティングとドメインシステム"、RFC 974、1986年1月[27]。
[28] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February 1988.
ヤマウズラ、C.、 "重複メッセージやSMTP"、RFC 1047、1988年2月[28]。
[29] Postel, J., ed., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, September 1981.
[29]ポステル、J.、編、 "伝送制御プロトコル - DARPAインターネットプログラムプロトコル仕様"。、STD 7、RFC 793、1981年9月。
[30] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 1982.
[30]ポステル、J.、 "簡易メール転送プロトコル"、RFC 821、1982年8月。
[31] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[31] Ramsdell、B.、エド。、 "S / MIMEバージョン3メッセージ仕様"、RFC 2633、1999年6月。
[32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[32]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[33] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August 1995.
[33]ヴォードルイユ、G.、RFC 1830、1995年8月 "大規模およびバイナリMIMEメッセージの送信のためのSMTPサービス拡張"。
[34] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[34]ヴォードルイユ、G.、 "強化されたメールシステムステータスコード"、RFC 1893、1996年1月。
John C. Klensin AT&T Laboratories 99 Bedford St Boston, MA 02111 USA
ジョンC. Klensin AT＆T研究所99ベッドフォードセントボストン、MA 02111 USA
Phone: 617-574-3076 EMail: klensin@research.att.com
電話：617-574-3076 Eメール：klensin@research.att.com
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ワーキンググループでの幅広い議論がありました、そのメーリングリスト上やディスカッション、についての多くの技術的な問題やインターネットメール輸送のための改訂基準の役割、および多くの貢献を対面での両方が、この中に文言を形成する助け仕様。 RFC 821から生産された多くの議論への参加者数百人は枚挙にいとまがないが、それらはすべて、この文書は、それが何であるかになって助けました。
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ビット・バイトとして送信されます。サービスの拡張機能は、メッセージ本文の一部としてではなく、SMTPコマンドや応答で完全な8ビット・データ・バイトの伝送を可能にするために、このルールを変更することができます。
B. Generating SMTP Commands from Headers
B.ヘッダから生成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).
いくつかのシステムは、メール送信プロトコルでRFC 822ヘッダー（のみ）を使用する、またはそうでなければそのようなメッセージがUAからMTAに渡されたときにRFC 822ヘッダからSMTPコマンドを生成します。 MTA-UAのプロトコルは、個人的な問題ですが、任意のインターネット標準でカバーされていない、このアプローチには問題があります。たとえば、概念的メール封筒に属する情報は、ヘッダ情報から処理の初期分離（及び別保持）されていない「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コマンドを生成する必要があります。
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ヘッダフィールドからの各受信者のアドレスは、RCPTコマンドにコピーする必要があり（それがキューイングまたは送達のために必要とされる場合は、複数のメッセージのコピーを生成します）。これは、RFC 822「グループ」に記載されている任意のアドレスが含まれます。どれBCCフィールドは、ヘッダから削除する必要があります。このプロセスが完了すると、残りのヘッダは、少なくとも一つは、CC：、又はBccの：をすることを確認するためにチェックすべきである：ヘッダが残ります。いずれも行わない場合、BCC：[32]で指定されない付加的な情報を持つヘッダが挿入されます。
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. MAILコマンド内のリターン・アドレスは、可能な場合、提出（ローカル）ユーザのシステムのアイデンティティに由来すべきであり、「から：」ヘッダフィールドさもなければ。利用可能なシステムのアイデンティティが存在する場合、それはからヘッダフィールド内のアドレスと異なる場合、それはまた、送信者ヘッダフィールドにコピーする必要があります。システムズ（すでにそこに削除する必要がありました。どれSenderフィールド）は、提出者は、封筒のリターンアドレスを上書きするための方法を提供することができるが、特権ユーザーにその使用を制限することができます。これは、メールの偽造を防ぐことはできませんが、その発生率を減少させること;セクション7.1を参照してください。
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.
822情報のみ標準RFCに基づいて提出プロトコルはSMTP環境への外来（非SMTP）メールシステムからのメッセージをゲートウェイするために使用してはいけません。エンベロープを構築するための追加情報が補足ヘッダや外部システムのエンベロープかどうか、他の環境では、いくつかのソースから来なければなりません。
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.
試みは、「へ」のみ彼らのヘッダを使用してメッセージをゲートウェイにし、「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.
歴史的には、<逆パス>ホストの逆ソースルーティングリストと元のメールボックスでした。 <逆経路>の最初のホストは、MAILコマンドを送信するホストであるべきです。同様に、<フォワードパス>ホストのリストをルーティングする送信元と宛先のメールボックスであってもよいです。しかし、一般的に、<フォワードパス>必要に応じて、ルーティング情報を供給するためにドメイン・ネーム・システムに依存する、唯一のメールボックスおよびドメイン名を含める必要があります。ソースルートの使用が推奨されていません。セクション3.3とF.2で議論したように、サーバが受信して、それらを処理するために準備しなければなりませんが、クライアントがそれらを送信すべきではなく、このセクションでは、唯一のコンテキストを提供するために含めました。
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.
リレーの目的のために、フォワードパス「は、2つの@、ONE @：THREE @ JOE」形式のソースルートであってもよいし、ONE、TWO、THREEとは、完全修飾ドメイン名である必要があります。このフォームは、アドレスとルートの区別を強調するために使用されます。メールボックスは絶対アドレスで、ルートがそこに到達する方法についての情報です。二つの概念を混同してはなりません。
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.
ソースルートを使用する場合、RFC 821および以下のテキストは、順方向と逆の経路を構築し、更新するための機構のために相談すべきです。
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.
forward-pathとreverse-pathは必ずしも必要ではないメッセージで、SMTPコマンドと応答に表示されていることに注意してください。それはに表示されるこれらのパス、特にこの構文の必要がない、です「：を」、「から：」、「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).
ホストのリストが存在する場合、それは「逆」ソースルートであり、メールがリスト上の各ホストを経由して中継されたことを示している（リストの最初のホストは、最新のリレーでした）。このリストは、送信者に配信不能通知を返すためのソースルートとして使用されています。各中継ホストがリストの先頭に自分自身を追加するとして、それはむしろ、（それらが異なる場合）、メールが来たから、交通環境のそれよりも、メールを中継されている輸送環境で知られているように、それはその名前を使用しなければなりません。
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 A典型的な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簡易メール転送サービスレディーC：EHLO bar.com S：250-8BITMIME S：250-SIZEのS：250-DSN S：250 HELPのC：MAIL 250-foo.comはbar.comのS挨拶FROM：<Smith@bar.com> S：250 OK C：RCPT TO：<Jones@foo.com> S：250 OK C：RCPT TO：<Green@foo.com> S：550、そのようなユーザーここでC： RCPT TO：<Brown@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 OK C：DATA S：354開始メール入力; 。<CRLF> <CRLF> Cで終わる：何とか何とか何とか... C：...等。などなどC：。 S：250 OK C：Sを終了：221 foo.comサービス閉鎖伝送路
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
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簡易メール転送サービスレディーC：EHLO bar.com S：250-8BITMIME S：250-SIZEのS：250-DSN S：250 HELPのC：MAIL 250-foo.comはbar.comのS挨拶FROM：<JQP@bar.com> S：250 OK C：RCPT TO：<@ foo.com:Jones@XYZ.COM> S：250 OK C：DATA S：354開始メール入力; <CRLF>で終わる<CRLF> Cを：日付：木、1998年5月21日5時33分29秒-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
C：から：ジョンQ.公共<JQP@bar.com> C：件名：ボードCの次回会合：TO：Jones@xyz.com C：C：ビル：C：取締役会の次回会合火曜日に：Cになります。 C：ジョン。 C：。 S：250 OK C：Sを終了：221 foo.comサービス閉鎖伝送路
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簡易メール転送サービスレディーC：EHLO foo.com S：250 xyz.comは空気Cである：<@ foo.com:JQP@bar.com> S：MAIL FROM：250 OK C： RCPT TO：<Jones@XYZ.COM> S：250 OK C：データS：354開始メール入力; <CRLF>で終了する<CRLF> C：受付：bar.comからfoo.comによって;木、1998年5月21日C：午前5時33分29秒-0700 C：日付：木、1998年5月21日午前5時33分22秒-0700 C：から：ジョンQ.公共<JQP@bar.com> C：件名：ボードCの次回会合：TO：Jones@xyz.com C：C：ビル：C：取締役会の次回会合はCになります：火曜日に。 C：ジョン。 C：。 S：250 OK C：Sを終了：221 foo.comサービス閉鎖伝送路
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: 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 HELPのC：VRFYクリスピンS：250マーク・クリスピン<Admin.MRC@foo.com> C：から送信する：<EAK@bar.com> S：250 OK C：RCPT TO：<管理.MRC @ foo.com> S：250 OK C：DATA S：354開始メール入力; 。<CRLF> <CRLF> Cで終わる：何とか何とか何とか... C：...等。などなどC：。 S：250 OK C：Sを終了：221 foo.comサービス閉鎖伝送路
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.
一般的には、インターネットや他のメールシステム間のゲートウェイは、関連する2つのメールシステム間の境界を越えて任意の階層化のセマンティクスを保護しようとすべきです。 （他のメッセージヘッダや本文に、1つのシステムからのエンベロープ情報など）マッピングによって近道を取るしようとすると、ゲートウェイ・翻訳アプローチは、一般的に重要な点で不十分であることが証明されています。両方のエンベロープとヘッダとインターネットメールをサポートしていない環境の間の変換システムは、いくつかの情報損失がほとんど不可避であることを理解した上で書かなければなりません。
F. Deprecated Features of
のF.非推奨機能
A few features of RFC 821 have proven to be problematic and SHOULD NOT be used in Internet mail.
RFC 821のいくつかの機能は、問題があることが証明されているとインターネットメールでは使用しないでください。
F.1 TURN
F.1 TURN
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.
RFC 821で説明このコマンドは、以来、重要なセキュリティ上の問題を提起するには、クライアントとサーバスイッチの役割ということを要求しているホストの強力な認証が存在しない場合に、簡単にその正しい宛先からのメールをそらすために使用することができます。その使用は推奨されません。サーバがクライアントを認証できない限り、SMTPシステムは、それを使用しないでください。
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.
RFC 821は、リレーのシリーズを経由して別のホストからのメールを取得するには、明示的なソースルーティングの概念を利用しました。トラフィックが彼らのためにドメインネームシステム「MX」のレコードと最後の重要な正当化の導入によって排除された通常のメールでのソースルートを利用するための要件は、「以下のアドレス明確な要件で、RFC 1123で、導入によって排除されました@」すべての完全修飾ドメイン名でなければなりません。その結果、ソースルートを使用するための唯一の残りの正当化は、非常に古いSMTPクライアントやMUAをためとメールシステムのデバッグではサポートされています。彼らは、しかし、まだ後者の状況で、そして関連する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.
このドキュメントの本体で指定し、必要に応じて、RFC 1123で彼らは、ルートを無視して、アドレスの唯一のターゲットドメインを利用することができるようSMTPサーバは、ソースルートの文法を受け入れ続けなければなりません。彼らはソースルートを利用した場合は、メッセージは、アドレス1に示した第1のドメインに送らなければなりません。具体的には、サーバは、ソースルート内のショートカットを推測してはなりません。
Clients SHOULD NOT utilize explicit source routing except under unusual circumstances, such as debugging or potentially relaying around firewall or mail system configuration errors.
クライアントは、このようなデバッグなど、異常な状況を除いて、明示的なソースルーティングを利用または潜在的にファイアウォールやメールシステムの設定エラーを中心に中継すべきではありません。
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＃の-literals
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.
RFC 821は、シャープ記号「＃」で始まる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桁の年はインターネットメールシステムでは許可されませんでした。
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.
ユーザのメールボックスにメッセージを配信するためのメカニズムを指定することに加えて、RFC 821は任意、追加の提供、ユーザの端末画面に直接メッセージを配信するためのコマンド。これらのコマンド（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.
クライアントは、サービスとしてSEND、SAML、またはSOMLを提供すべきではありません。サーバはそれらを実装するかもしれません。これらは、サーバによって実装されている場合は、RFC 821で指定された実装モデルを使用しなければなりませんし、コマンド名はEHLOコマンドに応答して公開する必要があります。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。