RFC2821 日本語訳

2821 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001. (Format: TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869, STD0010) (Obsoleted by RFC5321) (Updated by RFC5336) (Status: PROPOSED STANDARD)

Network Working Group                                 J. Klensin, Editor
Request for Comments: 2821                             AT&T Laboratories
Obsoletes: 821, 974, 1869                                     April 2001
Updates: 1123
Category: Standards Track

ワーキンググループJ.Klensin、コメントを求めるエディタ要求をネットワークでつないでください: 2821のAT&T研究所が以下を時代遅れにします。 821、974、1869 2001年4月は以下をアップデートします。 1123年のカテゴリ: 標準化過程

                     Simple Mail Transfer Protocol


Status of this Memo


   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice


   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。



   This document is a self-contained specification of the basic protocol
   for the Internet electronic mail transport.  It consolidates, updates
   and clarifies, but doesn't add new or change existing functionality
   of the following:

このドキュメントはインターネット電子メール輸送のための基本プロトコルの自己充足的な仕様です。 それは、以下の既存の機能性を統合するか、アップデートして、はっきりさせますが、新しく加えるか、または変えません:

   -  the original SMTP (Simple Mail Transfer Protocol) specification of
      RFC 821 [30],

- RFC821[30]の当初のSMTP(シンプルメールトランスファプロトコル)仕様

   -  domain name system requirements and implications for mail
      transport from RFC 1035 [22] and RFC 974 [27],

- メールのためのドメイン名システム要求と含意はRFCから1035[22]とRFC974[27]を輸送します。

   -  the clarifications and applicability statements in RFC 1123 [2],

- そしてRFC1123[2]の明確化と適用性証明。

   -  material drawn from the SMTP Extension mechanisms [19].

- SMTP Extensionメカニズム[19]から得られた材料。

   It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the
   mail transport materials of RFC 1123).  However, RFC 821 specifies
   some features that were not in significant use in the Internet by the
   mid-1990s and (in appendices) some additional transport models.
   Those sections are omitted here in the interest of clarity and
   brevity; readers needing them should refer to RFC 821.

それは、RFC821、RFC974を時代遅れにして、RFC1123(RFC1123のメール輸送の材料を取り替えます)をアップデートします。 しかしながら、RFC821は1990年代の半ばまでにインターネットで重要に使用中でなかったいくつかの特徴と何人かの(付録の)追加輸送モデルを指定します。 それらのセクションは明快と簡潔さのためにここで省略されます。 彼らを必要とする読者はRFC821を参照するべきです。

Klensin                     Standards Track                     [Page 1]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   It also includes some additional material from RFC 1123 that required
   amplification.  This material has been identified in multiple ways,
   mostly by tracking flaming on various lists and newsgroups and
   problems of unusual readings or interpretations that have appeared as
   the SMTP extensions have been deployed.  Where this specification
   moves beyond consolidation and actually differs from earlier
   documents, it supersedes them technically as well as textually.

また、それは増幅を必要としたRFC1123からの何らかの追加材料を含んでいます。 この材料は複数の方法で特定されました、ほとんど様々なリスト、ニュースグループ、および珍しい読書の問題で燃えるような追跡かSMTP拡張子が配布されたとき現れた解釈で。 この仕様が強化を超えて移行して、実際に以前のドキュメントと異なっているところでは、それは技術的に原文にそれらに取って代わります。

   Although SMTP was designed as a mail transport and delivery protocol,
   this specification also contains information that is important to its
   use as a 'mail submission' protocol, as recommended for POP [3, 26]
   and IMAP [6].  Additional submission issues are discussed in RFC 2476

メール輸送と配送が議定書を作るとき、SMTPは設計されましたが、また、この仕様は'メール提案'プロトコルとして使用に重要な情報を含んでいます、POP[3、26]とIMAP[6]のために推薦されるように。 RFC2476[15]で追加服従問題について議論します。

   Section 2.3 provides definitions of terms specific to this document.
   Except when the historical terminology is necessary for clarity, this
   document uses the current 'client' and 'server' terminology to
   identify the sending and receiving SMTP processes, respectively.

セクション2.3はこのドキュメントに特定の用語の定義を提供します。 歴史的な用語が明快に必要である時を除いて、このドキュメントは発信を特定するのに現在の'クライアント'と'サーバ'用語を使用します、そして、SMTPを受けるのはそれぞれ処理されます。

   A companion document [32] discusses message headers, message bodies
   and formats and structures for them, and their relationship.


Table of Contents


   1. Introduction ..................................................  4
   2. The SMTP Model ................................................  5
   2.1 Basic Structure ..............................................  5
   2.2 The Extension Model ..........................................  7
   2.2.1 Background .................................................  7
   2.2.2 Definition and Registration of Extensions ..................  8
   2.3 Terminology ..................................................  9
   2.3.1 Mail Objects ............................................... 10
   2.3.2 Senders and Receivers ...................................... 10
   2.3.3 Mail Agents and Message Stores ............................. 10
   2.3.4 Host ....................................................... 11
   2.3.5 Domain ..................................................... 11
   2.3.6 Buffer and State Table ..................................... 11
   2.3.7 Lines ...................................................... 12
   2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12
   2.3.9 Message Content and Mail Data .............................. 13
   2.3.10 Mailbox and Address ....................................... 13
   2.3.11 Reply ..................................................... 13
   2.4 General Syntax Principles and Transaction Model .............. 13
   3. The SMTP Procedures: An Overview .............................. 15
   3.1 Session Initiation ........................................... 15
   3.2 Client Initiation ............................................ 16
   3.3 Mail Transactions ............................................ 16
   3.4 Forwarding for Address Correction or Updating ................ 19

1. 序論… 4 2. SMTPはモデル化します… 5 2.1 基本的な構造… 5 2.2 拡大モデル… 7 2.2 .1バックグラウンド… 7 2.2 .2 拡大の定義と登録… 8 2.3用語… 9 2.3 .1 オブジェクトを郵送してください… 10 2.3 .2台の送付者と受信機… 10 2.3 .3 エージェントとメッセージにストアを郵送してください… 10 2.3 .4 接待します。 11 2.3 .5ドメイン… 11 2.3 .6 テーブルをバッファリングして、述べてください… 11 2.3 .7 立ち並んでいます… 12 2.3 .8台の創始者、配送、リレー、およびゲートウェイシステム… 12 2.3 .9 メッセージ内容とメールデータ… 13 2.3 .10のメールボックスとアドレス… 13 2.3 .11 返答してください… 13 2.4の一般構文プリンシプルズとトランザクションはモデル化されます… 13 3. SMTP手順: 概要… 15 3.1 セッション開始… 15 3.2 クライアント開始… 16 3.3 トランザクションを郵送してください… 16 3.4 住所変更かアップデートのための推進… 19

Klensin                     Standards Track                     [Page 2]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   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  Extended HELLO (EHLO) or HELLO (HELO) ................... 29 MAIL (MAIL) .............................................. 31 RECIPIENT (RCPT) ......................................... 31 DATA (DATA) .............................................. 33 RESET (RSET) ............................................. 34 VERIFY (VRFY) ............................................ 35 EXPAND (EXPN) ............................................ 35 HELP (HELP) .............................................. 35 NOOP (NOOP) .............................................. 35 QUIT (QUIT) ............................................. 36
   4.1.2 Command Argument Syntax .................................... 36
   4.1.3 Address Literals ........................................... 38
   4.1.4 Order of Commands .......................................... 39
   4.1.5 Private-use Commands ....................................... 40
   4.2  SMTP Replies ................................................ 40
   4.2.1 Reply Code Severities and Theory ........................... 42
   4.2.2 Reply Codes by Function Groups ............................. 44
   4.2.3  Reply Codes in Numeric Order .............................. 45
   4.2.4 Reply Code 502 ............................................. 46
   4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... 46
   4.3 Sequencing of Commands and Replies ........................... 47
   4.3.1 Sequencing Overview ........................................ 47
   4.3.2 Command-Reply Sequences .................................... 48
   4.4 Trace Information ............................................ 49
   4.5 Additional Implementation Issues ............................. 53
   4.5.1 Minimum Implementation ..................................... 53
   4.5.2 Transparency ............................................... 53
   4.5.3 Sizes and Timeouts ......................................... 54

3.5 デバッグアドレスのために、命令します… 20 3.5 .1概要… 20 3.5 .2 VRFYの通常の応答… 22 3.5 .3 VRFYかEXPN成功応答の意味… 22 3.5 .4 EXPNの意味論とアプリケーション… 23 3.6のドメイン… 23 3.7 リレーします。 24 3.8 Gatewayingに郵送してください… 25 3.8 .1 Gatewayingのヘッダー分野… 26 3.8 .2 Gatewayingの台詞を受けます… 26 3.8 .3 Gatewayingでは、扱います。 26 3.8 .4 Gatewayingの他のヘッダー分野… 27 3.8 Gatewayingの.5個の封筒… 27 3.9 セッションとコネクションズを終えます… 27 3.10のメーリングリストと別名… 28 3.10.1 アリア… 28 3.10.2 記載してください… 28 4. SMTP仕様… 29 4.1 SMTPは命令します… 29 4.1 .1 意味論と構文を命令してください… 29 4.1 .1 .1 こんにちは、(EHLO)か広げられて、こんにちは(HELO)… 29 4.1 .1 .2は(メール)を郵送します… 31 4.1 .1 .3 受取人(RCPT)… 31 4.1 .1 .4のデータ(データ)… 33 4.1 .1 .5は(RSET)をリセットしました… 34 4.1 .1 .6 (VRFY)について確かめてください… 35 4.1 .1 .7 (EXPN)を広げてください… 35 4.1 .1 .8 助けてください(助けます)… 35 4.1 .1 .9 NOOP(NOOP)… 35 4.1 .1 .10 やめてください(やめてください)… 36 4.1 .2 議論構文を命令してください… 36 4.1 .3 リテラルを扱ってください… 38 4.1 .4 コマンドの注文… 39 4.1 .5 私用は命令します… 40 4.2 SMTPは返答します… 40 4.2は厳しさと理論をコード化します.1が、返答する… 42 4.2 .2回答は機能でグループをコード化します… 44 4.2 .3 数値の回答コードは注文されます… 45 4.2 .4 回答コード502… 46 4.2 .5回答はデータとその後の<CRLFの後に><CRLF>をコード化します… 46 4.3 コマンドと回答の配列… 47 4.3 .1配列概要… 47 4.3 .2 コマンド回答系列… 48 4.4 情報をたどってください… 49 4.5 追加導入問題… 53 4.5 .1の最小の実装… 53 4.5 .2透明… 53 4.5 .3回のサイズとタイムアウト… 54

Klensin                     Standards Track                     [Page 3]

RFC 2821             Simple Mail Transfer Protocol            April 2001

メール転送プロトコル2001年4月に簡単なKlensin標準化過程[3ページ]RFC2821 Size limits and minimums ................................. 54 Timeouts ................................................. 56
   4.5.4 Retry Strategies ........................................... 57 Sending Strategy ......................................... 58 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 サイズ限界と最小限… 54 4.5 .3 .2回のタイムアウト… 56 4.5 .4 戦略を再試行してください… 57 4.5 .4 .1 戦略を送ります… 58 4.5 .4 .2 戦略を受けます… 59 4.5 逆経路であることでのヌル.5のメッセージ… 59 5. 解決を扱ってください、そして、取り扱いを郵送してください… 60 6. 問題検出と取り扱い… 62 6.1 メールによる信頼できる配信と回答… 62 6.2 検出を輪にしてください… 63 6.3 不規則を補います… 63 7. セキュリティ問題… 64 7.1 セキュリティとスプーフィングを郵送してください… 64 7.2「ブラインド」はコピーします… 65 7.3のVRFY、EXPN、およびセキュリティ… 65 7.4 発表における情報公開… 66 7.5 跡の分野での情報公開… 66 7.6 メッセージ推進における情報公開… 67 7.7 SMTPサーバの操作の範囲… 67 8. IANA問題… 67 9. 参照… 68 10. エディタのアドレス… 70 11. 承認… 70個の付録… 71 A.TCPはサービスを輸送します… 71 B. SMTPを生成するのはRFC822ヘッダーから命令します… 71 C.送信元経路… 72 D.シナリオ… 73 E. 他のゲートウェイ問題… 76 RFC821のF.の推奨しない特徴… 76 完全な著作権宣言文… 79

1. Introduction

1. 序論

   The objective of the Simple Mail Transfer Protocol (SMTP) is to
   transfer mail reliably and efficiently.


   SMTP is independent of the particular transmission subsystem and
   requires only a reliable ordered data stream channel.  While this
   document specifically discusses transport over TCP, other transports
   are possible.  Appendices to RFC 821 describe some of them.

SMTPは特定のトランスミッションサブシステムから独立していて、高信頼の規則正しいデータストリーム・チャンネルだけを必要とします。 このドキュメントは明確にTCPの上の輸送について議論しますが、他の輸送は可能です。 RFC821への付録はそれらのいくつかについて説明します。

   An important feature of SMTP is its capability to transport mail
   across networks, usually referred to as "SMTP mail relaying" (see
   section 3.8).  A network consists of the mutually-TCP-accessible
   hosts on the public Internet, the mutually-TCP-accessible hosts on a
   firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN
   environment utilizing a non-TCP transport-level protocol.  Using

SMTPの重要な特徴は通常、「SMTPメールリレー」と呼ばれたネットワークの向こう側にメールを輸送するその能力(セクション3.8を見る)です。 ネットワークが成る、互いにTCPアクセスしやすい、公共のインターネットのホスト、互いにTCPアクセスしやすい、ファイアウォールで孤立しているTCP/IPイントラネットのホスト、または非TCP輸送レベルプロトコルを利用するある他のLANかWAN環境におけるホスト。 使用

Klensin                     Standards Track                     [Page 4]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   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.


   In this way, a mail message may pass through a number of intermediate
   relay or gateway hosts on its path from sender to ultimate recipient.
   The Mail eXchanger mechanisms of the domain name system [22, 27] (and
   section 5 of this document) are used to identify the appropriate
   next-hop destination for a message being transported.

このように、メール・メッセージは経路を送付者から究極の受取人まで多くの中間的リレーかゲートウェイホストを通り抜けるかもしれません。 ドメイン名システム[22、27](そして、このドキュメントのセクション5)のメールeXchangerメカニズムは、輸送されるメッセージのために適切な次のホップの目的地を特定するのに使用されます。

2. The SMTP Model

2. SMTPモデル

2.1 Basic Structure

2.1 基本構造

   The SMTP design can be pictured as:


               +----------+                +----------+
   +------+    |          |                |          |
   | User |<-->|          |      SMTP      |          |
   +------+    |  Client- |Commands/Replies| Server-  |
   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
   | File |<-->|          |    and Mail    |          |<-->| File |
   |System|    |          |                |          |    |System|
   +------+    +----------+                +----------+    +------+
                SMTP client                SMTP server

+----------+ +----------+ +------+ | | | | | ユーザ| <-->、|、| SMTP| | +------+ | クライアント|コマンド/回答| サーバ| +------+ | SMTP| <、-、-、-、-、-、-、-、-、-、-、-、-、--、>| SMTP| +------+ | ファイル| <-->、|、| そして、メール| | <-->、| ファイル| |システム| | | | | |システム| +------+ +----------+ +----------+ +------+ SMTPクライアントSMTPサーバ

   When an SMTP client has a message to transmit, it establishes a two-
   way transmission channel to an SMTP server.  The responsibility of an
   SMTP client is to transfer mail messages to one or more SMTP servers,
   or report its failure to do so.


   The means by which a mail message is presented to an SMTP client, and
   how that client determines the domain name(s) to which mail messages
   are to be transferred is a local matter, and is not addressed by this
   document.  In some cases, the domain name(s) transferred to, or
   determined by, an SMTP client will identify the final destination(s)
   of the mail message.  In other cases, common with SMTP clients
   associated with implementations of the POP [3, 26] or IMAP [6]
   protocols, or when the SMTP client is inside an isolated transport
   service environment, the domain name determined will identify an
   intermediate destination through which all mail messages are to be
   relayed.  SMTP clients that transfer all traffic, regardless of the
   target domain names associated with the individual messages, or that
   do not maintain queues for retrying message transmissions that
   initially cannot be completed, may otherwise conform to this
   specification but are not considered fully-capable.  Fully-capable
   SMTP implementations, including the relays used by these less capable

どれがSMTPクライアントにメール・メッセージを提示されるか、そして、そのクライアントが、わたるメール・メッセージがことであるドメイン名が地域にかかわる事柄であり、このドキュメントによって扱われないとどのように決心しているかによる手段。 ドメイン名は、いくつかの場合、SMTPクライアントがメール・メッセージの最終的な目的地を特定することを移したか、または決定しました。 他のPOP[3、26]の実装に関連しているSMTPクライアントかIMAP[6]プロトコルについて一般的なケースかそれともいつ、SMTPクライアントが孤立している輸送サービス環境にいるかとき、決定するドメイン名はリレーされるすべてのメール・メッセージがことである中間的目的地を特定するでしょう。 個々のメッセージに関連している目標ドメイン名にかかわらずすべてのトラフィックを移すか、またはそんなに初めはメッセージ送信を再試行するための待ち行列が終了できないと主張しないSMTPクライアントは、そうでなければ、この仕様に従うかもしれませんが、完全にできると考えられません。 これらでそれほどできなく使用されるリレーを含む完全にできるSMTP実装

Klensin                     Standards Track                     [Page 5]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   ones, and their destinations, are expected to support all of the
   queuing, retrying, and alternate address functions discussed in this


   The means by which an SMTP client, once it has determined a target
   domain name, determines the identity of an SMTP server to which a
   copy of a message is to be transferred, and then performs that
   transfer, is covered by this document.  To effect a mail transfer to
   an SMTP server, an SMTP client establishes a two-way transmission
   channel to that SMTP server.  An SMTP client determines the address
   of an appropriate host running an SMTP server by resolving a
   destination domain name to either an intermediate Mail eXchanger host
   or a final target host.

いったん目標ドメイン名を決定して、わたるメッセージのコピーがことであるSMTPサーバーのアイデンティティを決定して、次に、その転送を実行するとSMTPクライアントがこのドキュメントでカバーされている手段。 SMTPサーバーへの郵便為替に作用するように、SMTPクライアントは両用トランスミッションチャンネルをそのSMTPサーバーに確立します。SMTPクライアントは中間的メールeXchangerホストか最終的な目標ホストのどちらかに目的地ドメイン名を決議することによってSMTPサーバーを実行する適切なホストのアドレスを決定します。

   An SMTP server may be either the ultimate destination or an
   intermediate "relay" (that is, it may assume the role of an SMTP
   client after receiving the message) or "gateway" (that is, it may
   transport the message further using some protocol other than SMTP).
   SMTP commands are generated by the SMTP client and sent to the SMTP
   server.  SMTP replies are sent from the SMTP server to the SMTP
   client in response to the commands.

SMTPサーバーは、最終仕向地か中間的「リレー」(メッセージを受け取った後に、すなわち、それはSMTPクライアントの役割を引き受けるかもしれない)か「ゲートウェイ」のどちらかであるかもしれません(すなわち、それはさらにSMTP以外の何らかのプロトコルを使用することでメッセージを輸送するかもしれません)。 SMTPコマンドをSMTPクライアントは生成して、SMTPサーバーに送ります。コマンドに対応してSMTPサーバーからSMTPクライアントにSMTP回答を送ります。

   In other words, message transfer can occur in a single connection
   between the original SMTP-sender and the final SMTP-recipient, or can
   occur in a series of hops through intermediary systems.  In either
   case, a formal handoff of responsibility for the message occurs: the
   protocol requires that a server accept responsibility for either
   delivering a message or properly reporting the failure to do so.

言い換えれば、メッセージ転送は、オリジナルのSMTP-送付者と最終的なSMTP-受取人の間に単独結合で起こることができるか、または仲介者システムを通して一連のホップに起こることができます。どちらの場合ではも、メッセージへの責任の正式な移管は起こります: プロトコルは、サーバが伝言をもたらすか、または適切にそうしないことを報告することへの責任を引き受けるのを必要とします。

   Once the transmission channel is established and initial handshaking
   completed, the SMTP client normally initiates a mail transaction.
   Such a transaction consists of a series of commands to specify the
   originator and destination of the mail and transmission of the
   message content (including any headers or other structure) itself.
   When the same message is sent to multiple recipients, this protocol
   encourages the transmission of only one copy of the data for all
   recipients at the same destination (or intermediate relay) host.

トランスミッションチャンネルがいったん完成した確立して初期のハンドシェイクになると、通常、SMTPクライアントはメールトランザクションを開始します。 そのようなトランザクションはメールの創始者と目的地を指定する一連のコマンドとメッセージ内容(どんなヘッダーや非重要構造も含んでいる)自体の伝達から成ります。 同じメッセージを複数の受取人に送るとき、このプロトコルは同じ目的地(または、中間的リレー)ホストのすべての受取人のためにデータのコピー1部だけのトランスミッションを奨励します。

   The server responds to each command with a reply; replies may
   indicate that the command was accepted, that additional commands are
   expected, or that a temporary or permanent error condition exists.
   Commands specifying the sender or recipients may include server-
   permitted SMTP service extension requests as discussed in section
   2.2.  The dialog is purposely lock-step, one-at-a-time, although this
   can be modified by mutually-agreed extension requests such as command
   pipelining [13].

サーバは回答で各コマンドに反応します。 回答は、コマンドを受け入れたか、追加コマンドが予想されるか、または一時的であるか永久的なエラー条件が存在するのを示すかもしれません。 送付者か受取人を指定するコマンドはSMTPサービス拡大要求がセクション2.2で議論するように受入れられたサーバを含むかもしれません。 コマンド連続送信[13]などの相談ずくの拡大要求でこれを変更できますが、対話は一度に一つ、わざわざ堅苦しいです。

Klensin                     Standards Track                     [Page 6]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   Once a given mail message has been transmitted, the client may either
   request that the connection be shut down or may initiate other mail
   transactions.  In addition, an SMTP client may use a connection to an
   SMTP server for ancillary services such as verification of email
   addresses or retrieval of mailing list subscriber addresses.

与えられたメール・メッセージがいったん伝えられると、クライアントは、接続が止められるよう要求するか、または他のメールトランザクションを開始するかもしれません。 さらに、SMTPクライアントはEメールアドレスの検証かメーリングリスト加入者アドレスの検索などの付属のサービスにSMTPサーバーに接続を使用するかもしれません。

   As suggested above, this protocol provides mechanisms for the
   transmission of mail.  This transmission normally occurs directly
   from the sending user's host to the receiving user's host when the
   two hosts are connected to the same transport service.  When they are
   not connected to the same transport service, transmission occurs via
   one or more relay SMTP servers.  An intermediate host that acts as
   either an SMTP relay or as a gateway into some other transmission
   environment is usually selected through the use of the domain name
   service (DNS) Mail eXchanger mechanism.

上に示されるように、このプロトコルはメールの伝達にメカニズムを提供します。 2人のホストが同じ輸送サービスに接続されるとき、通常、このトランスミッションは直接送付ユーザのホストから受信ユーザのホストまで起こります。 それらが同じ輸送サービスに接続されないとき、トランスミッションは1つ以上のリレーSMTPプロトコルのサーバで起こります。 通常、SMTPリレーとして、または、ゲートウェイとしてある他のトランスミッション環境に務める中間的ホストはドメイン名サービス(DNS)メールeXchangerメカニズムの使用で選ばれます。

   Usually, intermediate hosts are determined via the DNS MX record, not
   by explicit "source" routing (see section 5 and appendices C and

通常、中間的ホストは明白な「ソース」ルーティングで断固としているのではなく、DNS MX記録で断固としています(セクション5、付録C、およびF.2を見てください)。

2.2 The Extension Model

2.2 拡大モデル

2.2.1 Background

2.2.1 バックグラウンド

   In an effort that started in 1990, approximately a decade after RFC
   821 was completed, the protocol was modified with a "service
   extensions" model that permits the client and server to agree to
   utilize shared functionality beyond the original SMTP requirements.
   The SMTP extension mechanism defines a means whereby an extended SMTP
   client and server may recognize each other, and the server can inform
   the client as to the service extensions that it supports.

1990年に始まった取り組み、RFC821が完成した後におよそ10年間で、プロトコルはクライアントとサーバが、オリジナルのSMTP要件を超えて共有された機能性を利用するのに同意するのを可能にする「サービス拡大」モデルと共に変更されました。 SMTP拡張機能は拡張SMTPクライアントとサーバが互いを見分けるかもしれなくて、サーバがそれがサポートするサービス拡大に関してクライアントに知らせることができる手段を定義します。

   Contemporary SMTP implementations MUST support the basic extension
   mechanisms.  For instance, servers MUST support the EHLO command even
   if they do not implement any specific extensions and clients SHOULD
   preferentially utilize EHLO rather than HELO.  (However, for
   compatibility with older conforming implementations, SMTP clients and
   servers MUST support the original HELO mechanisms as a fallback.)
   Unless the different characteristics of HELO must be identified for
   interoperability purposes, this document discusses only EHLO.

現代のSMTP実装は基本的な拡張機能をサポートしなければなりません。例えば、少しの特定の拡大も実装しなく、クライアントSHOULDが優先的にHELOよりむしろEHLOを利用しても、サーバは、EHLOがコマンドであるとサポートしなければなりません。 (しかしながら、より古い従うとの互換性のために、実装、SMTPクライアント、およびサーバは後退としてオリジナルのHELOメカニズムをサポートしなければなりません。) 相互運用性目的のためにHELOの異なった特性を特定してはいけないなら、このドキュメントはEHLOだけについて議論します。

   SMTP is widely deployed and high-quality implementations have proven
   to be very robust.  However, the Internet community now considers
   some services to be important that were not anticipated when the
   protocol was first designed.  If support for those services is to be
   added, it must be done in a way that permits older implementations to
   continue working acceptably.  The extension framework consists of:

SMTPは広く配布されます、そして、高品質な実装は非常に強健であると判明しました。 しかしながら、インターネット共同体は、現在、重要であるプロトコルが1番目であったときに予期されなかったいくつかのサービスが設計されていると考えます。 それらのサービスのサポートが加えることであるなら、より古い実装が、許容できて働き続けているのを許容する方法でそれをしなければなりません。 拡大フレームワークは以下から成ります。

Klensin                     Standards Track                     [Page 7]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   -  The SMTP command EHLO, superseding the earlier HELO,

- 以前のHELOに取って代わって、SMTPはEHLOを命令します。

   -  a registry of SMTP service extensions,

- SMTPサービス拡張子の登録

   -  additional parameters to the SMTP MAIL and RCPT commands, and

- そしてSMTP MAILとRCPTコマンドへの追加パラメタ。

   -  optional replacements for commands defined in this protocol, such
      as for DATA in non-ASCII transmissions [33].

- このプロトコルで定義されたコマンド、非ASCII送信[33]におけるDATAなどの任意の交換。

   SMTP's strength comes primarily from its simplicity.  Experience with
   many protocols has shown that protocols with few options tend towards
   ubiquity, whereas protocols with many options tend towards obscurity.

SMTPの強さは主として簡単さから来ます。 多くのプロトコルの経験は、わずかなオプションがあるプロトコルは偏在の傾向があるのを示しましたが、多くのオプションがあるプロトコルは不鮮明の傾向があります。

   Each and every extension, regardless of its benefits, must be
   carefully scrutinized with respect to its implementation, deployment,
   and interoperability costs.  In many cases, the cost of extending the
   SMTP service will likely outweigh the benefit.

利益にかかわらず、実装、展開、および相互運用性コストに関して慎重にありとあらゆる拡大を精査しなければなりません。 多くの場合、SMTPサービスを広げる費用はおそらく利益より重いでしょう。

2.2.2 Definition and Registration of Extensions

2.2.2 拡大の定義と登録

   The IANA maintains a registry of SMTP service extensions.  A
   corresponding EHLO keyword value is associated with each extension.
   Each service extension registered with the IANA must be defined in a
   formal standards-track or IESG-approved experimental protocol
   document.  The definition must include:

IANAはSMTPサービス拡張子の登録を維持します。 対応するEHLOキーワード価値は各拡大に関連しています。 正規の標準規格道かIESGによって承認された実験プロトコルドキュメントでIANAに示されたそれぞれのサービス拡大を定義しなければなりません。 定義は以下を含まなければなりません。

   -  the textual name of the SMTP service extension;

- SMTPサービス拡張子の原文の名前。

   -  the EHLO keyword value associated with the extension;

- 拡大に関連しているEHLOキーワード価値。

   -  the syntax and possible values of parameters associated with the
      EHLO keyword value;

- EHLOキーワード価値に関連しているパラメタの構文と可能な値。

   -  any additional SMTP verbs associated with the extension
      (additional verbs will usually be, but are not required to be, the
      same as the EHLO keyword value);

- 拡大(追加動詞は、通常ありますが、EHLOキーワード価値として同じようにあるのに必要でない)に関連しているどんな追加SMTP動詞も。

   -  any new parameters the extension associates with the MAIL or RCPT

- 拡大がメールかRCPT動詞に関連づけるどんな新しいパラメタも。

   -  a description of how support for the extension affects the
      behavior of a server and client SMTP; and,

- 拡大のサポートがどうサーバとクライアントSMTPの動きに影響するかに関する記述。 そして

   -  the increment by which the extension is increasing the maximum
      length of the commands MAIL and/or RCPT, over that specified in
      this standard.

- 拡大がそれの上でコマンドのメール、そして/または、RCPTの最大の長さを増強している増分はこの規格で指定しました。

Klensin                     Standards Track                     [Page 8]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   In addition, any EHLO keyword value starting with an upper or lower
   case "X" refers to a local SMTP service extension used exclusively
   through bilateral agreement.  Keywords beginning with "X" MUST NOT be
   used in a registered service extension.  Conversely, keyword values
   presented in the EHLO response that do not begin with "X" MUST
   correspond to a standard, standards-track, or IESG-approved
   experimental SMTP service extension registered with IANA.  A
   conforming server MUST NOT offer non-"X"-prefixed keyword values that
   are not described in a registered extension.

さらに、上側の、または、低いケース「X」から始まるどんなEHLOキーワード価値も拡大が二国間条約を通して排他的に利用した地方のSMTPサービスについて言及します。 登録されたサービス拡大に「X」と共に始まるキーワードを使用してはいけません。 逆に、「X」と共に始まらないEHLO応答で提示されたキーワード値はIANAに示された規格、標準化過程、またはIESGによって承認された実験的なSMTPサービス拡張子に対応しなければなりません。 従うサーバは登録された拡大で説明されない非「X」前に置かれたキーワード値を提供してはいけません。

   Additional verbs and parameter names are bound by the same rules as
   EHLO keywords; specifically, verbs beginning with "X" are local
   extensions that may not be registered or standardized.  Conversely,
   verbs not beginning with "X" must always be registered.

追加動詞とパラメタ名はEHLOキーワードと同じ規則で縛られます。 明確に、「X」と共に始まる動詞は示されないかもしれないか、標準化されないかもしれない地方の拡大です。 逆に、いつも「X」と共に始まらない動詞を登録しなければなりません。

2.3 Terminology

2.3 用語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described below.


   1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that
      the definition is an absolute requirement of the specification.

1. This単語、「必要である」という用語または“SHALL"が、定義が仕様に関する絶対条件であることを意味しなければなりませんか?

   2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
      definition is an absolute prohibition of the specification.

2. This句でない、または句でない、「」、定義が仕様の絶対禁止であることを意味しなければならないでしょう。

   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
      there may exist valid reasons in particular circumstances to
      ignore a particular item, but the full implications must be
      understood and carefully weighed before choosing a different

3. 「推薦される」というSHOULD This単語、または形容詞が、特定の項目を無視する特定の事情の正当な理由が存在するかもしれないことを意味しますが、完全な含意を理解されて、異なったコースを選ぶ前に、慎重に熟慮しなければなりません。

   4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean
      that there may exist valid reasons in particular circumstances
      when the particular behavior is acceptable or even useful, but the
      full implications should be understood and the case carefully
      weighed before implementing any behavior described with this

4. どんなThisも言葉で表さないか、または句が「推薦しなかった」SHOULDは、このラベルで説明されたどんな振舞いも実装する前にいつ特定の振舞いが許容できるか、または役に立ちさえしますが、完全な含意が理解されるべきであるか、そして、この件が慎重に熟慮した特定の事情の正当な理由が存在するかもしれないことを意味します。

   5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
      truly optional.  One vendor may choose to include the item because
      a particular marketplace requires it or because the vendor feels
      that it enhances the product while another vendor may omit the
      same item.  An implementation which does not include a particular
      option MUST be prepared to interoperate with another
      implementation which does include the option, though perhaps with
      reduced functionality.  In the same vein an implementation which

5. 項目は、This単語か、形容詞「任意で」、意地悪ですが、本当に、任意の状態でそうするかもしれません。 1つのベンダーが、特定の市場がそれを必要とするか、またはベンダーが、それが製品を高めると感じるので別のベンダーが同じ項目を省略しているかもしれない間、項目を含んでいるのを選ぶかもしれません。 オプションを含んでいる別の実装で共同利用するように特定のオプションを含んでいない実装を準備しなければなりません、恐らく減少している機能性で。 同じ流れの実装、どれ

Klensin                     Standards Track                     [Page 9]

RFC 2821             Simple Mail Transfer Protocol            April 2001


      does include a particular option MUST be prepared to interoperate
      with another implementation which does not include the option
      (except, of course, for the feature the option provides.)


2.3.1 Mail Objects

2.3.1 オブジェクトを郵送してください。

   SMTP transports a mail object.  A mail object contains an envelope
   and content.

SMTPはメールオブジェクトを輸送します。 メールオブジェクトは封筒と内容を含んでいます。

   The SMTP envelope is sent as a series of SMTP protocol units
   (described in section 3).  It consists of an originator address (to
   which error reports should be directed); one or more recipient
   addresses; and optional protocol extension material.  Historically,
   variations on the recipient address specification command (RCPT TO)
   could be used to specify alternate delivery modes, such as immediate
   display; those variations have now been deprecated (see appendix F,
   section F.6).

SMTPのシリーズがユニット(セクション3で、説明される)について議定書の中で述べるとき、SMTP封筒を送ります。 それは創始者アドレス(エラー・レポートが向けられるべきである)から成ります。 1つ以上の受取人アドレス。 そして、任意のプロトコル拡大の材料。 歴史的に、代替配送モードを指定するのに受取人アドレス指定コマンド(RCPT TO)の変化を使用できました、即座のディスプレイなどのように。 それらの変化は現在、推奨しないです(付録F、セクションF.6を見てください)。

   The SMTP content is sent in the SMTP DATA protocol unit and has two
   parts:  the headers and the body.  If the content conforms to other
   contemporary standards, the headers form a collection of field/value
   pairs structured as in the message format specification [32]; the
   body, if structured, is defined according to MIME [12].  The content
   is textual in nature, expressed using the US-ASCII repertoire [1].
   Although SMTP extensions (such as "8BITMIME" [20]) may relax this
   restriction for the content body, the content headers are always
   encoded using the US-ASCII repertoire.  A MIME extension [23] defines
   an algorithm for representing header values outside the US-ASCII
   repertoire, while still encoding them using the US-ASCII repertoire.

SMTP内容は、SMTP DATAプロトコルユニットで送られて、2つの部品を持っています: ヘッダーとボディー。 内容が他の現代の規格に従うなら、ヘッダーはメッセージ書式仕様[32]のように構造化された分野/値の組の収集を形成します。 構造化されるなら、MIME[12]に従って、ボディーは定義されます。 内容は米国-ASCIIレパートリー[1]を使用することで示された自然で原文です。 SMTP拡張子である、("8BITMIME"[20])としてのそのようなものは満足しているボディーのためのこの規制を緩和するかもしれなくて、満足しているヘッダーは、米国-ASCIIレパートリーを使用することでいつもコード化されます。 MIME拡大[23]は米国-ASCIIレパートリーを使用することでまだそれらをコード化している間、米国-ASCIIレパートリーの外でヘッダー値を表すためのアルゴリズムを定義します。

2.3.2 Senders and Receivers

2.3.2 送付者と受信機

   In RFC 821, the two hosts participating in an SMTP transaction were
   described as the "SMTP-sender" and "SMTP-receiver".  This document
   has been changed to reflect current industry terminology and hence
   refers to them as the "SMTP client" (or sometimes just "the client")
   and "SMTP server" (or just "the server"), respectively.  Since a
   given host may act both as server and client in a relay situation,
   "receiver" and "sender" terminology is still used where needed for

RFC821では、SMTPトランザクションに参加する2人のホストが「SMTP-送付者」と「SMTP-受信機」として記述されました。 このドキュメントは、現在の産業用語を反映するために変えられて、したがって、それぞれ「SMTPクライアント」(または、まさしく時々「クライアント」)と「SMTPサーバー」(または、まさしく「サーバ」)とそれらを呼びます。 与えられたホストがサーバとクライアントとしてリレー状況で務めるかもしれないので、「受信機」と「送付者」用語は明快に必要であるところでまだ使用されています。

2.3.3 Mail Agents and Message Stores

2.3.3 メールエージェントとメッセージストア

   Additional mail system terminology became common after RFC 821 was
   published and, where convenient, is used in this specification.  In
   particular, SMTP servers and clients provide a mail transport service
   and therefore act as "Mail Transfer Agents" (MTAs).  "Mail User
   Agents" (MUAs or UAs) are normally thought of as the sources and

RFC821が発行されて、この仕様で便利であるところで使用された後に追加メールシステム用語は一般的になりました。 SMTPサーバーとクライアントは、特に、メール輸送サービスを提供して、したがって、「メール配達エージェント」(MTAs)として務めます。 そして通常、「メール・ユーザー・エージェント」(MUAsかUAs)がソースとして考えられる。

Klensin                     Standards Track                    [Page 10]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   targets of mail.  At the source, an MUA might collect mail to be
   transmitted from a user and hand it off to an MTA; the final
   ("delivery") MTA would be thought of as handing the mail off to an
   MUA (or at least transferring responsibility to it, e.g., by
   depositing the message in a "message store").  However, while these
   terms are used with at least the appearance of great precision in
   other environments, the implied boundaries between MUAs and MTAs
   often do not accurately match common, and conforming, practices with
   Internet mail.  Hence, the reader should be cautious about inferring
   the strong relationships and responsibilities that might be implied
   if these terms were used elsewhere.

メールの目標。 ソースでは、MUAがユーザから伝えられて、それをMTAに渡すためにメールを集めるかもしれません。 最終的な(「配送」)MTAはメールをMUAに渡すと考えられるでしょう(それ、例えば、「メッセージ店」にメッセージを預けることによって責任を少なくとも移して)。 しかしながら、これらの用語は少なくとも他の環境における、かなりの精度の外観と共に使用されますが、MUAsとMTAsの間の暗示している境界はしばしば正確に一般的で、従っている習慣をインターネット・メールに合わせるというわけではありません。 したがって、読者はこれらの用語がほかの場所で使用されたなら強い関係と暗示するかもしれない責任を推論することに関して用心深いはずです。

2.3.4 Host

2.3.4 ホスト

   For the purposes of this specification, a host is a computer system
   attached to the Internet (or, in some cases, to a private TCP/IP
   network) and supporting the SMTP protocol.  Hosts are known by names
   (see "domain"); identifying them by numerical address is discouraged.

この仕様の目的において、ホストはインターネット(または私設のTCP/IPネットワークへのいくつかの場合で)とSMTPプロトコルをサポートすることへの添付のコンピュータ・システムです。 ホストは名前によって知られています(「ドメイン」を見てください)。 数字のアドレスでそれらを特定するのはお勧めできないです。

2.3.5 Domain

2.3.5 ドメイン

   A domain (or domain name) consists of one or more dot-separated
   components.  These components ("labels" in DNS terminology [22]) are
   restricted for SMTP purposes to consist of a sequence of letters,
   digits, and hyphens drawn from the ASCII character set [1].  Domain
   names are used as names of hosts and of other entities in the domain
   name hierarchy.  For example, a domain may refer to an alias (label
   of a CNAME RR) or the label of Mail eXchanger records to be used to
   deliver mail instead of representing a host name.  See [22] and
   section 5 of this specification.

ドメイン(または、ドメイン名)は1つ以上のドットで切り離されたコンポーネントから成ります。 これらのコンポーネント、(DNS用語[22])の「ラベル」は、SMTP目的がASCII文字の組[1]から得られた手紙、ケタ、およびハイフンの系列から成るように制限されます。 ドメイン名はホストと他の実体の名前としてドメイン名階層構造に使用されます。 例えば、ドメインは、ホスト名を表すことの代わりにメールを提供するのに使用されるために別名(CNAME RRのラベル)かメールeXchanger記録のラベルを示すかもしれません。 この仕様の[22]とセクション5を見てください。

   The domain name, as described in this document and in [22], is the
   entire, fully-qualified name (often referred to as an "FQDN").  A
   domain name that is not in FQDN form is no more than a local alias.
   Local aliases MUST NOT appear in any SMTP transaction.

本書では説明されて[22]では、ドメイン名は全体です、完全に修飾された名前(しばしば"FQDN"と呼ばれます)。 FQDNフォームにないドメイン名はローカルの別名にすぎません。 ローカルの別名はどんなSMTPトランザクションにも現れてはいけません。

2.3.6 Buffer and State Table

2.3.6 バッファとステートテーブル

   SMTP sessions are stateful, with both parties carefully maintaining a
   common view of the current state.  In this document we model this
   state by a virtual "buffer" and a "state table" on the server which
   may be used by the client to, for example, "clear the buffer" or
   "reset the state table," causing the information in the buffer to be
   discarded and the state to be returned to some previous state.

双方が慎重に現状の共通認識を維持していて、SMTPセッションはstatefulです。 本書では私たちは例えば、「バッファをきれいにする」か、または「ステートテーブルをリセットすること」にクライアントによって使用されるかもしれないサーバで仮想の「バッファ」と「ステートテーブル」でこの状態をモデル化します、バッファの情報が捨てられることを引き起こして、状態が何らかの先に返されることを引き起こして。

Klensin                     Standards Track                    [Page 11]

RFC 2821             Simple Mail Transfer Protocol            April 2001


2.3.7 Lines

2.3.7 線

   SMTP commands and, unless altered by a service extension, message
   data, are transmitted in "lines".  Lines consist of zero or more data
   characters terminated by the sequence ASCII character "CR" (hex value
   0D) followed immediately by ASCII character "LF" (hex value 0A).
   This termination sequence is denoted as <CRLF> in this document.
   Conforming implementations MUST NOT recognize or generate any other
   character or character sequence as a line terminator.  Limits MAY be
   imposed on line lengths by servers (see section 4.5.3).

SMTPコマンドとどんなメッセージデータもサービス拡大で変更されない場合「系列」で送られません。 線がゼロから成ったか、またはすぐにASCII文字"LF"によって続かれた系列ASCII文字"CR"(十六進法値の0D)で、より多くのデータキャラクタが終わりました。(十六進法値の0A)。 この終止配列は<CRLF>として本書では指示されます。 実装を従わせるのは、系列ターミネータとしていかなる他のキャラクタかキャラクタシーケンスも見分けてはいけませんし、また生成してはいけません。 限界はサーバによって行長に課されるかもしれません(セクション4.5.3を見てください)。

   In addition, the appearance of "bare" "CR" or "LF" characters in text
   (i.e., either without the other) has a long history of causing
   problems in mail implementations and applications that use the mail
   system as a tool.  SMTP client implementations MUST NOT transmit
   these characters except when they are intended as line terminators
   and then MUST, as indicated above, transmit them only as a <CRLF>

さらに、テキスト(すなわち、どちらかもう片方のない)における、「むき出し」の"CR"か"LF"キャラクタの外観には、ツールとしてメールシステムを使用するメール実装とアプリケーションで問題を起こす長い歴史があります。 SMTPクライアント実装は、彼らが系列ターミネータとして意図する時を除いて、これらのキャラクタを伝えてはいけなくて、次に、上で示されるように単に<CRLF>系列としてそれらを伝えなければなりません。

2.3.8 Originator, Delivery, Relay, and Gateway Systems

2.3.8 創始者、配送、リレー、およびゲートウェイシステム

   This specification makes a distinction among four types of SMTP
   systems, based on the role those systems play in transmitting
   electronic mail.  An "originating" system (sometimes called an SMTP
   originator) introduces mail into the Internet or, more generally,
   into a transport service environment.  A "delivery" SMTP system is
   one that receives mail from a transport service environment and
   passes it to a mail user agent or deposits it in a message store
   which a mail user agent is expected to subsequently access.  A
   "relay" SMTP system (usually referred to just as a "relay") receives
   mail from an SMTP client and transmits it, without modification to
   the message data other than adding trace information, to another SMTP
   server for further relaying or for delivery.

この仕様は4つのタイプのSMTPシステムの中で区別をします、それらのシステムが電子メールを送る際に果たす役割に基づいて。 または、「起因する」システム(時々SMTP創始者と呼ばれる)がインターネットにメールを取り入れる、 より一般に、輸送サービス環境に。 「配送」SMTPシステムは、輸送サービス環境からメールを受け取るものであり、メールユーザエージェントにそれを渡すか、またはそれのaメールユーザエージェントが次にアクセサリーに予想されるメッセージ店にそれを預けます。 「リレー」SMTPシステム(通常、ちょうど「リレー」に言及される)は、SMTPクライアントからメールを受け取って、それを伝えます、トレース情報を加えるのを除いたメッセージデータへの変更なしで、一層のリレーか配送のための別のSMTPサーバーに。

   A "gateway" SMTP system (usually referred to just as a "gateway")
   receives mail from a client system in one transport environment and
   transmits it to a server system in another transport environment.
   Differences in protocols or message semantics between the transport
   environments on either side of a gateway may require that the gateway
   system perform transformations to the message that are not permitted
   to SMTP relay systems.  For the purposes of this specification,
   firewalls that rewrite addresses should be considered as gateways,
   even if SMTP is used on both sides of them (see [11]).

「ゲートウェイ」SMTPシステム(通常、ちょうど「ゲートウェイ」に言及される)は、クライアントシステムから1つの輸送環境でメールを受け取って、別の輸送環境でサーバシステムにそれを伝えます。 この仕様の目的のために、アドレスを書き直すファイアウォールはゲートウェイであるとみなされるべきです、SMTPがそれらの両側で使用されても。ゲートウェイのどちらかの側面のプロトコルの違いか輸送環境の間のメッセージ意味論が、ゲートウェイシステムがメッセージへのSMTPリレー方式に受入れられない変換を実行するのを必要とするかもしれません。([11])を見てください。

Klensin                     Standards Track                    [Page 12]

RFC 2821             Simple Mail Transfer Protocol            April 2001


2.3.9 Message Content and Mail Data

2.3.9 メッセージ内容とメールデータ

   The terms "message content" and "mail data" are used interchangeably
   in this document to describe the material transmitted after the DATA
   command is accepted and before the end of data indication is
   transmitted.  Message content includes message headers and the
   possibly-structured message body.  The MIME specification [12]
   provides the standard mechanisms for structured message bodies.

用語「メッセージ内容」と「メールデータ」は、DATAコマンドを受け入れた後とデータ指示の終わりを伝える前に伝える材料について説明するのに互換性を持って本書では使用されます。 メッセージ内容はメッセージヘッダーとことによると構造化されたメッセージ本体を含んでいます。 MIME仕様[12]は構造化されたメッセージ本体に標準のメカニズムを提供します。

2.3.10 Mailbox and Address

2.3.10 メールボックスとアドレス

   As used in this specification, an "address" is a character string
   that identifies a user to whom mail will be sent or a location into
   which mail will be deposited.  The term "mailbox" refers to that
   depository.  The two terms are typically used interchangeably unless
   the distinction between the location in which mail is placed (the
   mailbox) and a reference to it (the address) is important.  An
   address normally consists of user and domain specifications.  The
   standard mailbox naming convention is defined to be "local-
   part@domain": contemporary usage permits a much broader set of
   applications than simple "user names".  Consequently, and due to a
   long history of problems when intermediate hosts have attempted to
   optimize transport by modifying them, the local-part MUST be
   interpreted and assigned semantics only by the host specified in the
   domain part of the address.

この仕様で使用されるように、「アドレス」はメールが送られるユーザかメールが預けられる位置を特定する文字列です。 「メールボックス」という用語はその貯蔵所について言及します。 メールが置かれる位置(メールボックス)とそれの参照(アドレス)の区別が重要でない場合、2つの用語が通常互換性を持って使用されます。 通常、アドレスはユーザとドメイン仕様から成ります。 一般的なメールボックス命名規則は「地方の part@domain 」になるように定義されます: 現代の用法は簡単な「ユーザ名」よりはるかに広いアプリケーションを可能にします。 その結果と、中間的ホストが、彼らを変更することによって輸送を最適化するのを試みたときの問題の長い歴史のため、地方の部分は、単にアドレスのドメイン部分で指定されたホストが、解釈されて、意味論を割り当てなければなりません。

2.3.11 Reply

2.3.11 回答

   An SMTP reply is an acknowledgment (positive or negative) sent from
   receiver to sender via the transmission channel in response to a
   command.  The general form of a reply is a numeric completion code
   (indicating failure or success) usually followed by a text string.
   The codes are for use by programs and the text is usually intended
   for human users.  Recent work [34] has specified further structuring
   of the reply strings, including the use of supplemental and more
   specific completion codes.

SMTP回答はコマンドに対応したトランスミッションチャンネルで受信機から送付者に送られた承認(肯定しているか否定している)です。 回答の一般的なフォームは通常、テキスト文字列がいうことになった数値完了コード(失敗を示すか、成功)です。 プログラムによってコードは使用のためのものです、そして、通常、テキストは人間のユーザのために意図します。 近作[34]は回答ストリングの一層の構造を指定しました、補足の、そして、より特定の完了コードの使用を含んでいて。

2.4 General Syntax Principles and Transaction Model

2.4 一般構文原則とトランザクションモデル

   SMTP commands and replies have a rigid syntax.  All commands begin
   with a command verb.  All Replies begin with a three digit numeric
   code.  In some commands and replies, arguments MUST follow the verb
   or reply code.  Some commands do not accept arguments (after the
   verb), and some reply codes are followed, sometimes optionally, by
   free form text.  In both cases, where text appears, it is separated
   from the verb or reply code by a space character.  Complete
   definitions of commands and replies appear in section 4.

SMTPコマンドと回答には、堅い構文があります。 すべてのコマンドがコマンド動詞で始まります。 すべてのRepliesが3ケタ数字コードで始まります。 いくつかのコマンドと回答では、議論は動詞か回答コードに従わなければなりません。 いくつかのコマンドは主張(動詞の後の)を受け入れません、そして、いくつかの回答コードが任意に時々従われています、自由形式テキストで。 どちらの場合も、テキストが現れるところに、それは間隔文字によって動詞か回答コードと切り離されます。 コマンドと回答の完全な定義はセクション4に現れます。

Klensin                     Standards Track                    [Page 13]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
   and extension name keywords) are not case sensitive, with the sole
   exception in this specification of a mailbox local-part (SMTP
   Extensions may explicitly specify case-sensitive elements).  That is,
   a command verb, an argument value other than a mailbox local-part,
   and free form text MAY be encoded in upper case, lower case, or any
   mixture of upper and lower case with no impact on its meaning.  This
   is NOT true of a mailbox local-part.  The local-part of a mailbox
   MUST BE treated as case sensitive.  Therefore, SMTP implementations
   MUST take care to preserve the case of mailbox local-parts.  Mailbox
   domains are not case sensitive.  In particular, for some hosts the
   user "smith" is different from the user "Smith".  However, exploiting
   the case sensitivity of mailbox local-parts impedes interoperability
   and is discouraged.

動詞とパラメータ値(キーワードというRCPTコマンドと拡大名の例えば、「TO:」か「To:」)は大文字と小文字を区別していません、メールボックスの地方の部分のこの仕様による唯一の例外で(SMTP拡張子は明らかに大文字と小文字を区別する要素を指定するかもしれません)。 それはそうです、コマンド動詞、メールボックスの地方の部分以外のパラメータ値、そして、自由形式テキストが意味で大文字と小文字の大文字、小文字、またはどんな混合物の中にも影響なしでコード化されるかもしれません。 これはメールボックスの地方の部分に関して本当ではありません。 大文字と小文字を区別するとしてメールボックスの地方の部分を扱わなければなりません。 したがって、SMTP実装は、メールボックスの地方の部分に関するケースを保存するために注意されなければなりません。 メールボックスドメインは大文字と小文字を区別していません。 何人かのホストにとって、ユーザ「鍛冶屋」はユーザ「スミス」と特に、異なっています。 しかしながら、メールボックスの地方の部分のケース感度を利用するのは、相互運用性を妨害して、お勧めできないです。

   A few SMTP servers, in violation of this specification (and RFC 821)
   require that command verbs be encoded by clients in upper case.
   Implementations MAY wish to employ this encoding to accommodate those

いくつかのSMTPサーバー、これを違反して仕様(そして、RFC821)はコマンド動詞がコード化されるのを必要とします。大文字の中のクライアントで。 実装は、それらのサーバを収容するのにこのコード化を使いたがっているかもしれません。

   The argument field consists of a variable length character string
   ending with the end of the line, i.e., with the character sequence
   <CRLF>.  The receiver will take no action until this sequence is

議論分野は行の終わりで可変長文字列結末から成ります、すなわち、キャラクタシーケンス<CRLF>で。 この系列が受け取られているまで、受信機は行動を全く取らないでしょう。

   The syntax for each command is shown with the discussion of that
   command.  Common elements and parameters are shown in section 4.1.2.

各コマンドのための構文はそのコマンドの議論で示されます。 一般的な要素とパラメタはセクション4.1.2で見せられます。

   Commands and replies are composed of characters from the ASCII
   character set [1].  When the transport service provides an 8-bit byte
   (octet) transmission channel, each 7-bit character is transmitted
   right justified in an octet with the high order bit cleared to zero.
   More specifically, the unextended SMTP service provides seven bit
   transport only.  An originating SMTP client which has not
   successfully negotiated an appropriate extension with a particular
   server MUST NOT transmit messages with information in the high-order
   bit of octets.  If such messages are transmitted in violation of this
   rule, receiving SMTP servers MAY clear the high-order bit or reject
   the message as invalid.  In general, a relay SMTP SHOULD assume that
   the message content it has received is valid and, assuming that the
   envelope permits doing so, relay it without inspecting that content.
   Of course, if the content is mislabeled and the data path cannot
   accept the actual content, this may result in ultimate delivery of a
   severely garbled message to the recipient.  Delivery SMTP systems MAY
   reject ("bounce") such messages rather than deliver them.  No sending
   SMTP system is permitted to send envelope commands in any character

コマンドと回答はASCII文字の組[1]からキャラクタで構成されます。 輸送サービスが8ビットのバイト(八重奏)トランスミッションチャンネルを提供するとき、それぞれの7ビットのキャラクタは高位のビットがゼロまできれいにされている八重奏で正当化された伝えられた権利です。 より明確に、unextended SMTPサービスは7ビットの輸送だけを提供します。 情報が八重奏の高位のビットにある状態で、首尾よく特定のサーバと適切な拡大を交渉していない起因しているSMTPクライアントはメッセージを送ってはいけません。 そのようなメッセージがこの規則を違反して送られるなら、SMTPサーバーを受け取るのは、高位のビットをきれいにするか、またはメッセージが無効であると拒絶するかもしれません。 その内容を点検しないで、一般に、リレーSMTP SHOULDはそれが受け取ったメッセージ内容が有効であると仮定して、封筒が、そうするのを可能にすると仮定して、それをリレーします。 もちろん、内容が間違ったレッテルを貼られて、データ経路が実際の内容を受け入れることができないなら、これは受取人への厳しく誤り伝えられたメッセージの究極の配送をもたらすかもしれません。 配送SMTPシステムはそれらを提供するよりむしろそのようなメッセージを拒絶するかもしれません(「弾みます」)。 送付SMTPシステムが全くどんなキャラクタでも封筒コマンドを送ることが許可されていません。

Klensin                     Standards Track                    [Page 14]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   set other than US-ASCII; receiving systems SHOULD reject such
   commands, normally using "500 syntax error - invalid character"

米国-ASCIIを除いて、セットしてください。 受電方式SHOULDはそのようなコマンド、通常使用している「500構文エラー--無効のキャラクタ」回答を拒絶します。

   Eight-bit message content transmission MAY be requested of the server
   by a client using extended SMTP facilities, notably the "8BITMIME"
   extension [20].  8BITMIME SHOULD be supported by SMTP servers.
   However, it MUST not be construed as authorization to transmit
   unrestricted eight bit material.  8BITMIME MUST NOT be requested by
   senders for material with the high bit on that is not in MIME format
   with an appropriate content-transfer encoding; servers MAY reject
   such messages.

8ビットのメッセージ内容送信はサーバについて拡張SMTP施設(著しく"8BITMIME"拡大[20])を使用しているクライアントによって要求されているかもしれません。 8BITMIME SHOULD、SMTPサーバーによってサポートされてください。 しかしながら、8ビットの無制限な材料を伝えるためにそれを承認に理解してはいけません。 8BITMIMEは高いビットがオンの適切な満足している転送がコード化されているMIME形式にはない材料のために送付者によって要求されていてはいけません。 サーバはそのようなメッセージを拒絶するかもしれません。

   The metalinguistic notation used in this document corresponds to the
   "Augmented BNF" used in other Internet mail system documents.  The
   reader who is not familiar with that syntax should consult the ABNF
   specification [8].  Metalanguage terms used in running text are
   surrounded by pointed brackets (e.g., <CRLF>) for clarity.

本書では使用されるmetalinguistic記法は他のインターネット・メールシステムドキュメントで使用される「増大しているBNF」に対応しています。 その構文に詳しくない読者はABNF仕様[8]に相談するべきです。 明快のための先鋭な括弧(例えば、<CRLF>)によって広告のための活字原稿で使用されるメタ言語用語は囲まれます。

3. The SMTP Procedures: An Overview

3. SMTP手順: 概要

   This section contains descriptions of the procedures used in SMTP:
   session initiation, the mail transaction, forwarding mail, verifying
   mailbox names and expanding mailing lists, and the opening and
   closing exchanges.  Comments on relaying, a note on mail domains, and
   a discussion of changing roles are included at the end of this
   section.  Several complete scenarios are presented in appendix D.

このセクションはSMTPで用いられた手順の記述を含みます: セッション開始、メールボックス名と拡張メーリングリストについて確かめて、メールを転送するメールトランザクション、および初めの、そして、終わりの交換。 リレーのコメント、メール・ドメインに関する注、および役割を変える議論はこのセクションの端に含まれています。 いくつかの完全なシナリオが付録Dに提示されます。

3.1 Session Initiation

3.1 セッション開始

   An SMTP session is initiated when a client opens a connection to a
   server and the server responds with an opening message.


   SMTP 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 before closing
   the connection and SHOULD respond to any intervening commands with

SMTPプロトコルで、サーバはまだ以下の初期の接続を許している間、正式にトランザクションを拒絶できます: 220の代わりに初期の接続初めのメッセージで554応答を与えるかもしれません。 このアプローチを取るサーバが、クライアントがQUITを送るのをまだ待たなければならない、(接続とSHOULDを終える前の.10が)どんな介入しているコマンドにも応じるセクション4.1.1を見てください。

Klensin                     Standards Track                    [Page 15]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   "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

「コマンドの503の悪い系列。」 以来、SMTP接続をそのようなシステムにする試みはたぶん誤り(デバッグするのを容易にするほど初めのSHOULDが回答テキストの情報を提供する送付システムの接続のときに554応答を返すサーバ)中です。

3.2 Client Initiation

3.2 クライアント開始

   Once the server has sent the welcoming message and the client has
   received it, the client normally sends the EHLO command to the
   server, indicating the client's identity.  In addition to opening the
   session, use of EHLO indicates that the client is able to process
   service extensions and requests that the server provide a list of the
   extensions it supports.  Older SMTP systems which are unable to
   support service extensions and contemporary clients which do not
   require service extensions in the mail session being initiated, MAY
   use HELO instead of EHLO.  Servers MUST NOT return the extended
   EHLO-style response to a HELO command.  For a particular connection
   attempt, if the server returns a "command not recognized" response to
   EHLO, the client SHOULD be able to fall back and send HELO.

いったんサーバが歓迎メッセージを送って、クライアントがそれを受けると、通常、クライアントはEHLOコマンドをサーバに送ります、クライアントのアイデンティティを示して。 セッションを開くことに加えて、EHLOの使用は、クライアントがサービス拡大とサーバがそれがサポートする拡大のリストを提供するという要求を処理できるのを示します。 開始されるメールセッション、5月に修理するサービスが拡大であるとサポートすることができないシステムと現代のそうしないクライアントが拡大が必要であるより古いSMTPがEHLOの代わりにHELOを使用します。 サーバはHELOコマンドへの拡張EHLO-スタイル応答を返してはいけません。 特定の接続試みのために、サーバがEHLOへの「認識されなかったコマンド」応答を返すなら、クライアントSHOULDは後ろへ下がることができて、HELOを送ります。

   In the EHLO command the host sending the command identifies itself;
   the command may be interpreted as saying "Hello, I am <domain>" (and,
   in the case of EHLO, "and I support service extension requests").

EHLOコマンドで、コマンドを送るホストは身元を明らかにします。 「こんにちは、私は<ドメイン>(EHLOの場合では、「そして、私は、サービス拡大が要求であるとサポートする」)である」と言いながら、コマンドが解釈されるかもしれません。

3.3 Mail Transactions

3.3 メールトランザクション

   There are three steps to SMTP mail transactions.  The transaction
   starts with a MAIL command which gives the sender identification.
   (In general, the MAIL command may be sent only when no mail
   transaction is in progress; see section 4.1.4.)  A series of one or
   more RCPT commands follows giving the receiver information.  Then a
   DATA command initiates transfer of the mail data and is terminated by
   the "end of mail" data indicator, which also confirms the

SMTPメールトランザクションへの3ステップがあります。 トランザクションは送付者識別を与えるメールコマンドから始まります。 (メールトランザクションが全く進行していないときだけ、一般に、メールコマンドを送るかもしれません; セクション4.1.4を見てください。) 一連の1つ以上のRCPTコマンドが、受信機情報を教えながら、続きます。 次に、DATAコマンドは、メールデータの転送を起こして、「メールの終わり」データインディケータによって終えられます。(また、それは、トランザクションを確認します)。

   The first step in the procedure is the MAIL command.


      MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>


   This command tells the SMTP-receiver that a new mail transaction is
   starting and to reset all its state tables and buffers, including any
   recipients or mail data.  The <reverse-path> portion of the first or
   only argument contains the source mailbox (between "<" and ">"
   brackets), which can be used to report errors (see section 4.2 for a
   discussion of error reporting).  If accepted, the SMTP server returns
   a 250 OK reply.  If the mailbox specification is not acceptable for
   some reason, the server MUST return a reply indicating whether the

このコマンドは、新しいメールトランザクションが出かける、すべての州が見送るリセットとバッファにどんな受取人やメールデータも含めることであるとSMTP-受信機に言います。 1番目か議論だけの<の逆経路の>部分はソースメールボックス("<"と">"括弧の間の)を含んでいます(誤りが報告する議論に関してセクション4.2を見てください)。(誤りを報告するのにそれを使用できます)。 受け入れるなら、SMTPサーバーは250OK回答を返します。 メールボックス仕様がある理由で許容できないなら、サーバは回答表示を返さなければなりません。

Klensin                     Standards Track                    [Page 16]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   failure is permanent (i.e., will occur again if the client tries to
   send the same address again) or temporary (i.e., the address might be
   accepted if the client tries again later).  Despite the apparent
   scope of this requirement, there are circumstances in which the
   acceptability of the reverse-path may not be determined until one or
   more forward-paths (in RCPT commands) can be examined.  In those
   cases, the server MAY reasonably accept the reverse-path (with a 250
   reply) and then report problems after the forward-paths are received
   and examined.  Normally, failures produce 550 or 553 replies.

失敗は、永久的であるか(すなわち、再び、クライアントが再び同じアドレスを送ろうとすると、起こるでしょう)、または一時的です(クライアントが後で再び試みるなら、すなわち、アドレスを受け入れるかもしれません)。 この要件の見かけの範囲にもかかわらず、逆経路の受容性が1つ以上のフォワードパス(RCPTコマンドにおける)を調べることができるまで決定していないかもしれない事情があります。 それらの場合では、サーバが合理的に、逆経路(250回答がある)を受け入れるかもしれなくて、次に、フォワードパスの後のレポート問題は、受け取られて、調べられます。 通常、失敗は550か553の回答を起こします。

   Historically, the <reverse-path> can contain more than just a
   mailbox, however, contemporary systems SHOULD NOT use source routing
   (see appendix C).

歴史的に、<逆経路>はまさしくメールボックス以上を含むことができて、しかしながら、現代のシステムSHOULD NOTはソースルーティングを使用します(付録Cを見てください)。

   The optional <mail-parameters> are associated with negotiated SMTP
   service extensions (see section 2.2).


   The second step in the procedure is the RCPT command.


      RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>

RCPT TO:<フォワードパス>[SP<rcpt-パラメタ>]<CRLF>。

   The first or only argument to this command includes a forward-path
   (normally a mailbox and domain, always surrounded by "<" and ">"
   brackets) identifying one recipient.  If accepted, the SMTP server
   returns a 250 OK reply and stores the forward-path.  If the recipient
   is known not to be a deliverable address, the SMTP server returns a
   550 reply, typically with a string such as "no such user - " and the
   mailbox name (other circumstances and reply codes are possible).
   This step of the procedure can be repeated any number of times.

このコマンドへの1番目か議論だけが、1人の受取人を特定しながら、フォワードパス(通常いつも"<"と">"括弧によって囲まれたメールボックスとドメイン)を含んでいます。 受け入れるなら、SMTPサーバーは、250OK回答を返して、フォワードパスを保存します。 受取人が提出物のアドレスでないことが知られているなら、SMTPサーバーは通常「いいえ、そのようなユーザ」やメールボックス名などのひもで550回答を返します(他の事情と回答コードは可能です)。 いろいろな回手順のこのステップを繰り返すことができます。

   The <forward-path> can contain more than just a mailbox.
   Historically, the <forward-path> can be a source routing list of
   hosts and the destination mailbox, however, contemporary SMTP clients
   SHOULD NOT utilize source routes (see appendix C).  Servers MUST be
   prepared to encounter a list of source routes in the forward path,
   but SHOULD ignore the routes or MAY decline to support the relaying
   they imply.  Similarly, servers MAY decline to accept mail that is
   destined for other hosts or systems.  These restrictions make a
   server useless as a relay for clients that do not support full SMTP
   functionality.  Consequently, restricted-capability clients MUST NOT
   assume that any SMTP server on the Internet can be used as their mail
   processing (relaying) site.  If a RCPT command appears without a
   previous MAIL command, the server MUST return a 503 "Bad sequence of
   commands" response.  The optional <rcpt-parameters> are associated
   with negotiated SMTP service extensions (see section 2.2).

<フォワードパス>はまさしくメールボックス以上を含むことができます。 <フォワードパス>が歴史的に、ホストのソースルーティングリストとあて先メールボックスであるかもしれない、しかしながら、現代のSMTPクライアントSHOULD NOTは送信元経路を利用します(付録Cを見てください)。 フォワードパスで送信元経路のリストに遭遇するようにサーバを準備しなければなりませんが、SHOULDは、彼らが含意するリレーをサポートするためにルートか5月の衰退を無視します。 同様に、サーバは、他のホストかシステムのために運命づけられているメールを受け入れるのを断るかもしれません。これらの制限で、サーバは完全なSMTPが機能性であるとサポートしないクライアントのためのリレーとして役に立たなくなります。 その結果、制限された能力クライアントは、彼らのメール処理(リレーする)サイトとしてインターネットのどんなSMTPサーバーも使用できると仮定してはいけません。 RCPTコマンドが前のメールコマンドなしで現れるなら、サーバは503「コマンドの悪い系列」応答を返さなければなりません。 任意の<rcpt-パラメタ>は交渉されたSMTPサービス拡張子に関連しています(セクション2.2を見てください)。

   The third step in the procedure is the DATA command (or some
   alternative specified in a service extension).


Klensin                     Standards Track                    [Page 17]

RFC 2821             Simple Mail Transfer Protocol            April 2001


      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

受け入れるなら、SMTPサーバーは、354Intermediate回答を返して、系列をすべて引き継ぎますが、メールデータインディケータについて終わりを含まないのが、メッセージ・テキストであると考えます。 テキストの終わりが首尾よく得られて、保存されるとき、SMTP-受信機は250OK回答を送ります。

   Since the mail data is sent on the transmission channel, the end of
   mail data must be indicated so that the command and reply dialog can
   be resumed.  SMTP indicates the end of the mail data by sending a
   line containing only a "." (period or full stop).  A transparency
   procedure is used to prevent this from interfering with the user's
   text (see section 4.5.2).

トランスミッションチャンネルでメールデータを送るので、コマンドと回答対話を再開できるようにメールデータの終わりを示さなければなりません。 「SMTPはa」だけ、を含む系列を送ることによって、メールデータの終わりを示します。」 (期間か終止符。) 透明手順は、これがユーザのテキストを妨げるのを防ぐのに用いられます(セクション4.5.2を見てください)。

   The end of mail data indicator also confirms the mail transaction and
   tells the SMTP server to now process the stored recipients and mail
   data.  If accepted, the SMTP server returns a 250 OK reply.  The DATA
   command can fail at only two points in the protocol exchange:

メールデータインディケータの終わりは、また、メールトランザクションを確認して、今保存された受取人とメールデータを処理するようにSMTPサーバーに言います。 受け入れるなら、SMTPサーバーは250OK回答を返します。 DATAコマンドは2ポイントだけでプロトコル交換で失敗できます:

   -  If there was no MAIL, or no RCPT, command, or all such commands
      were rejected, the server MAY return a "command out of sequence"
      (503) or "no valid recipients" (554) reply in response to the DATA
      command.  If one of those replies (or any other 5yz reply) is
      received, the client MUST NOT send the message data; more
      generally, message data MUST NOT be sent unless a 354 reply is

- メールが全くなかったというわけではないか、またはRCPT、コマンド、またはそのようなすべてのコマンドが拒絶されたというわけではないなら、サーバはDATAコマンドに対応して(503)にもかかわらず、「有効な受取人がありません」(554)回答を「系列からのコマンド」に返すかもしれません。 それらの回答(または、いかなる他の5yz回答)の1つが受け取られているなら、クライアントはメッセージデータを送ってはいけません。 より一般に、354回答が受け取られていない場合、メッセージデータを送ってはいけません。

   -  If the verb is initially accepted and the 354 reply issued, the
      DATA command should fail only if the mail transaction was
      incomplete (for example, no recipients), or if resources were
      unavailable (including, of course, the server unexpectedly
      becoming unavailable), or if the server determines that the
      message should be rejected for policy or other reasons.

- 初めは、動詞を受け入れるか、そして、発行された354回答、メールトランザクションが単に不完全であったか(例えば、受取人がありません)、リソースが入手できなかった(もちろん不意にサーバを含んでいます入手できなくなる)、またはサーバが、メッセージが方針か他の理由で拒絶されるべきであることを決定するなら、DATAコマンドは失敗するべきです。

   However, in practice, some servers do not perform recipient
   verification until after the message text is received.  These servers
   SHOULD treat a failure for one or more recipients as a "subsequent
   failure" and return a mail message as discussed in section 6.  Using
   a "550 mailbox not found" (or equivalent) reply code after the data
   are accepted makes it difficult or impossible for the client to
   determine which recipients failed.

しかしながら、実際には、いくつかのサーバはメッセージ・テキストが受け取られていた後まで受取人検証を実行しません。 セクション6で議論して、SHOULDが「その後の失敗」として1人以上の受取人のための失敗を扱って、メール・メッセージを返すこれらのサーバ。 データを受け入れた後に「見つけられなかった550メールボックス」(または、同等物)回答コードを使用するのに、クライアントが、どの受取人が失敗したかを決心しているのが難しいか不可能になります。

   When RFC 822 format [7, 32] is being used, the mail data include the
   memo header items such as Date, Subject, To, Cc, From.  Server SMTP
   systems SHOULD NOT reject messages based on perceived defects in the
   RFC 822 or MIME [12] message header or message body.  In particular,

RFC822形式[7、32]が使用されているとき、メールデータはDateなどのメモヘッダーの品目を含んでいます、Subject、To、Cc、From。 サーバSMTPシステムSHOULD NOTはRFC822、MIME[12]メッセージヘッダーまたはメッセージ本体で知覚された欠陥に基づくメッセージを拒絶します。 特に

Klensin                     Standards Track                    [Page 18]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   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-


   Mail transaction commands MUST be used in the order discussed above.


3.4 Forwarding for Address Correction or Updating

3.4 住所変更かアップデートのための推進

   Forwarding support is most often required to consolidate and simplify
   addresses within, or relative to, some enterprise and less frequently
   to establish addresses to link a person's prior address with current
   one.  Silent forwarding of messages (without server notification to
   the sender), for security or non-disclosure purposes, is common in
   the contemporary Internet.

推進サポートが、企業以内かいくらかの企業アドレスを統合して、簡素化して、どんなより頻繁にも人の先のアドレスを現在の1つにリンクするためにアドレスを確立しないようにたいてい必要です。 セキュリティへのメッセージ(送付者へのサーバ通知のない)か非公開目的の静かな推進は現代のインターネットで一般的です。

   In both the enterprise and the "new address" cases, information
   hiding (and sometimes security) considerations argue against exposure
   of the "final" address through the SMTP protocol as a side-effect of
   the forwarding activity.  This may be especially important when the
   final address may not even be reachable by the sender.  Consequently,
   the "forwarding" mechanisms described in section 3.2 of RFC 821, and
   especially the 251 (corrected destination) and 551 reply codes from
   RCPT must be evaluated carefully by implementers and, when they are
   available, by those configuring systems.

企業と「新しいアドレス」ケースの両方では、情報隠蔽(そして、時々セキュリティ)問題は推進活動の副作用としてSMTPプロトコルを通して「最終的な」アドレスの暴露について反対の議論をします。 最終アドレスが送付者で届かないときさえ、これは特に重要であるかもしれません。 その結果、implementersであってそれらで構成することでそれらが利用可能であるときに慎重に特にRFC821のセクション3.2で説明されたメカニズム、251(目的地を修正する)、および551の回答コードがRCPTからの「進める」であることを評価しなければなりません。システム。

   In particular:


   *  Servers MAY forward messages when they are aware of an address
      change.  When they do so, they MAY either provide address-updating
      information with a 251 code, or may forward "silently" and return
      a 250 code.  But, if a 251 code is used, they MUST NOT assume that
      the client will actually update address information or even return
      that information to the user.

* それらがアドレス変化を意識しているとき、サーバはメッセージを転送するかもしれません。 彼らがそうすると、彼らは、250コードをアドレスをアップデートする情報に251コードを提供するか、「静かに」進めて、または返すかもしれません。 しかし、251コードが使用されているなら、彼らは、クライアントが実際にアドレス情報をアップデートするか、またはその情報をユーザに返しさえすると仮定してはいけません。



   *  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.


Klensin                     Standards Track                    [Page 19]

RFC 2821             Simple Mail Transfer Protocol            April 2001


3.5 Commands for Debugging Addresses

3.5 デバッグアドレスのためのコマンド

3.5.1 Overview

3.5.1 概要

   SMTP provides commands to verify a user name or obtain the content of
   a mailing list.  This is done with the VRFY and EXPN commands, which
   have character string arguments.  Implementations SHOULD support VRFY
   and EXPN (however, see section 3.5.2 and 7.3).

SMTPはユーザ名について確かめるか、またはメーリングリストの内容を得るコマンドを提供します。 VRFYとEXPNコマンドでこれをします。(コマンドには、文字列議論があります)。 実装SHOULDはVRFYとEXPNをサポートします(しかしながら、セクション3.5 .2と7.3を見てください)。

   For the VRFY command, the string is a user name or a user name and
   domain (see below).  If a normal (i.e., 250) response is returned,
   the response MAY include the full name of the user and MUST include
   the mailbox of the user.  It MUST be in either of the following

VRFYコマンドのために、ストリングは、ユーザ名かユーザ名とドメイン(以下を見る)です。 通常(すなわち、250)の応答を返すなら、応答は、ユーザのフルネームを含むかもしれなくて、ユーザのメールボックスを含まなければなりません。 それは以下のフォームのどちらかにあるに違いありません:

      User Name <local-part@domain>

ユーザ Name <local-part@domain 、gt;、地方のパート@domain

   When a name that is the argument to VRFY could identify more than one
   mailbox, the server MAY either note the ambiguity or identify the
   alternatives.  In other words, any of the following are legitimate
   response to VRFY:

VRFYへの議論である名前が1個以上のメールボックスを特定できたとき、サーバは、あいまいさに注意するか、または代替手段を特定するかもしれません。 言い換えれば、↓これのどれかはVRFYへの正統の応答です:

      553 User ambiguous




      553- Ambiguous;  Possibilities are
      553-Joe Smith <jsmith@foo.com>
      553-Harry Smith <hsmith@foo.com>
      553 Melvin Smith <dweep@foo.com>

553 あいまい。 ポシビリティーズが553ジョーの Smith <jsmith@foo.com である、gt;、553ハリーの Smith <hsmith@foo.com 、gt;、553メルビン Smith <dweep@foo.com 、gt。



      553-Ambiguous;  Possibilities
      553- <jsmith@foo.com>
      553- <hsmith@foo.com>
      553 <dweep@foo.com>

553あいまい。 ポシビリティーズ 553- <jsmith@foo.com 、gt;、553<hsmith@foo.com> 553 <dweep@foo.com 、gt。

   Under normal circumstances, a client receiving a 553 reply would be
   expected to expose the result to the user.  Use of exactly the forms
   given, and the "user ambiguous" or "ambiguous" keywords, possibly
   supplemented by extended reply codes such as those described in [34],
   will facilitate automated translation into other languages as needed.
   Of course, a client that was highly automated or that was operating
   in another language than English, might choose to try to translate
   the response, to return some other indication to the user than the

通常の状況下で、553回答を受け取るクライアントがユーザに結果を暴露すると予想されるでしょう。 ことによると[34]で説明されたものなどの拡張回答コードによって補われたまさに与えられた書式の使用、および「ユーザあいまいである」か「あいまいな」キーワードは必要に応じて他の言語への自動化された翻訳を容易にするでしょう。 もちろん、英語、力が応答を翻訳して、ある他の指示をユーザに返そうとするのを選ぶより非常に自動化されたクライアントかそれが別の言語で手術されていました。

Klensin                     Standards Track                    [Page 20]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   literal text of the reply, or to take some automated action such as
   consulting a directory service for additional information before
   reporting to the user.


   For the EXPN command, the string identifies a mailing list, and the
   successful (i.e., 250) multiline response MAY include the full name
   of the users and MUST give the mailboxes on the mailing list.


   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

何人かのホストでは、単一のメールボックスのためのメーリングリストと別名の区別は少しあいまいです、一般的なデータ構造が両方のタイプのエントリーを保持するかもしれなくて、1個のメールボックスだけを含むメーリングリストを持っているのが可能であるので。 要求をするなら、メーリングリスト、リストでそのように扱われたメッセージを皆に提供するなら応答を与えるかもしれなくて、そうでなければ、誤りがSHOULDであることを確信しているaにVRFYを適用するには、報告してください(例えば、「550Thatはメーリングリストです、ユーザでない」か「メーリングリストのメンバーについて確かめる252Unable」)。 ユーザ名を広げるのを要求をするなら、サーバが1つの名前を含むリストから成る積極的な応答を返すかもしれませんか、または誤りは報告されるかもしれません(例えば、「550 Thatはメーリングリストではなく、ユーザ名です」)。

   In the case of a successful multiline reply (normal for EXPN) exactly
   one mailbox is to be specified on each line of the reply.  The case
   of an ambiguous request is discussed above.

うまくいっているマルチライン回答(EXPNに、正常な)の場合では、ちょうど1個のメールボックスが回答の各系列で指定されることになっています。 上であいまいな要求に関するケースについて議論します。

   "User name" is a fuzzy term and has been used deliberately.  An
   implementation of the VRFY or EXPN commands MUST include at least
   recognition of local mailboxes as "user names".  However, since
   current Internet practice often results in a single host handling
   mail for multiple domains, hosts, especially hosts that provide this
   functionality, SHOULD accept the "local-part@domain" form as a "user
   name"; hosts MAY also choose to recognize other strings as "user

「ユーザ名」は、あいまいな用語であり、故意に使用されました。 VRFYかEXPNコマンドの実装は「ユーザ名」として少なくとも地方のメールボックスの認識を含まなければなりません。 しかしながら、現在のインターネット習慣がしばしば複数のドメインのためのただ一つのホスト取り扱いメールをもたらして以来のホスト、特にこの機能性、SHOULDを提供するホストが「ユーザ名」として" local-part@domain "フォームを認めます。 また、ホストは、他のストリングが「ユーザ名」であると認めるのを選ぶかもしれません。

   The case of expanding a mailbox list requires a multiline reply, such


      C: EXPN Example-People
      S: 250-Jon Postel <Postel@isi.edu>
      S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
      S: 250 Sam Q. Smith <SQSmith@specific.generic.com>

C: EXPN例人々S: 250ジョンの Postel <Postel@isi.edu 、gt;、S: 250フレッドの Fonebone <Fonebone@physics.foo-u.edu 、gt;、S: 250サムQ. Smith <SQSmith@specific.generic.com 、gt。



      C: EXPN Executive-Washroom-List
      S: 550 Access Denied to You.

C: EXPN幹部社員洗面所リストS: 550 あなたへのアクセス拒否。

Klensin                     Standards Track                    [Page 21]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   The character string arguments of the VRFY and EXPN commands cannot
   be further restricted due to the variety of implementations of the
   user name and mailbox list concepts.  On some systems it may be
   appropriate for the argument of the EXPN command to be a file name
   for a file containing a mailing list, but again there are a variety
   of file naming conventions in the Internet.  Similarly, historical
   variations in what is returned by these commands are such that the
   response SHOULD be interpreted very carefully, if at all, and SHOULD
   generally only be used for diagnostic purposes.

VRFYとEXPNコマンドの文字列議論はユーザ名とメールボックスリスト概念の実装のバラエティーのためさらに制限されない場合があります。 いくつかのシステムの上では、メーリングリストを含むファイルのためのファイル名であるEXPNコマンドの議論に、それは適切であるかもしれませんが、さまざまなファイル命名規則が再びインターネットであります。 これらのコマンドで返されるものの歴史的な変化は、同様に、応答SHOULDが非常にせいぜい慎重に解釈されるようなものとSHOULDです。一般に、単に診断目的で使用されてください。

3.5.2 VRFY Normal Response

3.5.2 VRFYの通常の応答

   When normal (2yz or 551) responses are returned from a VRFY or EXPN
   request, the reply normally includes the mailbox name, i.e.,
   "<local-part@domain>", where "domain" is a fully qualified domain
   name, MUST appear in the syntax.  In circumstances exceptional enough
   to justify violating the intent of this specification, free-form text
   MAY be returned.  In order to facilitate parsing by both computers
   and people, addresses SHOULD appear in pointed brackets.  When
   addresses, rather than free-form debugging information, are returned,
   EXPN and VRFY MUST return only valid domain addresses that are usable
   in SMTP RCPT commands.  Consequently, if an address implies delivery
   to a program or other system, the mailbox name used to reach that
   target MUST be given.  Paths (explicit source routes) MUST NOT be
   returned by VRFY or EXPN.

「VRFYかEXPN要求から通常(2yzか551)の応答を返すとき、通常、回答はメールボックス名を含んでいます、すなわち、 "<local-part@domain 、gt;、」 構文で「ドメイン」が完全修飾ドメイン名であるところに見えなければなりません。 この仕様の意図に違反するのを正当化するほど例外的な事情では、自由形式テキストを返すかもしれません。 コンピュータと人々の両方で分析するのを容易にするために、SHOULDが載っているアドレスは括弧を指しました。 自由形式デバッグ情報よりむしろアドレスを返すとき、EXPNとVRFY MUSTはSMTP RCPTコマンドで使用可能な有効なドメインアドレスだけを返します。 その結果、アドレスがプログラムか他のシステムに配送を含意するなら、その目標に達するのに使用されるメールボックス名を与えなければなりません。 経路(明白な送信元経路)はVRFYかEXPNによって返されてはいけません。

   Server implementations SHOULD support both VRFY and EXPN.  For
   security reasons, implementations MAY provide local installations a
   way to disable either or both of these commands through configuration
   options or the equivalent.  When these commands are supported, they
   are not required to work across relays when relaying is supported.
   Since they were both optional in RFC 821, they MUST be listed as
   service extensions in an EHLO response, if they are supported.

サーバ実装SHOULDはVRFYとEXPNの両方をサポートします。 安全保障上の理由で、実装はこれらのどちらかか両方が設定オプションによるコマンドか同等物であると無効にする方法を現地搬入に提供するかもしれません。 これらのコマンドがサポートされるとき、それらは必要でないことで、リレーするとき、リレーの向こう側に働いているのがサポートされるということです。 それらがRFC821でともに任意であったので、EHLO応答におけるサービス拡大としてそれらを記載しなければなりません、それらがサポートされるなら。

3.5.3 Meaning of VRFY or EXPN Success Response

3.5.3 VRFYかEXPN成功応答の意味

   A server MUST NOT return a 250 code in response to a VRFY or EXPN
   command unless it has actually verified the address.  In particular,
   a server MUST NOT return 250 if all it has done is to verify that the
   syntax given is valid.  In that case, 502 (Command not implemented)
   or 500 (Syntax error, command unrecognized) SHOULD be returned.  As
   stated elsewhere, implementation (in the sense of actually validating
   addresses and returning information) of VRFY and EXPN are strongly
   recommended.  Hence, implementations that return 500 or 502 for VRFY
   are not in full compliance with this specification.

実際にアドレスについて確かめていない場合、サーバはVRFYかEXPNコマンドに対応して250コードを返してはいけません。 特に、サーバはそれがしたすべてが与えられた構文が有効であることを確かめることであるなら250を返してはいけません。 その場合、502(実装されなかったコマンド)、または500の(構文エラーで、コマンド認識されていません)のSHOULD、返してください。 別記のとおり、VRFYとEXPNの実装(実際にアドレスと返品情報を有効にするという意味における)は強く推薦されます。 したがって、VRFYのために500か502を返す実装がこの仕様に応えてありません。

Klensin                     Standards Track                    [Page 22]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   There may be circumstances where an address appears to be valid but
   cannot reasonably be verified in real time, particularly when a
   server is acting as a mail exchanger for another server or domain.
   "Apparent validity" in this case would normally involve at least
   syntax checking and might involve verification that any domains
   specified were ones to which the host expected to be able to relay
   mail.  In these situations, reply code 252 SHOULD be returned.  These
   cases parallel the discussion of RCPT verification discussed in
   section 2.1.  Similarly, the discussion in section 3.4 applies to the
   use of reply codes 251 and 551 with VRFY (and EXPN) to indicate
   addresses that are recognized but that would be forwarded or bounced
   were mail received for them.  Implementations generally SHOULD be
   more aggressive about address verification in the case of VRFY than
   in the case of RCPT, even if it takes a little longer to do so.

事情がアドレスについて有効であるように見えますが、リアルタイムで合理的に確かめることができないところにあるかもしれません、特にサーバが別のサーバかドメインへのメール交換器として機能しているとき。 ホストができると予想したものがメールをリレーするなら、この場合、「見かけの正当性」は、通常、少なくとも構文の照合にかかわって、どんなドメインも指定した検証にかかわるでしょうに。 これらでは、状況、回答は252SHOULDをコード化します。返します。 これらのケースはセクション2.1で議論したRCPT検証の議論に沿います。 同様に、セクション3.4での議論は、認識しますが、転送するか、または弾ませるアドレスがそれらのために受け取られたメールであったのを示すのをVRFY(そして、EXPN)との回答コード251と551の使用に適用します。 一般に実装SHOULD、VRFYの場合ではRCPTに関するケースよりアドレス検査に関して攻撃的であってください、そうするために少し時間がかかっても。

3.5.4 Semantics and Applications of EXPN

3.5.4 EXPNの意味論とアプリケーション

   EXPN is often very useful in debugging and understanding problems
   with mailing lists and multiple-target-address aliases.  Some systems
   have attempted to use source expansion of mailing lists as a means of
   eliminating duplicates.  The propagation of aliasing systems with
   mail on the Internet, for hosts (typically with MX and CNAME DNS
   records), for mailboxes (various types of local host aliases), and in
   various proxying arrangements, has made it nearly impossible for
   these strategies to work consistently, and mail systems SHOULD NOT
   attempt them.

EXPNはメーリングリストと複数のあて先アドレス別名に関する問題をデバッグして、理解する際にしばしば非常に役に立ちます。 いくつかのシステムが、写しを排除する手段としてメーリングリストのソース拡張を使用するのを試みました。 インターネット、ホスト(通常、MXとCNAME DNS記録がある)、メールボックス(様々なタイプのローカル・ホスト別名)、および様々なproxyingアレンジメントにおけるメールがあるエイリアシングシステムの伝播でこれらの戦略が一貫して利くのがほとんど不可能になりました、そして、メールシステムSHOULD NOTはそれらを試みます。

3.6 Domains

3.6 ドメイン

   Only resolvable, fully-qualified, domain names (FQDNs) are permitted
   when domain names are used in SMTP.  In other words, names that can
   be resolved to MX RRs or A RRs (as discussed in section 5) are
   permitted, as are CNAME RRs whose targets can be resolved, in turn,
   to MX or A RRs.  Local nicknames or unqualified names MUST NOT be
   used.  There are two exceptions to the rule requiring FQDNs:

ドメイン名がSMTPで使用されるとき、溶解性だけの、そして、完全に適切なドメイン名(FQDNs)は受入れられます。 言い換えれば、MX RRsかA RRs(セクション5で議論するように)に決議できる名前は目標を決議できるCNAME RRsのように順番に受入れられます、MXかA RRsに。 ローカルのあだ名か資格のない名前を使用してはいけません。 規則へのFQDNsを必要とする2つの例外があります:

   -  The domain name given in the EHLO command MUST BE either a primary
      host name (a domain name that resolves to an A RR) or, if the host
      has no name, an address literal as described in section

- 一次ホスト名(AにRRを決議するドメイン名)かセクション4.1.1で説明されるアドレスリテラルのどちらかがホストに名前が全くないなら.1であったに違いないならEHLOコマンドで与えられたドメイン名。

   -  The reserved mailbox name "postmaster" may be used in a RCPT
      command without domain qualification (see section and
      MUST be accepted if so used.

- そして、「郵便局長」という予約されたメールボックス名がドメイン資格なしでRCPTコマンドに使用されるかもしれない、(.3が、)4.1に.1を区分するのを見る、そのように使用するなら、受け入れなければなりません。

Klensin                     Standards Track                    [Page 23]

RFC 2821             Simple Mail Transfer Protocol            April 2001


3.7 Relaying

3.7 リレー

   In general, the availability of Mail eXchanger records in the domain
   name system [22, 27] makes the use of explicit source routes in the
   Internet mail system unnecessary.  Many historical problems with
   their interpretation have made their use undesirable.  SMTP clients
   SHOULD NOT generate explicit source routes except under unusual
   circumstances.  SMTP servers MAY decline to act as mail relays or to
   accept addresses that specify source routes.  When route information
   is encountered, SMTP servers are also permitted to ignore the route
   information and simply send to the final destination specified as the
   last element in the route and SHOULD do so.  There has been an
   invalid practice of using names that do not appear in the DNS as
   destination names, with the senders counting on the intermediate
   hosts specified in source routing to resolve any problems.  If source
   routes are stripped, this practice will cause failures.  This is one
   of several reasons why SMTP clients MUST NOT generate invalid source
   routes or depend on serial resolution of names.

一般に、ドメイン名システム[22、27]のメールeXchanger記録の有用性で、インターネット・メールシステムにおける明白な送信元経路の使用は不要になります。 多くの彼らの解釈に関する歴史的な問題で、彼らの使用は望ましくなくなりました。 珍しい状況を除いて、SMTPクライアントSHOULD NOTは明白な送信元経路を生成します。 SMTPサーバーは、メール中継として機能するか、または送信元経路を指定するアドレスを認めるのを断るかもしれません。 また、経由地案内が遭遇するとき、SMTPサーバーは、経由地案内を無視して、単にルートにおける最後の要素として指定された最終的な目的地に発信するのが可能にされます、そして、SHOULDはそうします。 目的地名としてDNSに現れない名前を使用する無効の習慣がありました、送付者が、ソースルーティングで指定された中間的ホストがどんな問題も解決するのを頼りにしていて。送信元経路が剥取られると、この習慣は失敗を引き起こすでしょう。 これはSMTPクライアントが無効の送信元経路を生成してはいけませんし、また名前の連続の解決を当てにしてはいけないいくつかの理由の1つです。

   When source routes are not used, the process described in RFC 821 for
   constructing a reverse-path from the forward-path is not applicable
   and the reverse-path at the time of delivery will simply be the
   address that appeared in the MAIL command.


   A relay SMTP server is usually the target of a DNS MX record that
   designates it, rather than the final delivery system.  The relay
   server may accept or reject the task of relaying the mail in the same
   way it accepts or rejects mail for a local user.  If it accepts the
   task, it then becomes an SMTP client, establishes a transmission
   channel to the next SMTP server specified in the DNS (according to
   the rules in section 5), and sends it the mail.  If it declines to
   relay mail to a particular address for policy reasons, a 550 response
   SHOULD be returned.

通常、リレーSMTPサーバは最終的な配送システムよりむしろそれを指定するDNS MX記録の目標です。 リレーサーバは、地元のユーザのためにメールを受け入れるか、または拒絶する同じようにメールをリレーするタスクを受け入れるか、または拒絶するかもしれません。 タスクを受け入れるなら、それは、次に、SMTPクライアントになって、DNS(セクション5の規則に従って)で指定された次のSMTPサーバーにトランスミッションチャンネルを確立して、メールをそれに送ります。 減退するなら、方針理由、550応答SHOULDのための特定のアドレスにメールをリレーするには、返してください。

   Many mail-sending clients exist, especially in conjunction with
   facilities that receive mail via POP3 or IMAP, that have limited
   capability to support some of the requirements of this specification,
   such as the ability to queue messages for subsequent delivery
   attempts.  For these clients, it is common practice to make private
   arrangements to send all messages to a single server for processing
   and subsequent distribution.  SMTP, as specified here, is not ideally
   suited for this role, and work is underway on standardized mail
   submission protocols that might eventually supercede the current
   practices.  In any event, because these arrangements are private and
   fall outside the scope of this specification, they are not described

多くのメールを送るクライアントが存在します、特にPOP3かIMAPを通してメールを受け取って、この仕様の要件のいくつかをサポートする能力を制限した施設に関連して、その後の配送試みへのメッセージを列に並ばせる能力などのように。 これらのクライアントにとって、処理とその後の分配のためのただ一つのサーバにすべてのメッセージを送るために秘密協定をするのは、一般的な習慣です。 ここで指定されるとして、SMTPは理想的にこの役割に合っていません、そして、仕事は標準化された結局電流が練習するsupercedeがそうするかもしれないメール服従プロトコルで進行中です。 とにかく、これらのアレンジメントが個人的であり、この仕様の範囲をそらせるので、それらはここで説明されません。

Klensin                     Standards Track                    [Page 24]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   It is important to note that MX records can point to SMTP servers
   which act as gateways into other environments, not just SMTP relays
   and final delivery systems; see sections 3.8 and 5.

MX記録がSMTPリレーと最終的な配送システムだけではなく、他の環境へのゲートウェイとしてどの行為をSMTPサーバーに向けることができるかに注意するのは重要です。 セクション3.8と5を見てください。

   If an SMTP server has accepted the task of relaying the mail and
   later finds that the destination is incorrect or that the mail cannot
   be delivered for some other reason, then it MUST construct an
   "undeliverable mail" notification message and send it to the
   originator of the undeliverable mail (as indicated by the reverse-
   path).  Formats specified for non-delivery reports by other standards
   (see, for example, [24, 25]) SHOULD be used if possible.

SMTPサーバーが、メールをリレーするタスクを受け入れて、後で目的地が不正確であるか、またはある他の理由でメールは提供できないのがわかるなら、それが、「「非-提出物」メール」通知メッセージを構成して、「非-提出物」メールの創始者にそれを送らなければなりません(逆経路によって示されるように)。 非配送に指定された形式は、他の規格(例えば、見ます[24、25])SHOULDでできれば、使用されるように報告します。

   This notification message must be from the SMTP server at the relay
   host or the host that first determines that delivery cannot be
   accomplished.  Of course, SMTP servers MUST NOT send notification
   messages about problems transporting notification messages.  One way
   to prevent loops in error reporting is to specify a null reverse-path
   in the MAIL command of a notification message.  When such a message
   is transmitted the reverse-path MUST be set to null (see section
   4.5.5 for additional discussion).  A MAIL command with a null
   reverse-path appears as follows:

この通知メッセージは最初に配送を実行できないと決心している中継ホストかホストでSMTPサーバーから来ているに違いありません。 もちろん、SMTPサーバーは通知メッセージを輸送することにおける問題に関する通知メッセージを送ってはいけません。 間違い輪が報告するのを防ぐ1つの方法は通知メッセージのメールコマンドにおける逆経路のヌルを指定することです。 そのようなメッセージが送られるとき、逆経路をヌルに設定しなければなりません(追加議論に関してセクション4.5.5を見てください)。 逆経路であることでのヌルメールコマンドは以下の通りに見えます:

      MAIL FROM:<>


   As discussed in section 2.4.1, a relay SMTP has no need to inspect or
   act upon the headers or body of the message data and MUST NOT do so
   except to add its own "Received:" header (section 4.4) and,
   optionally, to attempt to detect looping in the mail system (see
   section 6.2).

セクション2.4.1で議論するように、リレーSMTPはヘッダーかメッセージ欄データに点検するか、または作用する必要性を全く持たないで、加える以外に、そうそれ自身の「受け取るのであったこと」をしてはいけません。 ヘッダー(セクション4.4)と任意にメールシステム(セクション6.2を見る)にループを検出する試みるのに。

3.8 Mail Gatewaying

3.8 メールGatewaying

   While the relay function discussed above operates within the Internet
   SMTP transport service environment, MX records or various forms of
   explicit routing may require that an intermediate SMTP server perform
   a translation function between one transport service and another.  As
   discussed in section 2.3.8, when such a system is at the boundary
   between two transport service environments, we refer to it as a
   "gateway" or "gateway SMTP".

上で議論したリレー機能がインターネットSMTP輸送サービス環境の中で作動している間、MX記録か様々なフォームの明白なルーティングは、中間的SMTPサーバーが1つの輸送サービスと別のものの間の翻訳機能を実行するのを必要とするかもしれません。 そのようなシステムが2つの輸送サービス環境の間の境界にあるとき、セクション2.3.8で議論するように、私たちは「ゲートウェイ」か「ゲートウェイSMTP」とそれを呼びます。

   Gatewaying mail between different mail environments, such as
   different mail formats and protocols, is complex and does not easily
   yield to standardization.  However, some general requirements may be
   given for a gateway between the Internet and another mail

異なったメール書式やプロトコルなどの異なったメール環境の間のメールをGatewayingするのは複雑であり、容易に標準化に屈しません。 しかしながら、インターネットと別のメール環境の間でいくつかの一般的な要件をゲートウェイに与えるかもしれません。

Klensin                     Standards Track                    [Page 25]

RFC 2821             Simple Mail Transfer Protocol            April 2001


3.8.1 Header Fields in Gatewaying

3.8.1 Gatewayingのヘッダーフィールド

   Header fields MAY be rewritten when necessary as messages are
   gatewayed across mail environment boundaries.  This may involve
   inspecting the message body or interpreting the local-part of the
   destination address in spite of the prohibitions in section 2.4.1.

必要であるときに、メッセージがメール環境限界の向こう側にgatewayedされるとき、ヘッダーフィールドは書き直されるかもしれません。 これは、メッセージ本体を点検するか、禁止にもかかわらず、または送付先アドレスの地方の部分を解釈することをセクション2.4.1に伴うかもしれません。

   Other mail systems gatewayed to the Internet often use a subset of
   RFC 822 headers or provide similar functionality with a different
   syntax, but some of these mail systems do not have an equivalent to
   the SMTP envelope.  Therefore, when a message leaves the Internet
   environment, it may be necessary to fold the SMTP envelope
   information into the message header.  A possible solution would be to
   create new header fields to carry the envelope information (e.g.,
   "X-SMTP-MAIL:"  and "X-SMTP-RCPT:"); however, this would require
   changes in mail programs in foreign environments and might risk
   disclosure of private information (see section 7.2).

または、インターネットにgatewayedされた他のメールシステムがしばしばRFCの部分集合を使用する、822個のヘッダー、異なった構文を同様の機能性に提供しなさい、ただし、これらのいくつかのメールシステムはSMTP封筒に同等物を持っていません。 したがって、メッセージがインターネット環境を残すとき、SMTP封筒情報をメッセージヘッダーに折り重ねるのが必要であるかもしれません。 そして、可能なソリューションが封筒情報を運ぶために新しいヘッダーフィールドを作成するだろうことである、(例えば、「以下をX-SMTP郵送してください」、「X-SMTP-RCPT:」、)、。 しかしながら、これは、外国環境におけるメールプログラムに釣り銭がいて、個人情報の公開を危険にさらすかもしれません(セクション7.2を見てください)。

3.8.2 Received Lines in Gatewaying

3.8.2 Gatewayingの容認された線

   When forwarding a message into or out of the Internet environment, a
   gateway MUST prepend a Received: line, but it MUST NOT alter in any
   way a Received: line that is already in the header.

環境の中、または、インターネット環境からメッセージを転送するとき、ゲートウェイはReceivedをprependしなければなりません: 何らかの方法でReceivedを変更してはいけません: ヘッダーに既にある系列。

   "Received:" fields of messages originating from other environments
   may not conform exactly to this specification.  However, the most
   important use of Received: lines is for debugging mail faults, and
   this debugging can be severely hampered by well-meaning gateways that
   try to "fix" a Received: line.  As another consequence of trace
   fields arising in non-SMTP environments, receiving systems MUST NOT
   reject mail based on the format of a trace field and SHOULD be
   extremely robust in the light of unexpected information or formats in
   those fields.

「受け取りました」 他の環境から発するメッセージの分野はちょうどこの仕様に従わないかもしれません。 Receivedの最も重要な使用: 系列がデバッグメール障害によってあります、そして、Receivedを「修理しようとする」善意のゲートウェイは厳しくこのデバッグを妨げることができます: 立ち並んでください。 跡の別の結果が非SMTP環境における起こることをさばくので、システムを受け止めて、跡の分野の形式に基づく廃棄物メールとSHOULDは予期していなかった情報か形式の見地からそれらの分野で非常に強健であるはずがありませんか?

   The gateway SHOULD indicate the environment and protocol in the "via"
   clauses of Received field(s) that it supplies.


3.8.3 Addresses in Gatewaying

3.8.3 Gatewayingのアドレス

   From the Internet side, the gateway SHOULD accept all valid address
   formats in SMTP commands and in RFC 822 headers, and all valid RFC
   822 messages.  Addresses and headers generated by gateways MUST
   conform to applicable Internet standards (including this one and RFC
   822).  Gateways are, of course, subject to the same rules for
   handling source routes as those described for other SMTP systems in
   section 3.3.

インターネット側から、ゲートウェイSHOULDはRFCのSMTPコマンドにおけるすべての有効なアドレス形式、822個のヘッダー、およびすべての有効なRFC822メッセージを受け入れます。 ゲートウェイによって作られたアドレスとヘッダーは適切なインターネット標準に従わなければなりません(この1とRFC822を含んでいて)。 取り扱い送信元経路において、ゲートウェイはもちろんものが他のSMTPシステムのためにセクション3.3で説明したように同じ規則を受けることがあります。

Klensin                     Standards Track                    [Page 26]

RFC 2821             Simple Mail Transfer Protocol            April 2001


3.8.4 Other Header Fields in Gatewaying

3.8.4 Gatewayingの他のヘッダーフィールド

   The gateway MUST ensure that all header fields of a message that it
   forwards into the Internet mail environment meet the requirements for
   Internet mail.  In particular, all addresses in "From:", "To:",
   "Cc:", etc., fields MUST be transformed (if necessary) to satisfy RFC
   822 syntax, MUST reference only fully-qualified domain names, and
   MUST be effective and useful for sending replies.  The translation
   algorithm used to convert mail from the Internet protocols to another
   environment's protocol SHOULD ensure that error messages from the
   foreign mail environment are delivered to the return path from the
   SMTP envelope, not to the sender listed in the "From:" field (or
   other fields) of the RFC 822 message.

ゲートウェイは、それがインターネット・メール環境に転送するメッセージのすべてのヘッダーフィールドがインターネット・メールのために条件を満たすのを確実にしなければなりません。 特に「From:」、「To:」、「Cc:」などにおけるすべてのアドレス、分野は、送付回答に(必要なら、)RFC822構文を満たすために変えなければならなくて、完全修飾ドメイン名だけに参照をつけなければならなくて、有効であって、役に立つに違いありません。 インターネットプロトコルから別の環境のプロトコルSHOULDまでメールを変換するのに使用される変換アルゴリズムは、外国メール環境からのエラーメッセージが「From:」に記載された送付者から提供されるのではなく、SMTP封筒からリターンパスに提供されるのを確実にします。 RFC822メッセージの分野(または、他の分野)。

3.8.5 Envelopes in Gatewaying

3.8.5 Gatewayingの封筒

   Similarly, when forwarding a message from another environment into
   the Internet, the gateway SHOULD set the envelope return path in
   accordance with an error message return address, if supplied by the
   foreign environment.  If the foreign environment has no equivalent
   concept, the gateway must select and use a best approximation, with
   the message originator's address as the default of last resort.

メッセージを別の環境からインターネットに転送するとき、同様に、エラーメッセージ返送先によると、ゲートウェイSHOULDは封筒リターンパスを設定します、外国環境から供給するなら。 外国環境でどんな同等な概念もないなら、ゲートウェイは、最良近似を選択して、使用しなければなりません、切り札のデフォルトとしてのメッセージ創始者のアドレスで。

3.9 Terminating Sessions and Connections

3.9 セッションとコネクションズを終えること。

   An SMTP connection is terminated when the client sends a QUIT
   command.  The server responds with a positive reply code, after which
   it closes the connection.

クライアントがQUITコマンドを送ると、SMTP接続は終えられます。 サーバは積極的な返事コードで反応します。(その時、それは接続を終えました後)。

   An SMTP server MUST NOT intentionally close the connection except:


   -  After receiving a QUIT command and responding with a 221 reply.

- QUITコマンドを受け取って、221回答で応じた後に。

   -  After detecting the need to shut down the SMTP service and
      returning a 421 response code.  This response code can be issued
      after the server receives any command or, if necessary,
      asynchronously from command receipt (on the assumption that the
      client will receive it after the next command is issued).

- SMTPサービスを止める必要性を見つけて、421応答コードを返した後に。 または、サーバがどんなコマンドも受け取った後にこの応答コードを発行できる、必要ならと、非同期である、コマンド領収書(次のコマンドを発行した後にクライアントがそれを受けるという前提での)から。

   In particular, a server that closes connections in response to
   commands that are not understood is in violation of this
   specification.  Servers are expected to be tolerant of unknown
   commands, issuing a 500 reply and awaiting further instructions from
   the client.

特に、理解されていないコマンドに対応して接続を終えるサーバはこの仕様を違反しています。 500回答を発行して、クライアントからその後の支持を待って、サーバは未知のコマンドにおいて許容性があると予想されます。

Klensin                     Standards Track                    [Page 27]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   An SMTP server which is forcibly shut down via external means SHOULD
   attempt to send a line containing a 421 response code to the SMTP
   client before exiting.  The SMTP client will normally read the 421
   response code after sending its next command.

外部を通して強制的に止められるSMTPサーバーは、SHOULDが、出る前に421応答コードをSMTPクライアントに含む系列を送るのを試みることを意味します。 次のコマンドを送った後に、通常、SMTPクライアントは421応答コードを読むでしょう。

   SMTP clients that experience a connection close, reset, or other
   communications failure due to circumstances not under their control
   (in violation of the intent of this specification but sometimes
   unavoidable) SHOULD, to maintain the robustness of the mail system,
   treat the mail transaction as if a 451 response had been received and
   act accordingly.


3.10 Mailing Lists and Aliases

3.10 メーリングリストと別名

   An SMTP-capable host SHOULD support both the alias and the list
   models of address expansion for multiple delivery.  When a message is
   delivered or forwarded to each address of an expanded list form, the
   return address in the envelope ("MAIL FROM:") MUST be changed to be
   the address of a person or other entity who administers the list.
   However, in this case, the message header [32] MUST be left
   unchanged; in particular, the "From" field of the message header is

SHOULDが別名と多重配信のためのアドレス拡張のリストモデルの両方をサポートするSMTP有能なホスト。 拡張リストフォームの各アドレスにメッセージを提供するか、または転送するとき、リストを管理する人か他の実体のアドレスになるように封筒(「メールFROM:」)の返送先を変えなければなりません。 しかしながら、この場合、メッセージヘッダー[32]を変わりがないままにしなければなりません。 メッセージヘッダーの“From"分野は特に、影響を受けないです。

   An important mail facility is a mechanism for multi-destination
   delivery of a single message, by transforming (or "expanding" or
   "exploding") a pseudo-mailbox address into a list of destination
   mailbox addresses.  When a message is sent to such a pseudo-mailbox
   (sometimes called an "exploder"), copies are forwarded or
   redistributed to each mailbox in the expanded list.  Servers SHOULD
   simply utilize the addresses on the list; application of heuristics
   or other matching rules to eliminate some addresses, such as that of
   the originator, is strongly discouraged.  We classify such a pseudo-
   mailbox as an "alias" or a "list", depending upon the expansion

重要な郵便施設はただ一つのメッセージのマルチの目的地配送のためのメカニズムです、疑似メールボックスアドレスをあて先メールボックスアドレスのリストに変えることによって(または、「広げる」か「爆発」)。 そのような疑似メールボックス(時々「発破器」と呼ばれる)にメッセージを送るとき、拡張リストの各メールボックスにコピーを送るか、または再配付します。 サーバSHOULDはリストで単にアドレスを利用します。 創始者のものなどのように、何らかのいくつかのアドレスを排除するために規則に合っている発見的教授法の適用は強くお勧めできないです。 拡張規則によって、私たちは「別名」や「リスト」のような疑似メールボックスを分類します。

3.10.1 Alias

3.10.1 通称

   To expand an alias, the recipient mailer simply replaces the pseudo-
   mailbox address in the envelope with each of the expanded addresses
   in turn; the rest of the envelope and the message body are left
   unchanged.  The message is then delivered or forwarded to each
   expanded address.

別名を広げるために、受取人郵送者は単に封筒の広げるのがあるそれぞれについてアドレスが順番に扱う疑似メールボックスを取り替えます。 封筒の残りとメッセージ本体は変わりがないままにされます。 各拡張アドレスにメッセージを次に、提供するか、または転送します。

3.10.2 List

3.10.2 リスト

   A mailing list may be said to operate by "redistribution" rather than
   by "forwarding".  To expand a list, the recipient mailer replaces the
   pseudo-mailbox address in the envelope with all of the expanded

メーリングリストは「推進」でというよりむしろ「再分配」で作動すると言われているかもしれません。 リストを広げるために、受取人郵送者は封筒で疑似メールボックスアドレスを広げることのすべてに置き換えます。

Klensin                     Standards Track                    [Page 28]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   addresses.  The return address in the envelope is changed so that all
   error messages generated by the final deliveries will be returned to
   a list administrator, not to the message originator, who generally
   has no control over the contents of the list and will typically find
   error messages annoying.

アドレス。 一般に、リストのコンテンツを管理しないで、エラーメッセージが煩わしいのが通常わかるメッセージ創始者ではなく、リスト管理者に最終的な配送で生成されたすべてのエラーメッセージを返すように封筒の返送先を変えます。

4. The SMTP Specifications

4. SMTP仕様

4.1 SMTP Commands

4.1 SMTPコマンド

4.1.1 Command Semantics and Syntax

4.1.1 コマンド意味論と構文

   The SMTP commands define the mail transfer or the mail system
   function requested by the user.  SMTP commands are character strings
   terminated by <CRLF>.  The commands themselves are alphabetic
   characters terminated by <SP> if parameters follow and <CRLF>
   otherwise.  (In the interest of improved interoperability, SMTP
   receivers are encouraged to tolerate trailing white space before the
   terminating <CRLF>.)  The syntax of the local part of a mailbox must
   conform to receiver site conventions and the syntax specified in
   section 4.1.2.  The SMTP commands are discussed below.  The SMTP
   replies are discussed in section 4.2.

SMTPコマンドはユーザによって要求された郵便為替かメールシステム機能を定義します。 SMTPコマンドは<CRLF>によって終えられた文字列です。 そうでなければ、コマンド自体は、パラメタが従うなら<SP>によって終えられた英字と<CRLF>です。 (改良された相互運用性のために、SMTP受信機が、終わっている<CRLF>の前に余白を引きずるのを許容するよう奨励されます。) メールボックスの地方の部分の構文はセクション4.1.2で指定された受信機サイトコンベンションと構文に従わなければなりません。 以下でSMTPコマンドについて議論します。 セクション4.2でSMTP回答について議論します。

   A mail transaction involves several data objects which are
   communicated as arguments to different commands.  The reverse-path is
   the argument of the MAIL command, the forward-path is the argument of
   the RCPT command, and the mail data is the argument of the DATA
   command.  These arguments or data objects must be transmitted and
   held pending the confirmation communicated by the end of mail data
   indication which finalizes the transaction.  The model for this is
   that distinct buffers are provided to hold the types of data objects,
   that is, there is a reverse-path buffer, a forward-path buffer, and a
   mail data buffer.  Specific commands cause information to be appended
   to a specific buffer, or cause one or more buffers to be cleared.

メールトランザクションは議論として異なったコマンドに伝えられる数個のデータ・オブジェクトにかかわります。 逆経路はメールコマンドの議論です、そして、フォワードパスはRCPTコマンドの議論です、そして、メールデータはDATAコマンドの議論です。 トランザクションを成立させるメールデータ指示の終わりまでに伝えられた確認までこれらの議論かデータ・オブジェクトを伝えられて、持たなければなりません。 これのためのモデルがデータ・オブジェクトのタイプを保持するために異なったバッファを提供するということである、すなわち、逆経路バッファ、フォワードパスバッファ、およびメールデータバッファがあります。 特定のコマンドで、クリアされるために特定のバッファ、またはより多くの原因1バッファに情報を追加します。

   Several commands (RSET, DATA, QUIT) are specified as not permitting
   parameters.  In the absence of specific extensions offered by the
   server and accepted by the client, clients MUST NOT send such
   parameters and servers SHOULD reject commands containing them as
   having invalid syntax.

いくつかのコマンド(RSET、DATA、QUIT)はどんな可能にするパラメタとしても指定されません。 サーバによって提供されて、クライアントによって受け入れられた特定の拡大がないときクライアントがそのようなパラメタとサーバを送ってはいけないので、SHOULDは無効の構文を持っているとしてそれらを含むコマンドを拒絶します。  Extended HELLO (EHLO) or HELLO (HELO)

こんにちは、(EHLO)か4.1.1.1 広げられて、こんにちは(HELO)

   These commands are used to identify the SMTP client to the SMTP
   server.  The argument field contains the fully-qualified domain name
   of the SMTP client if one is available.  In situations in which the
   SMTP client system does not have a meaningful domain name (e.g., when
   its address is dynamically allocated and no reverse mapping record is

これらのコマンドは、SMTPクライアントをSMTPサーバーに特定するのに使用されます。1つが利用可能であるなら、議論分野はSMTPクライアントの完全修飾ドメイン名を含んでいます。 SMTPクライアントシステムが重要なドメイン名を持っていない状況、(例えば、ダイナミックにアドレスを割り当てて、どんな逆のマッピング記録も割り当てません。

Klensin                     Standards Track                    [Page 29]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   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


   A client SMTP SHOULD start an SMTP session by issuing the EHLO
   command.  If the SMTP server supports the SMTP service extensions it
   will give a successful response, a failure response, or an error
   response.  If the SMTP server, in violation of this specification,
   does not support any SMTP service extensions it will generate an
   error response.  Older client SMTP systems MAY, as discussed above,
   use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
   support the HELO command and reply properly to it.  In any event, a
   client MUST issue HELO or EHLO before starting a mail transaction.

クライアントSMTP SHOULDは、EHLOコマンドを発行することによって、SMTPセッションを始めます。 SMTPサーバーがSMTPをサポートするなら、それがうまくいっている応答、失敗応答、または誤り応答を与える拡大を修理してください。 SMTPサーバーが、この仕様を違反してどんなSMTPサービスも拡大であるとサポートしないと、それは誤り応答を生成するでしょう。 より古いクライアントSMTPシステムがEHLOの代わりに上で議論するようにHELOを使用するかもしれなくて(RFC821で指定されるように)、サーバは、HELOがコマンドであるとサポートして、適切にそれに答えなければなりません。 とにかく、メールトランザクションを始める前に、クライアントはHELOかEHLOを発行しなければなりません。

   These commands, and a "250 OK" reply to one of them, confirm that
   both the SMTP client and the SMTP server are in the initial state,
   that is, there is no transaction in progress and all state tables and
   buffers are cleared.




      ehlo            = "EHLO" SP Domain CRLF
      helo            = "HELO" SP Domain CRLF

"EHLO"SPドメインehlo=CRLF heloは"HELO"SPドメインCRLFと等しいです。

   Normally, the response to EHLO will be a multiline reply.  Each line
   of the response contains a keyword and, optionally, one or more
   parameters.  Following the normal syntax for multiline replies, these
   keyworks follow the code (250) and a hyphen for all but the last
   line, and the code and a space for the last line.  The syntax for a
   positive response, using the ABNF notation and terminal symbols of
   [8], is:

通常、EHLOへの応答はマルチライン回答になるでしょう。 応答の各系列はキーワードと任意に1つ以上のパラメタを含んでいます。 マルチライン回答のための正常な構文に従って、これらのkeyworksは最終ライン以外のすべてのためにコード(250)とハイフンに従って、コードとスペースに最終ラインに従います。 積極的な応答のための構文([8]のABNF記法を使用して、終端記号)は、以下の通りです。

      ehlo-ok-rsp  =    ( "250"    domain [ SP ehlo-greet ] CRLF )
                   / (    "250-"   domain [ SP ehlo-greet ] CRLF
                       *( "250-"   ehlo-line                CRLF )
                          "250"    SP ehlo-line             CRLF  )

ehloの間違いないrspは/と等しいです(「250」ドメイン[SP ehlo挨拶する]CRLF)。(「250」ドメイン[SP ehlo挨拶する]CRLF*(「250」ehlo-系列CRLF)「250」SP ehlo-系列CRLF)

      ehlo-greet   = 1*(%d0-9 / %d11-12 / %d14-127)
                   ; string of any characters other than CR or LF

=1*(%d0-9/%d11-12/%d14-127)にehlo挨拶してください。 CRかLF以外のどんなキャラクタのストリング

      ehlo-line    = ehlo-keyword *( SP ehlo-param )

ehlo-系列=ehlo-キーワード*(SP ehlo-param)

      ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
                   ; additional syntax of ehlo-params depends on
                   ; ehlo-keyword

ehlo-キーワード=(アルファー/DIGIT)*(ALPHA / DIGIT /「-」)。 ehlo-paramsの追加構文がよる、。 ehlo-キーワード

Klensin                     Standards Track                    [Page 30]

RFC 2821             Simple Mail Transfer Protocol            April 2001


      ehlo-param   = 1*(%d33-127)
                   ; any CHAR excluding <SP> and all
                   ; control characters (US-ASCII 0-31 inclusive)

ehlo-param=1*(%d33-127)。 <SP>を除いたどんなCHARとすべて。 制御文字(米国-ASCII0-31包括的)です。

   Although EHLO keywords may be specified in upper, lower, or mixed
   case, they MUST always be recognized and processed in a case-
   insensitive manner.  This is simply an extension of practices
   specified in RFC 821 and section 2.4.1.

EHLOキーワードは上側の、または、下側の、または、複雑な場合で指定されるかもしれませんが、ケースの神経の鈍い方法でそれらをいつも認識されて、処理しなければなりません。 これは単にRFC821とセクション2.4.1で指定された習慣の拡大です。 MAIL (MAIL) メール(メール)

   This command is used to initiate a mail transaction in which the mail
   data is delivered to an SMTP server which may, in turn, deliver it to
   one or more mailboxes or pass it on to another system (possibly using
   SMTP).  The argument field contains a reverse-path and may contain
   optional parameters.  In general, the MAIL command may be sent only
   when no mail transaction is in progress, see section 4.1.4.

このコマンドは、メールデータが順番に1個以上のメールボックスにそれを提供するか、または別のシステムにそれを通過するかもしれないSMTPサーバーに提供されるメールトランザクションを開始するのに使用されます(ことによるとSMTPを使用して)。 議論分野は、逆経路を含んでいて、任意のパラメタを含むかもしれません。 セクション4.1.4は、メールトランザクションが全く進行していないときだけ、一般に、メールコマンドが送られるかもしれないのを見ます。

   The reverse-path consists of the sender mailbox.  Historically, that
   mailbox might optionally have been preceded by a list of hosts, but
   that behavior is now deprecated (see appendix C).  In some types of
   reporting messages for which a reply is likely to cause a mail loop
   (for example, mail delivery and nondelivery notifications), the
   reverse-path may be null (see section 3.7).

逆経路は送付者メールボックスから成ります。 歴史的に、ホストのリストは任意にそのメールボックスに先行したかもしれませんが、その振舞いは現在、推奨しないです(付録Cを見てください)。 中では、回答がaメールを引き起こしそうであるメッセージを報告する何人かのタイプが輪にする、(例えば、郵便配達と不着損害通知)、逆経路はヌルであるかもしれません(セクション3.7を見てください)。

   This command clears the reverse-path buffer, the forward-path buffer,
   and the mail data buffer; and inserts the reverse-path information
   from this command into the reverse-path buffer.

このコマンドは逆経路バッファ、フォワードパスバッファ、およびメールデータバッファをきれいにします。 そして、逆経路へのこのコマンドからの逆経路情報がバッファリングする差し込み。

   If service extensions were negotiated, the MAIL command may also
   carry parameters associated with a particular service extension.




      "MAIL FROM:" ("<>" / Reverse-Path)
                       [SP Mail-parameters] CRLF

「メールFROM:」 (逆「<>」/経路) [SPメールパラメタ] CRLF RECIPIENT (RCPT) 受取人(RCPT)

   This command is used to identify an individual recipient of the mail
   data; multiple recipients are specified by multiple use of this
   command.  The argument field contains a forward-path and may contain
   optional parameters.

このコマンドはメールデータの個々の受取人を特定するのに使用されます。 複数の受取人はこのコマンドの複数の使用で指定されます。 議論分野は、フォワードパスを含んでいて、任意のパラメタを含むかもしれません。

   The forward-path normally consists of the required destination
   mailbox.  Sending systems SHOULD not generate the optional list of
   hosts known as a source route.  Receiving systems MUST recognize

通常、フォワードパスは必要なあて先メールボックスから成ります。 送付システムSHOULDは送信元経路として知られているホストの任意のリストを生成しません。 システムが認識しなければならない受信

Klensin                     Standards Track                    [Page 31]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   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.

同様に、中継ホストSHOULDは送信元経路を剥取るか、または無視します、そして、名前は逆経路にコピーされてはいけません。 メールが最終仕向地に達すると(フォワードパスはあて先メールボックスだけを含んでいます)、ホストメールコンベンションによると、SMTPサーバーはあて先メールボックスの中にそれを挿入します。

   For example, mail received at relay host xyz.com with envelope


      MAIL FROM:<userx@y.foo.org>
      RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>

FROM:<userx@y.foo.org に郵送してください、gt;、@jkl.org: RCPT TO:<@hosta.int 、 userc@d.bar.org 、gt。

   will normally be sent directly on to host d.bar.org with envelope


      MAIL FROM:<userx@y.foo.org>
      RCPT TO:<userc@d.bar.org>

FROM:<userx@y.foo.org に郵送してください、gt;、RCPT TO:<userc@d.bar.org 、gt。

   As provided in appendix C, xyz.com MAY also choose to relay the
   message to hosta.int, using the envelope commands


      MAIL FROM:<userx@y.foo.org>
      RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>

FROM:<userx@y.foo.org に郵送してください、gt;、@jkl.org: RCPT TO:<@hosta.int 、 userc@d.bar.org 、gt。

   or to jkl.org, using the envelope commands


      MAIL FROM:<userx@y.foo.org>
      RCPT TO:<@jkl.org:userc@d.bar.org>

FROM:<userx@y.foo.org に郵送してください、gt;、RCPT TO:<@jkl.org : userc@d.bar.org>。

   Of course, since hosts are not required to relay mail at all, xyz.com
   may also reject the message entirely when the RCPT command is
   received, using a 550 code (since this is a "policy reason").


   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 TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path)
                    [SP Rcpt-parameters] CRLF

構文: 「RCPT TO:」 (「<郵便局長@」ドメイン">"/「<郵便局長>」/フォワードパス) [SP Rcpt-パラメタ] CRLF

Klensin                     Standards Track                    [Page 32]

RFC 2821             Simple Mail Transfer Protocol            April 2001

メール転送プロトコル2001年4月に簡単なKlensin標準化過程[32ページ]RFC2821 DATA (DATA) データ(データ)

   The receiver normally sends a 354 response to DATA, and then treats
   the lines (strings ending in <CRLF> sequences, as described in
   section 2.3.7) following the command as mail data from the sender.
   This command causes the mail data to be appended to the mail data
   buffer.  The mail data may contain any of the 128 ASCII character
   codes, although experience has indicated that use of control
   characters other than SP, HT, CR, and LF may cause problems and
   SHOULD be avoided when possible.

受信機は、通常、354応答をDATAに送って、メールデータとしてコマンドに続いて、次に、送付者から系列(セクション2.3.7で説明されるように<CRLF>系列に終わるストリング)を扱います。 このコマンドで、メールデータバッファにメールデータを追加します。 メールデータは128のASCII文字コードのどれかを含むかもしれなくて、経験は、SP、HT、CR、およびLF以外の制御文字の使用が問題とSHOULDを引き起こすかもしれないのを示しましたが、可能であるときには避けられてください。

   The mail data is terminated by a line containing only a period, that
   is, the character sequence "<CRLF>.<CRLF>" (see section 4.5.2).  This
   is the end of mail data indication.  Note that the first <CRLF> of
   this terminating sequence is also the <CRLF> that ends the final line
   of the data (message text) or, if there was no data, ends the DATA
   command itself.  An extra <CRLF> MUST NOT be added, as that would
   cause an empty line to be added to the message.  The only exception
   to this rule would arise if the message body were passed to the
   originating SMTP-sender with a final "line" that did not end in
   <CRLF>; in that case, the originating SMTP system MUST either reject
   the message as invalid or add <CRLF> in order to have the receiving
   SMTP server recognize the "end of data" condition.

メールデータはすなわち、期間だけを含む系列、キャラクタシーケンス「<CRLF><CRLF>」によって終えられます(セクション4.5.2を見てください)。 これはメールデータ指示の終わりです。 また、系列を終えるこの最初の<CRLF>がデータ(メッセージ・テキスト)の最終的な系列を終わらせるか、またはデータが全くなかったならDATAコマンド自体を終わらせる<CRLF>であることに注意してください。 CRLF>がそうしなければならない付加的な<が加えられないで、それが引き起こすように空の系列がメッセージに追加されることを引き起こしてください。 メッセージ本体が<CRLF>に終わらなかった最終的な「系列」で起因しているSMTP-送付者に渡されるなら、この規則への唯一の例外が起こるでしょうに。 その場合、受信SMTPサーバーに「データの終わり」状態を認識させるように、起因しているSMTPシステムは、メッセージが無効であると拒絶しなければならないか、または<CRLF>を言い足さなければなりません。

   The custom of accepting lines ending only in <LF>, as a concession to
   non-conforming behavior on the part of some UNIX systems, has proven
   to cause more interoperability problems than it solves, and SMTP
   server systems MUST NOT do this, even in the name of improved
   robustness.  In particular, the sequence "<LF>.<LF>" (bare line
   feeds, without carriage returns) MUST NOT be treated as equivalent to
   <CRLF>.<CRLF> as the end of mail data indication.

いくつかのUNIXシステム側の譲歩として<LF>だけに終わる系列を非の従うことの振舞いに認める習慣は解決するより多くの相互運用性問題を引き起こすと判明しました、そして、SMTPサーバーシステムはこれをしてはいけません、改良された丈夫さの名にかけてさえ。 特に、メールデータ指示の終わりとして系列「<LF><LF>」(復帰のないむき出しの改行)を<CRLF><CRLF>と同等物として扱ってはいけません。

   Receipt of the end of mail data indication requires the server to
   process the stored mail transaction information.  This processing
   consumes the information in the reverse-path buffer, the forward-path
   buffer, and the mail data buffer, and on the completion of this
   command these buffers are cleared.  If the processing is successful,
   the receiver MUST send an OK reply.  If the processing fails the
   receiver MUST send a failure reply.  The SMTP model does not allow
   for partial failures at this point: either the message is accepted by
   the server for delivery and a positive response is returned or it is
   not accepted and a failure reply is returned.  In sending a positive
   completion reply to the end of data indication, the receiver takes
   full responsibility for the message (see section 6.1).  Errors that
   are diagnosed subsequently MUST be reported in a mail message, as
   discussed in section 4.4.

メールデータ指示の終わりの領収書は、保存されたメールトランザクション情報を処理するためにサーバを必要とします。 この処理は逆経路バッファ、フォワードパスバッファ、およびメールデータバッファの情報を消費します、そして、このコマンドの完成のときに、これらのバッファはきれいにされます。 処理がうまくいくなら、受信機はOK回答を送らなければなりません。 処理が失敗するなら、受信機は失敗回答を送らなければなりません。 SMTPモデルはここに部分的な失敗を考慮しません: 配送のためのサーバでメッセージを受け入れます、そして、それを受け入れません、そして、積極的な応答を返すか、または失敗回答を返します。 積極的な完成回答をデータ指示の終わりに送る際に、受信機はメッセージへの完全な責任を取ります(セクション6.1を見てください)。 セクション4.4で議論するような次に診断されて、メール・メッセージで報告しなければならないということである誤り。

Klensin                     Standards Track                    [Page 33]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   When the SMTP server accepts a message either for relaying or for
   final delivery, it inserts a trace record (also referred to
   interchangeably as a "time stamp line" or "Received" line) at the top
   of the mail data.  This trace record indicates the identity of the
   host that sent the message, the identity of the host that received
   the message (and is inserting this time stamp), and the date and time
   the message was received.  Relayed messages will have multiple time
   stamp lines.  Details for formation of these lines, including their
   syntax, is specified in section 4.4.

SMTPサーバーがリレーか最終的な配送へのメッセージを受け入れるとき、それはメールデータの先端で跡の記録(また、「タイムスタンプ系列」か「受け取られていている」系列に互換性を持って言及される)を挿入します。 この跡の記録は、メッセージ、メッセージ(これを挿入するのは、タイムスタンプである)を受け取ったホストのアイデンティティ、および日時にメッセージを送ったホストのアイデンティティが受け取られたのを示します。 リレーされたメッセージには、複数のタイムスタンプ系列があるでしょう。 それらの構文を含むこれらの系列の構成のための詳細はセクション4.4で指定されます。

   Additional discussion about the operation of the DATA command appears
   in section 3.3.


      "DATA" CRLF

構文: 「データ」CRLF RESET (RSET) リセット(RSET)

   This command specifies that the current mail transaction will be
   aborted.  Any stored sender, recipients, and mail data MUST be
   discarded, and all buffers and state tables cleared.  The receiver
   MUST send a "250 OK" reply to a RSET command with no arguments.  A
   reset command may be issued by the client at any time.  It is
   effectively equivalent to a NOOP (i.e., if has no effect) if issued
   immediately after EHLO, before EHLO is issued in the session, after
   an end-of-data indicator has been sent and acknowledged, or
   immediately before a QUIT.  An SMTP server MUST NOT close the
   connection as the result of receiving a RSET; that action is reserved
   for QUIT (see section

このコマンドは、現在のメールトランザクションが中止されると指定します。 どんな保存された送付者、受取人、およびメールデータも捨てなければなりませんでした、そして、すべてのバッファとステートテーブルはきれいにされました。 受信機は議論なしで「250OK」回答をRSETコマンドに送らなければなりません。 リセットコマンドはいつでも、クライアントによって発行されるかもしれません。 すなわち、事実上、それがNOOPに同等である、(効果がありません) EHLO直後発行されるなら、以前、EHLOはセッション、データのエンドインディケータが送られて、承認された後またはQUITの直前発行されます。 SMTPサーバーはRSETを受けるという結果として接続を終えてはいけません。 セクション4.1を見てください。その動作がQUITのために控えられる、(.1 .10)。

   Since EHLO implies some additional processing and response by the
   server, RSET will normally be more efficient than reissuing that
   command, even though the formal semantics are the same.


   There are circumstances, contrary to the intent of this
   specification, in which an SMTP server may receive an indication that
   the underlying TCP connection has been closed or reset.  To preserve
   the robustness of the mail system, SMTP servers SHOULD be prepared
   for this condition and SHOULD treat it as if a QUIT had been received
   before the connection disappeared.

事情があります、この仕様の意図とは逆に。そこでは、SMTPサーバーが基本的なTCP接続が閉店するか、またはリセットされたという指示を受けるかもしれません。 メールシステム、SMTPプロトコルのサーバSHOULDの丈夫さを保存するために、この状態のために用意してください。そうすれば、SHOULDはまるで接続が姿を消す前にQUITを受け取ったかのようにそれを扱います。

      "RSET" CRLF


Klensin                     Standards Track                    [Page 34]

RFC 2821             Simple Mail Transfer Protocol            April 2001

メール転送プロトコル2001年4月に簡単なKlensin標準化過程[34ページ]RFC2821 VERIFY (VRFY)、検証(VRFY)

   This command asks the receiver to confirm that the argument
   identifies a user or mailbox.  If it is a user name, information is
   returned as specified in section 3.5.

このコマンドは、議論がユーザかメールボックスを特定すると確認するように受信機に頼みます。 それがユーザ名であるなら、セクション3.5で指定されるように情報を返します。

   This command has no effect on the reverse-path buffer, the forward-
   path buffer, or the mail data buffer.


      "VRFY" SP String CRLF

構文: "VRFY"SPストリングCRLF EXPAND (EXPN) 広がってください。(EXPN)

   This command asks the receiver to confirm that the argument
   identifies a mailing list, and if so, to return the membership of
   that list.  If the command is successful, a reply is returned
   containing information as described in section 3.5.  This reply will
   have multiple lines except in the trivial case of a one-member list.

このコマンドは、議論がメーリングリストを特定すると確認して、そうだとすれば、そのリストの会員資格を返すように受信機に頼みます。 コマンドがうまくいくなら、セクション3.5で説明されるように情報を含んでいて、回答を返します。 この回答には、1メンバーのリストの些細なケース以外の複数の系列があるでしょう。

   This command has no effect on the reverse-path buffer, the forward-
   path buffer, or the mail data buffer and may be issued at any time.


      "EXPN" SP String CRLF

構文: "EXPN"SPストリングCRLF HELP (HELP) ヘルプ(助け)

   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.


      "HELP" [ SP String ] CRLF

構文: 「助け」[SPストリング]CRLF NOOP (NOOP) NOOP(NOOP)

   This command does not affect any parameters or previously entered
   commands.  It specifies no action other than that the receiver send
   an OK reply.

このコマンドは少しのパラメタや以前に入力されたコマンドにも影響しません。 受信機がOK回答を送る以外に、それは動作を全く指定しません。

Klensin                     Standards Track                    [Page 35]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   This command has no effect on the reverse-path buffer, the forward-
   path buffer, or the mail data buffer and may be issued at any time.
   If a parameter string is specified, servers SHOULD ignore it.

このコマンドは逆経路バッファ、前進の経路バッファ、またはメールデータバッファの上で効き目がなくて、いつでも、発行するかもしれません。 パラメタストリングが指定されるなら、サーバSHOULDはそれを無視します。

      "NOOP" [ SP String ] CRLF

構文: "NOOP"[SPストリング]CRLF QUIT (QUIT) やめてください。(やめます)

   This command specifies that the receiver MUST send an OK reply, and
   then close the transmission channel.


   The receiver MUST NOT intentionally close the transmission channel
   until it receives and replies to a QUIT command (even if there was an
   error).  The sender MUST NOT intentionally close the transmission
   channel until it sends a QUIT command and SHOULD wait until it
   receives the reply (even if there was an error response to a previous
   command).  If the connection is closed prematurely due to violations
   of the above or system or network failure, the server MUST cancel any
   pending transaction, but not undo any previously completed
   transaction, and generally MUST act as if the command or transaction
   in progress had received a temporary error (i.e., a 4yz response).

受信機は故意にQUITコマンドに受けて、答えるまで(誤りがあったとしても)トランスミッションチャンネルを閉じてはいけません。 QUITコマンドを送って、回答を受け取るまで(前のコマンドへの誤り応答があったとしても)SHOULDが待つまで、送付者は故意にトランスミッションチャンネルを閉じてはいけません。 接続が早まって、違反のため上記で閉じられるか、そして、システムかネットワーク失敗、サーバがどんな未定のトランザクションも取り消さなければなりません、どんな以前に完成したトランザクションも元に戻さないで、まるで進行中のコマンドかトランザクションが一時的な誤り(すなわち、4yz応答)を受けたかのように一般に、行動しなければならないのを除いて。

   The QUIT command may be issued at any time.


      "QUIT" CRLF

構文: 「やめてください」CRLF

4.1.2 Command Argument Syntax

4.1.2 コマンド議論構文

   The syntax of the argument fields of the above commands (using the
   syntax specified in [8] where applicable) is given below.  Some of
   the productions given below are used only in conjunction with source
   routes as described in appendix C.  Terminals not defined in this
   document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in
   the "core" syntax [8 (section 6)] or in the message format syntax

上のコマンド(適切であるところで[8]で指定された構文を使用する)の議論分野の構文を以下に与えます。 以下に与えられた創作のいくつかが付録C.で説明されるように送信元経路に関連してだけ使用されます。アルファーなどのように本書では定義されなかったTerminals、DIGIT、SP、CR、LF(CRLF)が「コア」構文[8(セクション6)]で定義されるか、メッセージ・フォーマット構文[32]であります。

      Reverse-path = Path
      Forward-path = Path
      Path = "<" [ A-d-l ":" ] Mailbox ">"
      A-d-l = At-domain *( "," A-d-l )
            ; Note that this form, the so-called "source route",
            ; MUST BE accepted, SHOULD NOT be generated, and SHOULD be
            ; ignored.
      At-domain = "@" domain
      Mail-parameters = esmtp-param *(SP esmtp-param)
      Rcpt-parameters = esmtp-param *(SP esmtp-param)

「逆経路=経路経路フォワードパス=経路="<"、[d l」、:、」、]、メールボックス">"d lがドメインの*と等しい、(「」 d l)、。 このフォーム、そのいわゆる「送信元経路」に注意してください。 SHOULD NOT、受け入れなければならない、生成されてください、SHOULD、いてください。 無視にされる。 ドメインの="@"ドメインメールパラメタはesmtp-param*(SP esmtp-param)Rcpt-パラメタ=esmtp-param*と等しいです。(SP esmtp-param)

Klensin                     Standards Track                    [Page 36]

RFC 2821             Simple Mail Transfer Protocol            April 2001


      esmtp-param     = esmtp-keyword ["=" esmtp-value]
      esmtp-keyword   = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
      esmtp-value     = 1*(%d33-60 / %d62-127)
            ; any CHAR excluding "=", SP, and control characters
      Keyword  = Ldh-str
      Argument = Atom
      Domain = (sub-domain 1*("." sub-domain)) / address-literal
      sub-domain = Let-dig [Ldh-str]

esmtp-paramはesmtp-キーワード[esmtp-値と「等しい」]esmtp-キーワード=(アルファー/ケタ)*(アルファ/ケタ/「-」)esmtp-値=1*(%d33-60/%d62-127)と等しいです。 原子「=」を除いたどんなCHAR、SP、および制御文字キーワード=Ldh-str議論も=ドメインが等しい、(サブドメイン1*、(「. 」 サブドメイン) /アドレスリテラルサブドメイン=、皮肉をさせます。[Ldh-str]

      address-literal = "[" IPv4-address-literal /
                            IPv6-address-literal /
                            General-address-literal "]"
            ; See section 4.1.3

「[「一般アドレスIPv6アドレスIPv4アドレスリテラル/リテラル/リテラル」]」というアドレスリテラル=。 セクション4.1.3を見てください。

      Mailbox = Local-part "@" Domain


      Local-part = Dot-string / Quoted-string
            ; MAY be case-sensitive

地方の部分はドットストリング/引用文字列と等しいです。 大文字と小文字を区別しているかもしれません。

      Dot-string = Atom *("." Atom)

ドットストリング=原子*(「. 」 原子、)

      Atom = 1*atext


      Quoted-string = DQUOTE *qcontent DQUOTE

引用文字列=DQUOTE*qcontent DQUOTE

      String = Atom / Quoted-string


   While the above definition for Local-part is relatively permissive,
   for maximum interoperability, a host that expects to receive mail
   SHOULD avoid defining mailboxes where the Local-part requires (or
   uses) the Quoted-string form or where the Local-part is case-
   sensitive.  For any purposes that require generating or comparing
   Local-parts (e.g., to specific mailbox names), all quoted forms MUST
   be treated as equivalent and the sending system SHOULD transmit the
   form that uses the minimum quoting possible.

Local-部分のための上の定義が比較的寛大である間、最大限のインターオペラビリティ、受信すると予想するホストに関して、メールSHOULDは、Local-部分がQuoted-ストリングフォームを必要とするか、またはLocal-部分がケース敏感である(または、用途)メールボックスを定義するのを避けます。 Local-部品(例えば、特定のメールボックス名への)を生成するか、または比較するのを必要とするどんな目的のためにも、すべてが、同等物としてフォームを扱わなければならないのを引用しました、そして、送付システムSHOULDは可能な最小の引用を使用する書式を伝えます。

   Systems MUST NOT define mailboxes in such a way as to require the use
   in SMTP of non-ASCII characters (octets with the high order bit set
   to one) or ASCII "control characters" (decimal value 0-31 and 127).
   These characters MUST NOT be used in MAIL or RCPT commands or other
   commands that require mailbox names.

システムはメールボックスを非ASCII文字(高位のビットによる八重奏は1つにセットしました)かASCII「制御文字」(デシマル値0-31と127)のSMTPにおける使用を必要とするほどそのような方法で定義してはいけません。 メールボックス名を必要とするメール、RCPTコマンドまたは他のコマンドにこれらのキャラクタを使用してはいけません。

   Note that the backslash, "\", is a quote character, which is used to
   indicate that the next character is to be used literally (instead of
   its normal interpretation).  For example, "Joe\,Smith" indicates a
   single nine character user field with the comma being the fourth
   character of the field.

「\」というバックスラッシュが引用文字であることに注意してください。(その引用文字は、次のキャラクタが文字通り(通常の解釈の代わりに)使用されることになっているのを示すのに使用されます)。 例えば、「ジョー\、スミス」は分野の4番目のキャラクタであるコンマでただ一つの9キャラクタユーザ分野を示します。

Klensin                     Standards Track                    [Page 37]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   To promote interoperability and consistent with long-standing
   guidance about conservative use of the DNS in naming and applications
   (e.g., see section 2.3.1 of the base DNS document, RFC1035 [22]),
   characters outside the set of alphas, digits, and hyphen MUST NOT
   appear in domain name labels for SMTP clients or servers.  In
   particular, the underscore character is not permitted.  SMTP servers
   that receive a command in which invalid character codes have been
   employed, and for which there are no other reasons for rejection,
   MUST reject that command with a 501 response.

促進する、相互運用性で長年の指導と命名とアプリケーションにおけるDNSの保守的な使用に関して一致する、(例えば、ベースDNSドキュメント、RFC1035[22])、アルファのセットの外におけるキャラクタ、ケタ、および.1のセクション2.3ハイフンがドメイン名ラベルにSMTPクライアントかサーバに関して現れてはいけないのを確実にしてください。 特に、強調キャラクタは受入れられません。 どの無効のキャラクタコードでコマンドを受け取るSMTPサーバーが使われて、何か他のものがどれがあるように拒絶のために推論して、501応答によるそのコマンドを拒絶してはいけないかをそうされます。

4.1.3 Address Literals

4.1.3 アドレスリテラル

   Sometimes a host is not known to the domain name system and
   communication (and, in particular, communication to report and repair
   the error) is blocked.  To bypass this barrier a special literal form
   of the address is allowed as an alternative to a domain name.  For
   IPv4 addresses, this form uses four small decimal integers separated
   by dots and enclosed by brackets such as [], which
   indicates an (IPv4) Internet Address in sequence-of-octets form.  For
   IPv6 and other forms of addressing that might eventually be
   standardized, the form consists of a standardized "tag" that
   identifies the address syntax, a colon, and the address itself, in a
   format specified as part of the IPv6 standards [17].

時々、ホストはドメイン名システムに知られていません、そして、コミュニケーション(誤りを報告して、修理する特にコミュニケーション)は妨げられます。 このバリアを迂回させるために、アドレスの特別な文字通りのフォームはドメイン名に代わる手段として許容されています。 IPv4アドレスに、このフォームがわずかな10進ドットで切り離している、同封の整数がそのようなものに腕木を付ける4を使用する、[123.255 .37 .2] 八重奏の系列の(IPv4)インターネットAddressが形成するのを示す。 結局標準化されるかもしれないIPv6と他の用紙のアドレシングのために、フォームはアドレス構文、コロン、およびアドレス自体を特定する標準化された「タグ」から成ります、IPv6規格[17]の一部として指定された形式で。



      IPv4-address-literal = Snum 3("." Snum)
      IPv6-address-literal = "IPv6:" IPv6-addr
      General-address-literal = Standardized-tag ":" 1*dcontent
      Standardized-tag = Ldh-str
            ; MUST be specified in a standards-track RFC
            ; and registered with IANA

IPv4アドレスリテラル=Snum3、(「. 」 Snum) IPv6アドレスリテラル=、「IPv6:」 「IPv6-addrの一般アドレスリテラルは標準化されたタグと等しい」:、」 1*dcontentの標準化されたタグはLdh-strと等しいです。 標準化過程RFCで指定しなければなりません。 そして、IANAに登録にされる

      Snum = 1*3DIGIT  ; representing a decimal integer
            ; value in the range 0 through 255
      Let-dig = ALPHA / DIGIT
      Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig

Snumは1*3DIGITと等しいです。 10進整数を表します。 範囲で皮肉をさせて0〜255Let-皮肉=アルファー/DIGIT Ldh-str=*(アルファー/ DIGIT /「-」)を評価してください。

      IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
      IPv6-hex  = 1*4HEXDIG
      IPv6-full = IPv6-hex 7(":" IPv6-hex)
      IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":"
            ; The "::" represents at least 2 16-bit groups of zeros
            ; No more than 6 groups in addition to the "::" may be
            ; present
      IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
      IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"

「IPv6-addrはIPv6完全であるかIPv6v4いっぱいなIPv6-コンピュータ/IPv6v4/コンピュータIPv6-十六進法=1*4HEXDIG IPv6完全な=IPv6-十六進法7(「:」 IPv6-十六進法)IPv6-コンピュータ=[IPv6-十六進法*5(「:」 IPv6-十六進法)]と等しい」:、:、」 [IPv6-十六進法*5(「:」 IPv6-十六進法)]。 「The」、:、:、」 少なくとも2つのゼロ人の16ビットのグループを代表します。 に加えて「6つ未満のグループ、」、:、:、」 あるかもしれません。 「IPv6-十六進法いっぱいな現在のIPv6v4=5(「:」 IPv6-十六進法)」:、」 「IPv4アドレスリテラルIPv6v4-コンピュータ=[IPv6-十六進法*3(「:」 IPv6-十六進法)]」:、:、」

Klensin                     Standards Track                    [Page 38]

RFC 2821             Simple Mail Transfer Protocol            April 2001


                   [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal
            ; The "::" represents at least 2 16-bit groups of zeros
            ; No more than 4 groups in addition to the "::" and
            ; IPv4-address-literal may be present

「[IPv6-十六進法*3(「:」 IPv6-十六進法)、」、:、」、]、IPv4はリテラルを扱います。 「The」、:、:、」 少なくとも2つのゼロ人の16ビットのグループを代表します。 に加えて「4つ未満のグループ、」、:、:、」 そして、。 IPv4アドレスリテラルは存在しているかもしれません。

4.1.4 Order of Commands

4.1.4 コマンドの注文

   There are restrictions on the order in which these commands may be


   A session that will contain mail transactions MUST first be
   initialized by the use of the EHLO command.  An SMTP server SHOULD
   accept commands for non-mail transactions (e.g., VRFY or EXPN)
   without this initialization.

最初に、EHLOコマンドの使用でメールトランザクションを含むセッションを初期化しなければなりません。 SHOULDが受け入れるSMTPサーバーは非メールトランザクション(例えば、VRFYかEXPN)のためにこの初期化なしで命令します。

   An EHLO command MAY be issued by a client later in the session.  If
   it is issued after the session begins, the SMTP server MUST clear all
   buffers and reset the state exactly as if a RSET command had been
   issued.  In other words, the sequence of RSET followed immediately by
   EHLO is redundant, but not harmful other than in the performance cost
   of executing unnecessary commands.

EHLOコマンドは後でのセッションにおけるクライアントによって発行されるかもしれません。 セッションが始まった後にそれが発行されるなら、SMTPサーバーは、まるでちょうどRSETコマンドを発行したかのようにすべてのバッファをきれいにして、状態をリセットしなければなりません。 言い換えれば、すぐEHLOによって続かれたRSETの系列は、余分ですが、不要なコマンドを実行する性能費用以外に、有害ではありません。

   If the EHLO command is not acceptable to the SMTP server, 501, 500,
   or 502 failure replies MUST be returned as appropriate.  The SMTP
   server MUST stay in the same state after transmitting these replies
   that it was in before the EHLO was received.

EHLOコマンドが許容できないなら、SMTPサーバー、501、500、または502に、適宜失敗回答を返さなければなりません。 それが以前にあったこれらの回答を伝えて、EHLOが受け取られていた後にSMTPサーバーは同じ状態にいなければなりません。

   The SMTP client MUST, if possible, ensure that the domain parameter
   to the EHLO command is a valid principal host name (not a CNAME or MX
   name) for its host.  If this is not possible (e.g., when the client's
   address is dynamically assigned and the client does not have an
   obvious name), an address literal SHOULD be substituted for the
   domain name and supplemental information provided that will assist in
   identifying the client.

できれば、SMTPクライアントは、EHLOコマンドへのドメインパラメタが有効なホストにとって、主要なホスト名(CNAMEでないMX名でない)であることを保証しなければなりません。 これは可能ではありません(例えば、クライアントには、いつ、クライアントのアドレスがダイナミックに割り当てられて、明白な名前がありませんか)、アドレスの文字通りのSHOULD。ドメイン名に代入されるのと補足的情報が、意志であればクライアントを特定するのを助けるということになってください。

   An SMTP server MAY verify that the domain name parameter in the EHLO
   command actually corresponds to the IP address of the client.
   However, the server MUST NOT refuse to accept a message for this
   reason if the verification fails: the information about verification
   failure is for logging and tracing only.

SMTPサーバーは、EHLOコマンドにおけるドメイン名パラメタが実際にクライアントのIPアドレスに対応することを確かめるかもしれません。 しかしながら、検証が失敗するなら、サーバは、この理由でメッセージを受け入れるのを拒否してはいけません: 検証失敗の情報は伐採とたどるだけのものです。

   The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time
   during a session, or without previously initializing a session.  SMTP
   servers SHOULD process these normally (that is, not return a 503
   code) even if no EHLO command has yet been received; clients SHOULD
   open a session with EHLO before sending these commands.

NOOP、ヘルプ、セッション、または以前にセッションを初期化しないで、いつでも、EXPN、VRFY、およびRSETコマンドを使用できます。 まだEHLOコマンドを全く受け取らないでも、通常(すなわち、503コードを返さない)、SMTPプロトコルのサーバSHOULDはこれらを処理します。 クライアントSHOULDはこれらのコマンドを送る前のEHLOと共に開会します。

Klensin                     Standards Track                    [Page 39]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   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.


   The MAIL command (or the obsolete SEND, SOML, or SAML commands)
   begins a mail transaction.  Once started, a mail transaction consists
   of a transaction beginning command, one or more RCPT commands, and a
   DATA command, in that order.  A mail transaction may be aborted by
   the RSET (or a new EHLO) command.  There may be zero or more
   transactions in a session.  MAIL (or SEND, SOML, or SAML) MUST NOT be
   sent if a mail transaction is already open, i.e., it should be sent
   only if no mail transaction had been started in the session, or it
   the previous one successfully concluded with a successful DATA
   command, or if the previous one was aborted with a RSET.

メールコマンド(または、時代遅れのSEND、SOML、またはSAMLコマンド)はメールトランザクションを始めます。 一度始められます、メールトランザクションはコマンド、1つ以上のRCPTコマンド、およびDATAコマンドを始めるトランザクションから成ります、そのオーダーで。 メールトランザクションはRSET(または、新しいEHLO)コマンドで中止されるかもしれません。 セッションにはゼロか、より多くのトランザクションがあるかもしれません。 メールトランザクションが既に開きます、セッションのときにメールトランザクションを全く始めていない場合にだけすなわち、それを送るということであるかそれがうまくいっているDATAコマンドで首尾よく結論づけられた前のものである、またはRSETと共に前のものを中止したなら、メール(または、SEND、SOML、またはSAML)を送ってはいけません。

   If the transaction beginning command argument is not acceptable, a
   501 failure reply MUST be returned and the SMTP server MUST stay in
   the same state.  If the commands in a transaction are out of order to
   the degree that they cannot be processed by the server, a 503 failure
   reply MUST be returned and the SMTP server MUST stay in the same

コマンド議論を始めるトランザクションが許容できないなら、501失敗回答を返さなければなりません、そして、SMTPサーバーは同じ状態にいなければなりません。 トランザクションにおけるコマンドが度合いに不適切であるなら、サーバ、503失敗回答でそれらを処理できないのを返さなければなりません、そして、SMTPサーバーは同じ状態にいなければなりません。

   The last command in a session MUST be the QUIT command.  The QUIT
   command cannot be used at any other time in a session, but SHOULD be
   used by the client SMTP to request connection closure, even when no
   session opening command was sent and accepted.

セッションにおける持続コマンドはQUITコマンドであるに違いありません。 セッションのときに他の時ならいつでもQUITコマンドを使用できませんが、SHOULDが接続閉鎖を要求するのにクライアントSMTPによって使用されて、セッションでさえないときに、初めのコマンドを送って、受け入れました。

4.1.5 Private-use Commands

4.1.5 私用コマンド

   As specified in section 2.2.2, commands starting in "X" may be used
   by bilateral agreement between the client (sending) and server
   (receiving) SMTP agents.  An SMTP server that does not recognize such
   a command is expected to reply with "500 Command not recognized".  An
   extended SMTP server MAY list the feature names associated with these
   private commands in the response to the EHLO command.

セクション2.2.2で指定されるように、「X」で始まるコマンドはクライアント(発信)とサーバ(受信)SMTPエージェントの間の二国間条約によって使用されるかもしれません。 そのようなコマンドを認識しないSMTPサーバーが「Commandが認識しなかった500」で返答すると予想されます。 拡張SMTPサーバーはEHLOコマンドへの応答におけるこれらの個人的なコマンドに関連している特徴名を記載するかもしれません。

   Commands sent or accepted by SMTP systems that do not start with "X"
   MUST conform to the requirements of section 2.2.2.


4.2 SMTP Replies

4.2 SMTP回答

   Replies to SMTP commands serve to ensure the synchronization of
   requests and actions in the process of mail transfer and to guarantee
   that the SMTP client always knows the state of the SMTP server.
   Every command MUST generate exactly one reply.


Klensin                     Standards Track                    [Page 40]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   The details of the command-reply sequence are described in section


   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

SMTP回答は別の方法で本書では指定されない場合何らかのテキストがあとに続いた3桁数(3つの数字として、伝えられる)から成ります。 数はオートマトンによる使用が、次にどんな状態に入ったらよいかを決定することです。 テキストは人間のユーザのためのものです。 3ケタはSMTPクライアントがテキストを調べる必要はなくて、それを捨てるか、またはそれを通過するかもしれないという十分なコード化された情報をユーザに含んでいます、適宜。 例外が別掲のとおりこのドキュメントにあります。 220、221、251、421、および551の回答コードがマシンで分析されて、解釈しなければならないメッセージ・テキストに特に、関連しています。 一般的な場合には、テキストが受信機に依存していて文脈に依存しているかもしれないので、それぞれの回答コードにおいて、異なったテキストがありそうです。 セクション4.2.1で回答コードの理論の議論をします。 正式に、回答は系列になるように定義されます: 3ケタのコードか、<SP>か、1個のテキスト行と、<CRLF>か、マルチラインが返答します(セクション4.2.1で定義されるように)。 以来この仕様を違反してテキストは時々送られません、それを受けないクライアント、SHOULD、単独(引きずっている間隔文字のあるなしにかかわらず)でコードを処理するように用意してください。 EHLO、EXPN、およびHELPコマンドだけが平常な時にマルチライン回答をもたらすと予想されて、しかしながら、マルチライン回答はどんなコマンドのためにも許されています。

   In ABNF, server responses are:


      Greeting = "220 " Domain [ SP text ] CRLF
      Reply-line = Reply-code [ SP text ] CRLF

挨拶=回答コード[SPテキスト]「220」ドメイン[SPテキスト]CRLF Reply-線=CRLF

   where "Greeting" appears only in the 220 response that announces that
   the server is opening its part of the connection.


   An SMTP server SHOULD send only the reply codes listed in this
   document.  An SMTP server SHOULD use the text shown in the examples
   whenever appropriate.

SHOULDが回答コードだけを送るSMTPサーバーは本書では記載しました。 SMTPサーバーSHOULDは適切であるときはいつも、例に示されたテキストを使用します。

   An SMTP client MUST determine its actions only by the reply code, not
   by the text (except for the "change of address" 251 and 551 and, if
   necessary, 220, 221, and 421 replies); in the general case, any text,
   including no text at all (although senders SHOULD NOT send bare
   codes), MUST be acceptable.  The space (blank) following the reply
   code is considered part of the text.  Whenever possible, a receiver-
   SMTP SHOULD test the first digit (severity indication) of the reply

回答コード(必要なら「住所の変更」251と551、220、221、および421の回答を除いた)だけでSMTPクライアントはテキストで決定するのではなく、動作を決定しなければなりません。 一般的な場合では、テキストを全く(送付者SHOULD NOTはむき出しのコードを送りますが)含まないどんなテキストも許容できるに違いありません。 回答コードに従うスペース(空白の)はテキストの一部であると考えられます。 可能であるときはいつも、受信機SMTP SHOULDは回答コードの最初のケタ(厳しさ指示)をテストします。

Klensin                     Standards Track                    [Page 41]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   The list of codes that appears below MUST NOT be construed as
   permanent.  While the addition of new codes should be a rare and
   significant activity, with supplemental information in the textual
   part of the response being preferred, new codes may be added as the
   result of new Standards or Standards-track specifications.
   Consequently, a sender-SMTP MUST be prepared to handle codes not
   specified in this document and MUST do so by interpreting the first
   digit only.

永久的であるとして以下に現れるコードのリストを解釈してはいけません。 新法の追加がまれで重要な活動であるべきである間、応答の原文の部分の補足的情報が好まれている状態で、新法は新しいStandardsかStandards-道の仕様の結果として加えられるかもしれません。 その結果、送付者-SMTP MUSTは、本書では指定されなかったコードを扱うように準備されて、最初のケタだけを解釈することによって、そうしなければなりません。

4.2.1 Reply Code Severities and Theory

4.2.1 回答コードの厳しさと理論

   The three digits of the reply each have a special significance.  The
   first digit denotes whether the response is good, bad or incomplete.
   An unsophisticated SMTP client, or one that receives an unexpected
   code, will be able to determine its next action (proceed as planned,
   redo, retrench, etc.) by examining this first digit.  An SMTP client
   that wants to know approximately what kind of error occurred (e.g.,
   mail system error, command syntax error) may examine the second
   digit.  The third digit and any supplemental information that may be
   present is reserved for the finest gradation of information.

それぞれ回答の3ケタは特別な意義があります。 応答が良いか、悪いかまたは不完全であることにかかわらずケタが指示する1番目。 世慣れていないSMTPクライアント、または予期していなかったコードを受け取るものが次の動作を決定できる、(計画通り続いてください、改装、など) 調べるのによるこの最初のケタに節約してください。 どういう誤りが周囲に発生したかを(例えば、システム誤りを郵送してください、コマンド構文エラー)知りたがっているSMTPクライアントは2番目のケタを調べるかもしれません。 存在するかもしれない3番目のケタとどんな補足的情報も情報の最もすばらしい段階のために予約されます。

   There are five values for the first digit of the reply code:


   1yz   Positive Preliminary reply
      The command has been accepted, but the requested action is being
      held in abeyance, pending confirmation of the information in this
      reply.  The SMTP client should send another command specifying
      whether to continue or abort the action.  Note: unextended SMTP
      does not have any commands that allow this type of reply, and so
      does not have continue or abort commands.

要求された動作だけが停止しているのに保たれています、コマンドが持っている1yz Positive Preliminary回答を受け入れてこの回答における、情報の確認まで。 SMTPクライアントは別のコマンドに動作を続けているか、または中止するかを指定させるべきです。 以下に注意してください。 unextended SMTPには、それがこのタイプの回答を許すのでコマンドを続けているか、または中止するのを持っていない少しのコマンドもありません。

   2yz   Positive Completion reply
      The requested action has been successfully completed.  A new
      request may be initiated.

要求された動作が持っている2yz Positive Completion回答は首尾よくそうです。完成されます。 新しい要求は開始されるかもしれません。

   3yz   Positive Intermediate reply
      The command has been accepted, but the requested action is being
      held in abeyance, pending receipt of further information.  The
      SMTP client should send another command specifying this
      information.  This reply is used in command sequence groups (i.e.,
      in DATA).

要求された動作だけが停止しているのに保たれています、コマンドが持っている3yz Positive Intermediate回答を受け入れて詳細の領収書まで。 SMTPクライアントは別のコマンドにこの情報を指定させるべきです。 この回答はコマンド・シーケンスグループ(すなわち、DATAの)に使用されます。

   4yz   Transient Negative Completion reply
      The command was not accepted, and the requested action did not
      occur.  However, the error condition is temporary and the action
      may be requested again.  The sender should return to the beginning
      of the command sequence (if any).  It is difficult to assign a
      meaning to "transient" when two different sites (receiver- and

4yz Transient Negative Completionは返答します。コマンドは受け入れられませんでした、そして、要求された動作は起こりませんでした。 しかしながら、エラー条件は一時的です、そして、動作は再び要求されているかもしれません。 送付者はコマンド・シーケンス(もしあれば)の始まりまで戻るべきです。 そして2つの異なったサイトであるときに、「一時的に」意味を割り当てるのが難しい、(受信機。

Klensin                     Standards Track                    [Page 42]

RFC 2821             Simple Mail Transfer Protocol            April 2001


      sender-SMTP agents) must agree on the interpretation.  Each reply
      in this category might have a different time value, but the SMTP
      client is encouraged to try again.  A rule of thumb to determine
      whether a reply fits into the 4yz or the 5yz category (see below)
      is that replies are 4yz if they can be successful if repeated
      without any change in command form or in properties of the sender
      or receiver (that is, the command is repeated identically and the
      receiver does not put up a new implementation.)

送付者-SMTPエージェント) 解釈に同意しなければなりません。 このカテゴリにおける各回答には、異なった時間的価値があるかもしれませんが、SMTPクライアントが再試行するよう奨励されます。 回答が4yzか5yzカテゴリに収まる(以下を見てください)か否かに関係なく、決定する経験則はコマンドフォームか特性における少しも変化なしで繰り返されるならそれらが送付者か受信機でうまくいく場合があるなら回答が4yzであるということです。(すなわち、コマンドは同様に繰り返されて、受信機は新しい実装を提供しません。)

   5yz   Permanent Negative Completion reply
      The command was not accepted and the requested action did not
      occur.  The SMTP client is discouraged from repeating the exact
      request (in the same sequence).  Even some "permanent" error
      conditions can be corrected, so the human user may want to direct
      the SMTP client to reinitiate the command sequence by direct
      action at some point in the future (e.g., after the spelling has
      been changed, or the user has altered the account status).

5yz Permanent Negative Completionは返答します。コマンドは受け入れられませんでした、そして、要求された動作は起こりませんでした。 SMTPクライアントは、正確な要求(同じ系列の)を繰り返して、がっかりしています。 人間のユーザは、いくつかの「永久的な」エラー条件さえ修正できるので、いくつかの直接行動によるコマンド・シーケンスが将来指す再開始にSMTPクライアントを向けたがっているかもしれません(例えば、スペルを変えたか、またはユーザがアカウントステータスを変更した後に)。

   The second digit encodes responses in specific categories:


   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

x2zコネクションズ: これらはトランスミッションチャンネルについて言及する回答です。

   x3z   Unspecified.


   x4z   Unspecified.


   x5z   Mail system: These replies indicate the status of the receiver
      mail system vis-a-vis the requested transfer or other mail system

x5zメールシステム: これらの回答は要求された転送か他のメールシステム動作と向かいあって受信機メールシステムの状態を示します。

   The third digit gives a finer gradation of meaning in each category
   specified by the second digit.  The list of replies illustrates this.
   Each reply text is recommended rather than mandatory, and may even
   change according to the command with which it is associated.  On the
   other hand, the reply codes must strictly follow the specifications
   in this section.  Receiver implementations should not invent new
   codes for slightly different situations from the ones described here,
   but rather adapt codes already defined.

3番目のケタは2番目のケタによって指定された各カテゴリにおける意味の、よりすばらしい段階を与えます。 回答のリストはこれを例証します。 それぞれの回答テキストは、義務的であるというよりむしろお勧めであり、それが関連しているコマンドに応じて、変化さえするかもしれません。 他方では、回答コードは厳密にこのセクションの仕様に従わなければなりません。 受信機実装はここで説明されたものからわずかに異なった状況のための新法を発明するべきではありませんが、むしろ既に定義されたコードを適合させてください。

Klensin                     Standards Track                    [Page 43]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   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

例えば、NOOPなどのコマンドは250回答を返すでしょう。(NOOPのうまくいっている実行は少しの新情報もSMTPクライアントに提供しません)。 コマンドが非実装している非サイトの詳細動作を要求するとき、回答は502です。 その気品は実装されますが、非実装しているパラメタを要求するコマンドのための504回答です。

   The reply text may be longer than a single line; in these cases the
   complete text must be marked so the SMTP client knows when it can
   stop reading the reply.  This requires a special format to indicate a
   multiple line reply.

回答テキストは単線より長いかもしれません。 これらの場合では、全文をマークしなければならないので、SMTPクライアントは、それが、いつ回答を読むのを止めることができるかを知っています。 これは、複数の系列回答を示すために特別な形式を必要とします。

   The format for multiline replies requires that every line, except the
   last, begin with the reply code, followed immediately by a hyphen,
   "-" (also known as minus), followed by text.  The last line will
   begin with the reply code, followed immediately by <SP>, optionally
   some text, and <CRLF>.  As noted above, servers SHOULD send the <SP>
   if subsequent text is not sent, but clients MUST be prepared for it
   to be omitted.

マルチライン回答のための形式は、最終を除いて、テキストがすぐにハイフン、「-」(また、マイナスとして、知られている)であとに続く回答コードのあとに続いていてあらゆる系列が始まるのを必要とします。 最終ラインはすぐ<SP>によって従われた回答コードで任意に始まるでしょう。何らかのテキスト、および<CRLF>。 上で述べたように、その後のテキストが送られませんが、クライアントがそれが省略される用意ができていなければならないなら、サーバSHOULDは<SP>を送ります。

   For example:


      123-First line
      123-Second line
      123-234 text beginning with numbers
      123 The last line


   In many cases the SMTP client then simply needs to search for a line
   beginning with the reply code followed by <SP> or <CRLF> and ignore
   all preceding lines.  In a few cases, there is important data for the
   client in the reply "text".  The client will be able to identify
   these cases from the current context.

多くの場合、そして、SMTPクライアントは、単に回答コードが<SP>か<CRLF>によって従われている状態で始まる系列を捜し求めて、すべての前の系列を無視する必要があります。 いくつかの場合には、回答「テキスト」にクライアントにとって、重要なデータがあります。 クライアントは現在の背景からのこれらのケースを特定できるでしょう。

4.2.2 Reply Codes by Function Groups

4.2.2 関数群による回答コード

      500 Syntax error, command unrecognized
         (This may include errors such as command line too long)
      501 Syntax error in parameters or arguments
      502 Command not implemented  (see section 4.2.4)
      503 Bad sequence of commands
      504 Command parameter not implemented


      211 System status, or system help reply
      214 Help message
         (Information on how to use the receiver or the meaning of a
         particular non-standard command; this reply is useful only
         to the human user)

211 システム状態、またはシステム助け回答214ヘルプメッセージ(特定の標準的でないコマンド; この回答の受信機か意味を使用するのがどう人間のユーザだけの役に立つかに関する情報)

Klensin                     Standards Track                    [Page 44]

RFC 2821             Simple Mail Transfer Protocol            April 2001


      220 <domain> Service ready
      221 <domain> Service closing transmission channel
      421 <domain> Service not available, closing transmission channel
         (This may be a reply to any command if the service knows it
         must shut down)

220 持ち合わせの<の>Service終わりのトランスミッションドメイン>Service221<ドメインチャンネル421のドメインの>のServiceの利用可能で、終わりでないトランスミッション<チャンネル(サービスが、それが停止しなければならないのを知っているなら、これはどんなコマンドに関する回答であるかもしれません)

      250 Requested mail action okay, completed
      251 User not local; will forward to <forward-path>
         (See section 3.4)
      252 Cannot VRFY user, but will accept message and attempt
         (See section 3.5.3)
      450 Requested mail action not taken: mailbox unavailable
         (e.g., mailbox busy)
      550 Requested action not taken: mailbox unavailable
         (e.g., mailbox not found, no access, or command rejected
         for policy reasons)
      451 Requested action aborted: error in processing
      551 User not local; please try <forward-path>
         (See section 3.4)
      452 Requested action not taken: insufficient system storage
      552 Requested mail action aborted: exceeded storage allocation
      553 Requested action not taken: mailbox name not allowed
         (e.g., mailbox syntax incorrect)
      354 Start mail input; end with <CRLF>.<CRLF>
      554 Transaction failed (Or, in the case of a connection-opening
          response, "No SMTP service here")

250は地方でなくメール動作オーケーの、そして、完成した251Userを要求しました。 >(セクション3.4を見る)252Cannot VRFYユーザを<フォワードパスに送りますが、メッセージと試み配送(セクション3.5.3を見る)450Requestedメール動作が取られないと受け入れるでしょう: 入手できないメールボックス、(例えば、メールボックスが忙しくする、)、550 取られなかったRequested行動: メールボックス入手できない(方針理由で拒絶されなかった例えば見つけられなかったメールボックス、アクセス、またはコマンド全く)451Requested動作は中止になりました: 処理551Userの地方でない誤り。 取られなかった<フォワードパス>(セクション3.4を見る)452Requested行動を試みてください: 不十分なシステムストレージ552Requestedメール動作は中止になりました: 取られなかった超えられている記憶領域の割当て553Requested行動: メールボックス名が許容しなかった、(例えば、メールボックス構文不正確である、)、354 Startは入力を郵送します。 <CRLF><CRLF>554Transactionが失敗されている状態で、終わってください。(または接続の初めである応答、「ここでSMTPサービスがありません」の場合で)

4.2.3  Reply Codes in Numeric Order

4.2.3 数値オーダーにおける回答コード

      211 System status, or system help reply
      214 Help message
         (Information on how to use the receiver or the meaning of a
         particular non-standard command; this reply is useful only
         to the human user)
      220 <domain> Service ready
      221 <domain> Service closing transmission channel
      250 Requested mail action okay, completed
      251 User not local; will forward to <forward-path>
         (See section 3.4)
      252 Cannot VRFY user, but will accept message and attempt
         (See section 3.5.3)

211 システム状態、または地方でなくトランスミッションチャンネル250Requestedメール動作オーケーの、そして、完成した251Userを閉じるシステム助け回答214ヘルプメッセージ(特定の標準的でないコマンド; この回答の受信機か意味を使用するのがどう人間のユーザだけの役に立つかに関する情報)220<ドメイン>のServiceの持ち合わせの221<ドメイン>Service。 >(セクション3.4を見る)252Cannot VRFYユーザを<フォワードパスに送りますが、メッセージと試み配送を受け入れるでしょう。(セクション3.5.3を見ます)

      354 Start mail input; end with <CRLF>.<CRLF>

354 メール入力を始めてください。 <CRLF><CRLF>で、終わってください。

Klensin                     Standards Track                    [Page 45]

RFC 2821             Simple Mail Transfer Protocol            April 2001


      421 <domain> Service not available, closing transmission channel
         (This may be a reply to any command if the service knows it
         must shut down)
      450 Requested mail action not taken: mailbox unavailable
         (e.g., mailbox busy)
      451 Requested action aborted: local error in processing
      452 Requested action not taken: insufficient system storage
      500 Syntax error, command unrecognized
         (This may include errors such as command line too long)
      501 Syntax error in parameters or arguments
      502 Command not implemented (see section 4.2.4)
      503 Bad sequence of commands
      504 Command parameter not implemented
      550 Requested action not taken: mailbox unavailable
         (e.g., mailbox not found, no access, or command rejected
         for policy reasons)
      551 User not local; please try <forward-path>
         (See section 3.4)
      552 Requested mail action aborted: exceeded storage allocation
      553 Requested action not taken: mailbox name not allowed
         (e.g., mailbox syntax incorrect)
      554 Transaction failed  (Or, in the case of a connection-opening
          response, "No SMTP service here")

421 <のドメインの>のServiceの利用可能で、終わりでないトランスミッションチャンネル(サービスが、それが停止しなければならないのを知っているなら、これはどんなコマンドに関する回答であるかもしれない)450Requestedは取られなかった行動を郵送します: 入手できないメールボックス、(例えば、メールボックスが忙しくする、)、451 Requested動作は中止になりました: 取られなかった処理452Requested行動における地方の誤り: 不十分なシステムストレージ500Syntax誤り、パラメタか議論502Commandの認識されていない(これはあまりに長い間、コマンドラインなどの誤りを含むかもしれない)501Syntax誤りが504Commandパラメタが取られなかった550Requested行動を実装しなかったコマンドの503Bad系列を実装しなかった(セクション4.2.4を見ます)コマンド: ローカルではなく、メールボックス入手できない(方針理由で拒絶されなかった例えば見つけられなかったメールボックス、アクセス、またはコマンド全く)551User。 >(セクション3.4を見る)552Requestedメール動作が中止した<フォワードパスを試みてください: 取られなかった超えられている記憶領域の割当て553Requested行動: メールボックス名が許容しなかった、(例えば、メールボックス構文不正確である、)、554Transactionは失敗しました。(または接続の初めである応答、「ここでSMTPサービスがありません」の場合で)

4.2.4 Reply Code 502

4.2.4 回答コード502

   Questions have been raised as to when reply code 502 (Command not
   implemented) SHOULD be returned in preference to other codes.  502
   SHOULD be used when the command is actually recognized by the SMTP
   server, but not implemented.  If the command is not recognized, code
   500 SHOULD be returned.  Extended SMTP systems MUST NOT list
   capabilities in response to EHLO for which they will return 502 (or
   500) replies.

回答が502(実装されなかったコマンド)SHOULDをコード化する時に関して疑問を引き起こしました。他のコードに優先して、返します。 502 コマンドが実際にSMTPサーバーによって認識されるとき、使用されますが、実装されなかったSHOULD。 コマンドが認識されないで、500SHOULDをコード化するなら、返してください。 拡張SMTPシステムはそれらが502(または、500)の回答を返すEHLOに対応して能力を記載してはいけません。

4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>

4.2.5 回答はデータとその後の<CRLFの後に><CRLF>をコード化します。

   When an SMTP server returns a positive completion status (2yz code)
   after the DATA command is completed with <CRLF>.<CRLF>, it accepts
   responsibility for:


   -  delivering the message (if the recipient mailbox exists), or

- またはメッセージ(受取人メールボックスが存在しているなら)を提供する。

   -  if attempts to deliver the message fail due to transient
      conditions, retrying delivery some reasonable number of times at
      intervals as specified in section 4.5.4.

- メッセージを提供する試みが一時的な状態、再試行配送のためセクション4.5.4における指定されるとしての間隔を置いて何らかの相当な数の回に失敗するなら。

Klensin                     Standards Track                    [Page 46]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   -  if attempts to deliver the message fail due to permanent
      conditions, or if repeated attempts to deliver the message fail
      due to transient conditions, returning appropriate notification to
      the sender of the original message (using the address in the SMTP
      MAIL command).

- メッセージを提供する試みが永久的な状態のため失敗するか、またはオリジナルのメッセージの送付者に適切な通知を返して、メッセージを提供する繰り返された試みが一時的な状態のため失敗するなら(SMTP MAILコマンドにアドレスを使用して)。

   When an SMTP server returns a permanent error status (5yz) code after
   the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
   any subsequent attempt to deliver that message.  The SMTP client
   retains responsibility for delivery of that message and may either
   return it to the user or requeue it for a subsequent attempt (see

DATAコマンドが<CRLF><CRLF>で終了した後にSMTPサーバーが永続エラー状態(5yz)コードを返すとき、それはそのメッセージを提供するどんなその後の試みもしてはいけません。 セクション4.5を見てください。SMTPクライアントがそのメッセージの配送のために責任を保有して、それをユーザに返すか、またはその後の試みのためにそれを「再-列に並ばせ」るかもしれない、(.4 .1)。

   The user who originated the message SHOULD be able to interpret the
   return of a transient failure status (by mail message or otherwise)
   as a non-delivery indication, just as a permanent failure would be
   interpreted.  I.e., if the client SMTP successfully handles these
   conditions, the user will not receive such a reply.

だれがメッセージSHOULDを溯源したか。ユーザ、非配送指示として一時障害状態(メール・メッセージかそうでないのによる)の復帰を解釈できてください、ちょうど永久的な失敗が解釈されるように。 すなわち、クライアントSMTPが首尾よくこれらの状態を扱うと、ユーザはそのような回答を受け取らないでしょう。

   When an SMTP server returns a permanent error status (5yz) code after
   the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make
   any subsequent attempt to deliver the message.  As with temporary
   error status codes, the SMTP client retains responsibility for the
   message, but SHOULD not again attempt delivery to the same server
   without user review and intervention of the message.

DATAコマンドが<CRLF>完全に<CRLF>であった後にSMTPサーバーが永続エラー状態(5yz)コードを返すとき、それはメッセージを提供するどんなその後の試みもしてはいけません。 一時的な誤りステータスコードのように、SMTPクライアントはメッセージへの責任を保有します、しかし、SHOULDが再びメッセージのユーザレビューと介入なしで同じサーバに配送を試みません。

4.3 Sequencing of Commands and Replies

4.3 コマンドと回答の配列

4.3.1 Sequencing Overview

4.3.1 配列概要

   The communication between the sender and receiver is an alternating
   dialogue, controlled by the sender.  As such, the sender issues a
   command and the receiver responds with a reply.  Unless other
   arrangements are negotiated through service extensions, the sender
   MUST wait for this response before sending further commands.

送付者と受信機とのコミュニケーションは送付者によって制御された交互の対話です。 そういうものとして、送付者はコマンドを発行します、そして、受信機は回答で応じます。 他のアレンジメントがサービス拡大で交渉されない場合、さらなるコマンドを送る前に、送付者はこの応答を待たなければなりません。

   One important reply is the connection greeting.  Normally, a receiver
   will send a 220 "Service ready" reply when the connection is
   completed.  The sender SHOULD wait for this greeting message before
   sending any commands.

1つの重要な回答は接続挨拶です。 接続が終了しているとき、通常、受信機は220の「サービス準備ができる」回答を送るでしょう。 どんなコマンドも送る前に、送付者SHOULDはこのあいさつメッセージを待ちます。

   Note: all the greeting-type replies have the official name (the
   fully-qualified primary domain name) of the server host as the first
   word following the reply code.  Sometimes the host will have no
   meaningful name.  See 4.1.3 for a discussion of alternatives in these

以下に注意してください。 挨拶タイプ回答にはすべて、回答コードに従って、最初の単語としてサーバー・ホストの正式名称(完全に適切な一次的領域名)があります。 ホストには、時々、どんな重要な名前もないでしょう。 これらの状況における、代替手段の議論に関して4.1に.3を見てください。

Klensin                     Standards Track                    [Page 47]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   For example,


      220 ISIF.USC.EDU Service ready
      220 mail.foo.com SuperSMTP v 6.1.2 Service ready
      220 [] Clueless host service ready

ISIF.USC.EDU Service準備ができるか220mail.foo.com SuperSMTP v6.1.2Serviceが準備する220か220、[10.0の.0の.1の]手掛かりのないホストサービス準備ができている。

   The table below lists alternative success and failure replies for
   each command.  These SHOULD be strictly adhered to: a receiver may
   substitute text in the replies, but the meaning and action implied by
   the code numbers and by the specific command reply sequence cannot be

代替の成功と失敗が各コマンドのために返答するリストの下のテーブル。 固く守られて、これらのSHOULDは厳密に以下の通りです。 受信機は回答におけるテキストを代入するかもしれませんが、コード番号と特定のコマンド回答系列によって含意された意味と動作は変更できません。

4.3.2 Command-Reply Sequences

4.3.2 コマンド回答系列

   Each command is listed with its usual possible replies.  The prefixes
   used before the possible replies are "I" for intermediate, "S" for
   success, and "E" for error.  Since some servers may generate other
   replies under special circumstances, and to allow for future
   extension, SMTP clients SHOULD, when possible, interpret only the
   first digit of the reply and MUST be prepared to deal with
   unrecognized reply codes by interpreting the first digit only.
   Unless extended using the mechanisms described in section 2.2, SMTP
   servers MUST NOT transmit reply codes to an SMTP client that are
   other than three digits or that do not start in a digit between 2 and
   5 inclusive.

各コマンドは普通の可能な回答で記載されています。 可能な回答の前に使用された接頭語は、中間的のための「私」と、成功のための「S」と、誤りのための「E」です。 以来に、いくつかのサーバが他の特殊事情の下での回答を生成するかもしれなくて、可能であるときに、今後の拡大を考慮するために、SMTPクライアントSHOULDを回答の最初のケタだけを解釈して、最初のケタだけを解釈することによって認識されていない回答コードに対処するように準備しなければなりません。 セクション2.2で説明されたメカニズムを使用することで広げられない場合、SMTPサーバーはSMTPクライアントへの3ケタ以外に、あるか、または2〜5ケタで包括的に開始しない回答コードを伝えてはいけません。

   These sequencing rules and, in principle, the codes themselves, can
   be extended or modified by SMTP extensions offered by the server and
   accepted (requested) by the client.


   In addition to the codes listed below, any SMTP command can return
   any of the following codes if the corresponding unusual circumstances
   are encountered:


   500  For the "command line too long" case or if the command name was
      not recognized.  Note that producing a "command not recognized"
      error in response to the required subset of these commands is a
      violation of this specification.

500 「コマンドラインも切望する」というケースかそれともコマンド名が認識されなかったかどうかのために。 これらのコマンドの必要な部分集合に対応して「認識されなかったコマンド」誤りを起こすのが、この仕様の違反であることに注意してください。

   501  Syntax error in command or arguments.  In order to provide for
      future extensions, commands that are specified in this document as
      not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501
      message if arguments are supplied in the absence of EHLO-
      advertised extensions.

コマンドか議論における501構文エラー。 今後の拡大に備えるために、EHLOが不在のとき議論を供給するなら本書では、SHOULDが501メッセージを返す主張(DATA、RSET、QUIT)を受け入れないと指定されるコマンドは拡大の広告を出しました。

   421  Service shutting down and closing transmission channel

421 停止するサービスと終わりのトランスミッションは向けられます。

Klensin                     Standards Track                    [Page 48]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   Specific sequences are:


      S: 220
      E: 554
      S: 250
      E: 504, 550
      S: 250
      E: 552, 451, 452, 550, 553, 503
      S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
      E: 550, 551, 552, 553, 450, 451, 452, 503, 550
      I: 354 -> data -> S: 250
                        E: 552, 554, 451, 452
      E: 451, 554, 503
      S: 250
      S: 250, 251, 252
      E: 550, 551, 553, 502, 504
      S: 250, 252
      E: 550, 500, 502, 504
      S: 211, 214
      E: 502, 504
      S: 250
      S: 221

コネクション確立S: 220E: 554 EHLOかHELO S: 250E: 504、550はSを郵送します: 250E: 552、451、452、550、553、503RCPT S: 250、251(251と551の議論に関してセクション3.4を見る)E: 550、551、552、553、450、451、452、503、550のデータI: 354 ->データ->S: 250E: 552、554、451、452E: 451、554、503RSET S: 250VRFY S: 250、251、252E: 550、551、553、502、504EXPN S: 250、252E: 550、500、502、504はSを助けます: 211、214E: 502、504NOOP S: 250 Sをやめてください: 221

4.4 Trace Information

4.4 トレース情報

   When an SMTP server receives a message for delivery or further
   processing, it MUST insert trace ("time stamp" or "Received")
   information at the beginning of the message content, as discussed in


   This line MUST be structured as follows:


   -  The FROM field, which MUST be supplied in an SMTP environment,
      SHOULD contain both (1) the name of the source host as presented
      in the EHLO command and (2) an address literal containing the IP
      address of the source, determined from the TCP connection.

- FROM野原、SHOULDは(1) EHLOコマンドにおける提示されるとしての送信元ホストの名前と(2) ソースのIPアドレスを含むアドレスリテラルの両方を含んでいます、TCP接続によって、断固としています。(SMTP環境でその野原を供給しなければなりません)。

Klensin                     Standards Track                    [Page 49]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   -  The ID field MAY contain an "@" as suggested in RFC 822, but this
      is not required.

- ID分野はRFC822に示されるように"@"を含むかもしれませんが、これは必要ではありません。

   -  The FOR field MAY contain a list of <path> entries when multiple
      RCPT commands have been given.  This may raise some security
      issues and is usually not desirable; see section 7.2.

- 複数のRCPTコマンドを与えたとき、FOR分野は<経路>エントリーのリストを含むかもしれません。 これは、いくつかの安全保障問題を提起するかもしれなくて、通常、望ましくはありません。 セクション7.2を見てください。

   An Internet mail program MUST NOT change a Received: line that was
   previously added to the message header.  SMTP servers MUST prepend
   Received lines to messages; they MUST NOT change the order of
   existing lines or insert Received lines in any other location.

インターネット・メールプログラムはReceivedを変えてはいけません: 以前にメッセージヘッダーに加えられた系列。 SMTPサーバーはメッセージへのprepend Received系列がそうしなければなりません。 彼らは、既設線の注文を変えてはいけませんし、またReceived系列をいかなる他の位置にも挿入してはいけません。

   As the Internet grows, comparability of Received fields is important
   for detecting problems, especially slow relays.  SMTP servers that
   create Received fields SHOULD use explicit offsets in the dates
   (e.g., -0800), rather than time zone names of any type.  Local time
   (with an offset) is preferred to UT when feasible.  This formulation
   allows slightly more information about local circumstances to be
   specified.  If UT is needed, the receiver need merely do some simple
   arithmetic to convert the values.  Use of UT loses information about
   the time zone-location of the server.  If it is desired to supply a
   time zone name, it SHOULD be included in a comment.

インターネットが発展するので、問題、特に遅いリレーを検出するのに、Received分野の比較可能性は重要です。 Received分野SHOULDを作成するSMTPサーバーがどんなタイプの時間帯の名よりもむしろ日付(例えば、-0800)で明白なオフセットを使用します。 可能であるときに、現地時間(オフセットがある)はユタより好まれます。 この定式化は、地元の事情に関する詳しい情報が指定されるのをわずかに許容します。 ユタが必要であるなら、受信機は、値を変換するために単に何らかの簡単な演算をしなければなりません。 ユタの使用はサーバの時間帯位置の情報を失います。それが望まれているなら、時間帯の名前を提供してください、それ、SHOULD、コメントで含められてください。

   When the delivery SMTP server makes the "final delivery" of a
   message, it inserts a return-path line at the beginning of the mail
   data.  This use of return-path is required; mail systems MUST support
   it.  The return-path line preserves the information in the <reverse-
   path> from the MAIL command.  Here, final delivery means the message
   has left the SMTP environment.  Normally, this would mean it had been
   delivered to the destination user or an associated mail drop, but in
   some cases it may be further processed and transmitted by another
   mail system.

配送SMTPサーバがメッセージの「最終的な配送」を作ると、それはメールデータの始めにリターンパス線を挿入します。 リターンパスのこの使用が必要です。 メールシステムはそれをサポートしなければなりません。 リターンパス線はメールコマンドから<逆経路>の情報を保存します。 ここで、最終的な配送は、メッセージがSMTPを環境に残したことを意味します。 通常、これが、それが目的地ユーザか関連ポストの差入れ口に提供されたことを意味するでしょうが、いくつかの場合、それは、別のメールシステムによってさらに処理されて、伝えられるかもしれません。

   It is possible for the mailbox in the return path to be different
   from the actual sender's mailbox, for example, if error responses are
   to be delivered to a special error handling mailbox rather than to
   the message sender.  When mailing lists are involved, this
   arrangement is common and useful as a means of directing errors to
   the list maintainer rather than the message originator.

リターンパスのメールボックスが実際の送付者のメールボックスと異なるのは、例えば可能です、誤り応答がメッセージ送付者にというよりむしろ特別なエラー処理メールボックスに提供されることであるなら。 メーリングリストがかかわるとき、このアレンジメントは、メッセージ創始者よりむしろリスト維持装置に誤りを向ける手段として一般的であって、役に立ちます。

   The text above implies that the final mail data will begin with a
   return path line, followed by one or more time stamp lines.  These
   lines will be followed by the mail data headers and body [32].

上のテキストは、最終的なメールデータが1つ以上のタイムスタンプ系列があとに続いたリターンパス線で始まるのを含意します。 メールデータヘッダーとボディー[32]はこれらの系列を支えるでしょう。

   It is sometimes difficult for an SMTP server to determine whether or
   not it is making final delivery since forwarding or other operations
   may occur after the message is accepted for delivery.  Consequently,

SMTPサーバーが、それが配送のためにメッセージを受け入れた後に推進か他の操作が起こるかもしれないので最終的な配送をしているかどうか決定するのは、時々難しいです。 その結果

Klensin                     Standards Track                    [Page 50]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   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.


   A message-originating SMTP system SHOULD NOT send a message that
   already contains a Return-path header.  SMTP servers performing a
   relay function MUST NOT inspect the message data, and especially not
   to the extent needed to determine if Return-path headers are present.
   SMTP servers making final delivery MAY remove Return-path headers
   before adding their own.

SHOULD NOTが既にReturn-経路ヘッダーを含むメッセージを送るメッセージを溯源するSMTPシステム。 リレー機能を実行するSMTPサーバーはメッセージデータを点検してはいけません、そして、特に確認するのに必要であるいずれの範囲にもReturn-経路ヘッダーは出席していません。 それら自身のを加える前に、最終的な配送をするSMTPサーバーはReturn-経路ヘッダーを取り除くかもしれません。

   The primary purpose of the Return-path is to designate the address to
   which messages indicating non-delivery or other mail system failures
   are to be sent.  For this to be unambiguous, exactly one return path
   SHOULD be present when the message is delivered.  Systems using RFC
   822 syntax with non-SMTP transports SHOULD designate an unambiguous
   address, associated with the transport envelope, to which error
   reports (e.g., non-delivery messages) should be sent.

Return-経路のプライマリ目的は送られる非配送か他のメールシステム障害を示すメッセージがことであるアドレスを指定することです。 これが明白なまさに1つのリターンパスのSHOULDであるには、メッセージが提供されたら、存在してください。 SHOULDが輸送封筒に関連づけられた明白なアドレスを指定する非SMTP輸送があるRFC822構文をどのエラー・レポート(例えば、非配送メッセージ)に使用するシステムを送るべきです。

   Historical note: Text in RFC 822 that appears to contradict the use
   of the Return-path header (or the envelope reverse path address from
   the MAIL command) as the destination for error messages is not
   applicable on the Internet.  The reverse path address (as copied into
   the Return-path) MUST be used as the target of any mail containing
   delivery error messages.

歴史的な注意: エラーメッセージのための目的地としてReturn-経路ヘッダー(または、メールコマンドからの封筒逆経路アドレス)の使用に矛盾するように見えるRFC822のテキストはインターネットで適切ではありません。 配送エラーメッセージを含むどんなメールの目標としても逆の経路アドレス(Return-経路にコピーされるように)を使用しなければなりません。

   In particular:


   -  a gateway from SMTP->elsewhere SHOULD insert a return-path header,
      unless it is known that the "elsewhere" transport also uses
      Internet domain addresses and maintains the envelope sender
      address separately.

- ほかの場所のSMTP->SHOULDからのゲートウェイはリターンパスヘッダーを挿入します、「ほかの場所」という輸送がまた、インターネットドメインアドレスを使用して、別々に封筒送付者アドレスを維持するのが知られていない場合。

   -  a gateway from elsewhere->SMTP SHOULD delete any return-path
      header present in the message, and either copy that information to
      the SMTP envelope or combine it with information present in the
      envelope of the other transport system to construct the reverse
      path argument to the MAIL command in the SMTP envelope.

- SMTP封筒の->SMTP SHOULDが逆の経路議論を構成するためにメッセージに出席しているどんなリターンパスヘッダーも削除して、SMTP封筒にその情報をコピーするか、または情報が存在していた状態でもう片方の輸送システムの封筒でそれを結合するほかの場所からメールコマンドへのゲートウェイ。

   The server must give special treatment to cases in which the
   processing following the end of mail data indication is only
   partially successful.  This could happen if, after accepting several
   recipients and the mail data, the SMTP server finds that the mail
   data could be successfully delivered to some, but not all, of the
   recipients.  In such cases, the response to the DATA command MUST be
   an OK reply.  However, the SMTP server MUST compose and send an
   "undeliverable mail" notification message to the originator of the

サーバは単にメールデータ指示の終わりに続く処理が部分的にうまくいっている場合に特別な処理を与えなければなりません。 数人の受取人とメールデータを受け入れた後にSMTPサーバーが、首尾よくすべてではなく、何人かの受取人にメールデータを提供できたのがわかるなら、これは起こるかもしれません。 そのような場合、DATAコマンドへの応答はOK回答であるに違いありません。 しかしながら、SMTPサーバーは、「「非-提出物」メール」通知メッセージをメッセージの創始者に構成して、送らなければなりません。

Klensin                     Standards Track                    [Page 51]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   A single notification listing all of the failed recipients or
   separate notification messages MUST be sent for each failed
   recipient.  For economy of processing by the sender, the former is
   preferred when possible.  All undeliverable mail notification
   messages are sent using the MAIL command (even if they result from
   processing the obsolete SEND, SOML, or SAML commands) and use a null
   return path as discussed in section 3.7.

それぞれの失敗した受取人のために失敗した受取人か別々の通知メッセージのすべてを記載するただ一つの通知を送らなければなりません。 可能であるときに、送付者による処理の経済のために、前者は好まれます。 すべての「非-提出物」メール通知メッセージが、メールコマンドを使用することで(時代遅れのSEND、SOML、またはSAMLが命令する処理から生じても)送られて、セクション3.7で議論するようにヌルリターンパスを使用します。

   The time stamp line and the return path line are formally defined as


Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>

リターン経路線=、「リターンパス:」 FWS逆経路<CRLF>。

Time-stamp-line = "Received:" FWS Stamp <CRLF>

時間スタンプ線=「受け取りました」。 FWSは<CRLF>を押し込みます。

Stamp = From-domain By-domain Opt-info ";"  FWS date-time

「インフォメーションを選んでドメインのそばのドメインの=を押し込んでください」;、」 FWS日付-時間

      ; where "date-time" is as defined in [32]
      ; but the "obs-" forms, especially two-digit
      ; years, are prohibited in SMTP and MUST NOT be used.

; 「日付-時間」が[32]で定義されるようにあるところで。 しかし、"obs"は特に2ケタで形成されます。 何年も、SMTPで禁止して、使用してはいけません。

From-domain = "FROM" FWS Extended-Domain CFWS

ドメインからの=“FROM" FWS拡張ドメインCFWS

By-domain = "BY" FWS Extended-Domain CFWS

ドメインのそばの=“BY" FWS拡張ドメインCFWS

Extended-Domain = Domain /
           ( Domain FWS "(" TCP-info ")" ) /
           ( Address-literal FWS "(" TCP-info ")" )


TCP-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]


Via = "VIA" FWS Link CFWS


With = "WITH" FWS Protocol CFWS

=“WITH" FWSプロトコルCFWSと共に

ID = "ID" FWS String / msg-id CFWS


For = "FOR" FWS 1*( Path / Mailbox ) CFWS

=“FOR" FWS1*(経路/メールボックス)CFWSのために

Link = "TCP" / Addtl-Link
Addtl-Link = Atom
      ; Additional standard names for links are registered with the
         ; Internet Assigned Numbers Authority (IANA).  "Via" is
         ; primarily of value with non-Internet transports.  SMTP

Addtl="TCP"/リンクAddtl-リンク=原子をリンクしてください。 リンクへの追加標準の名前がともに記名される、。 インターネットは数の権威(IANA)を割り当てました。 を通して「」 あります。 主として非インターネット輸送がある価値について。 SMTP

Klensin                     Standards Track                    [Page 52]

RFC 2821             Simple Mail Transfer Protocol            April 2001


         ; servers SHOULD NOT use unregistered names.
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
      ; Additional standard names for protocols are registered with the
         ; Internet Assigned Numbers Authority (IANA).  SMTP servers
         ; SHOULD NOT use unregistered names.

; サーバSHOULD NOTは登録されていない名前を使用します。 Attdlプロトコル="ESMTP"/"SMTP"/プロトコルAttdl-プロトコルは原子と等しいです。 プロトコルのための追加標準の名前がともに記名される、。 インターネットは数の権威(IANA)を割り当てました。 SMTPサーバー。 SHOULD NOTは登録されていない名前を使用します。

4.5 Additional Implementation Issues

4.5 追加導入問題

4.5.1 Minimum Implementation

4.5.1 最小の実装

   In order to make SMTP workable, the following minimum implementation
   is required for all receivers.  The following commands MUST be
   supported to conform to this specification:

SMTPを実行可能にして、以下の最小の実装がすべての受信機に必要です。 この仕様に従うために以下のコマンドをサポートしなければなりません:



   Any system that includes an SMTP server supporting mail relaying or
   delivery MUST support the reserved mailbox "postmaster" as a case-
   insensitive local name.  This postmaster address is not strictly
   necessary if the server always returns 554 on connection opening (as
   described in section 3.1).  The requirement to accept mail for
   postmaster implies that RCPT commands which specify a mailbox for
   postmaster at any of the domains for which the SMTP server provides
   mail service, as well as the special case of "RCPT TO:<Postmaster>"
   (with no domain specification), MUST be supported.

メールがリレーか配送であるとサポートするSMTPサーバーを含んでいるどんなシステムもケースの神経の鈍い地方名として予約されたメールボックス「郵便局長」をサポートしなければなりません。 サーバが接続始まりの上でいつも554を返すなら(セクション3.1で説明されるように)、この郵便局長アドレスは厳密に必要ではありません。 郵便局長へのメールを受け入れるという要件は、SMTPサーバーがメールサービスを提供するドメインのどれか、および「RCPT TO:<郵便局長>」(ドメイン仕様のない)の特別なケースで郵便局長にメールボックスを指定するRCPTコマンドをサポートしなければならないのを含意します。

   SMTP systems are expected to make every reasonable effort to accept
   mail directed to Postmaster from any other system on the Internet.
   In extreme cases --such as to contain a denial of service attack or
   other breach of security-- an SMTP server may block mail directed to
   Postmaster.  However, such arrangements SHOULD be narrowly tailored
   so as to avoid blocking messages which are not part of such attacks.

SMTPシステムがインターネットにいかなる他のシステムからもPostmasterに向けられたメールを受け入れるためのあらゆる妥当な努力をすると予想されます。 極端な場合(セキュリティのサービス不能攻撃か他の不履行を含むようなもの)では、SMTPサーバーはPostmasterに向けられたメールを妨げるかもしれません。 しかしながら、そのようなアレンジメントSHOULDは狭くそうです。そのような攻撃の一部でないメッセージを妨げるのを避けるために、仕立てられます。

4.5.2 Transparency

4.5.2 透明

   Without some provision for data transparency, the character sequence
   "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
   In general, users are not aware of such "forbidden" sequences.  To

データ透明への何らかの支給がなければ、キャラクタシーケンス「<CRLF><CRLF>」を、メールテキストを終わらせて、ユーザは送ることができません。 一般に、ユーザは系列が「禁じられた」そのようなものを意識していません。 to

Klensin                     Standards Track                    [Page 53]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   allow all user composed text to be transmitted transparently, the
   following procedures are used:


   -  Before sending a line of mail text, the SMTP client checks the
      first character of the line.  If it is a period, one additional
      period is inserted at the beginning of the line.

- メールテキストの系列を送る前に、SMTPクライアントは系列の最初のキャラクタをチェックします。 それが期間であるなら、ある追加期間は系列の始めに挿入されます。

   -  When a line of mail text is received by the SMTP server, it checks
      the line.  If the line is composed of a single period, it is
      treated as the end of mail indicator.  If the first character is a
      period and there are other characters on the line, the first
      character is deleted.

- メールテキストの台詞がSMTPサーバーによって受けられるとき、それは系列をチェックします。 系列がただ一つの期間で構成されるなら、メールインディケータの終わりとして扱われます。 最初のキャラクタが期間であり、他のキャラクタが系列にあれば、最初のキャラクタは削除されます。

   The mail data may contain any of the 128 ASCII characters.  All
   characters are to be delivered to the recipient's mailbox, including
   spaces, vertical and horizontal tabs, and other control characters.
   If the transmission channel provides an 8-bit byte (octet) data
   stream, the 7-bit ASCII codes are transmitted right justified in the
   octets, with the high order bits cleared to zero.  See 3.7 for
   special treatment of these conditions in SMTP systems serving a relay

メールデータは128人のASCII文字のいずれも含むかもしれません。 すべてのキャラクタが空間、垂直で水平なタブ、および他の制御文字を含む受信者のメールボックスに提供されることになっています。 トランスミッションチャンネルがデータが流す8ビットのバイト(八重奏)を提供するなら、7ビットのASCIIコードは八重奏で正当化された、伝えられた権利です、高位のビットがゼロまできれいにされている状態で。 リレー機能を果たすSMTPシステムにおける、これらの状態の特別な処理に関して3.7を見てください。

   In some systems it may be necessary to transform the data as it is
   received and stored.  This may be necessary for hosts that use a
   different character set than ASCII as their local character set, that
   store data in records rather than strings, or which use special
   character sequences as delimiters inside mailboxes.  If such
   transformations are necessary, they MUST be reversible, especially if
   they are applied to mail being relayed.

いくつかのシステムでは、それが受け取られて、保存されるとき、データを変えるのが必要であるかもしれません。 これが彼らのローカルキャラクターセットとしてのASCIIより異なった文字集合を使用するホストに必要であるかもしれません(ストリングよりむしろ記録にデータを保存するか、またはデリミタとしてメールボックスの中に特殊文字系列を使用します)。 そのような変換が必要であるなら、特にリレーされるメールに適用されるなら、それらはリバーシブルであるに違いありません。

4.5.3 Sizes and Timeouts

4.5.3 サイズとタイムアウト Size limits and minimums サイズ限界と最小限

   There are several objects that have required minimum/maximum sizes.
   Every implementation MUST be able to receive objects of at least
   these sizes.  Objects larger than these sizes SHOULD be avoided when
   possible.  However, some Internet mail constructs such as encoded
   X.400 addresses [16] will often require larger objects: clients MAY
   attempt to transmit these, but MUST be prepared for a server to
   reject them if they cannot be handled by it.  To the maximum extent
   possible, implementation techniques which impose no limits on the
   length of these objects should be used.

最小の、または、最大のサイズを必要としたいくつかの目的があります。 あらゆる実装が少なくともこれらのサイズのオブジェクトを受け取ることができなければなりません。 これらより大きい目的はSHOULDを大きさで分けます。可能であるときに、避けられます。 しかしながら、コード化されたX.400アドレス[16]などのいくつかのインターネット・メール構造物がしばしばより大きいオブジェクトを必要とするでしょう: クライアントは、これらを伝えるのを試みるかもしれませんが、それで彼らを扱うことができないなら、サーバが彼らを拒絶する用意ができていなければなりません。 可能な最大の範囲実装のテクニックに、どれがこれらのオブジェクトの長さに限界を全く課さないかは使用されるべきです。

      The maximum total length of a user name or other local-part is 64


Klensin                     Standards Track                    [Page 54]

RFC 2821             Simple Mail Transfer Protocol            April 2001


      The maximum total length of a domain name or number is 255


      The maximum total length of a reverse-path or forward-path is 256
      characters (including the punctuation and element separators).


   command line
      The maximum total length of a command line including the command
      word and the <CRLF> is 512 characters.  SMTP extensions may be
      used to increase this limit.

コマンドラインがコマンドを含む最大の全長が言い表すコマンドラインと<CRLF>は512のキャラクタです。 SMTP拡張子は、この限界を増強するのに使用されるかもしれません。

   reply line
      The maximum total length of a reply line including the reply code
      and the <CRLF> is 512 characters.  More information may be
      conveyed through multiple-line replies.

回答コードと<CRLF>を含む回答の最大の全長が裏打ちする回答系列は512のキャラクタです。 詳しい情報は複数の系列回答で伝えられるかもしれません。

   text line
      The maximum total length of a text line including the <CRLF> is
      1000 characters (not counting the leading dot duplicated for
      transparency).  This number may be increased by the use of SMTP
      Service Extensions.

<CRLF>を含むテキストの最大の全長が裏打ちするテキスト系列は1000のキャラクタ(透明ためにコピーされた主なドットを数えないで)です。 この数はSMTP Service Extensionsの使用で増強されるかもしれません。

   message content
      The maximum total length of a message content (including any
      message headers as well as the message body) MUST BE at least 64K
      octets.  Since the introduction of Internet standards for
      multimedia mail [12], message lengths on the Internet have grown
      dramatically, and message size restrictions should be avoided if
      at all possible.  SMTP server systems that must impose
      restrictions SHOULD implement the "SIZE" service extension [18],
      and SMTP client systems that will send large messages SHOULD
      utilize it when possible.

メッセージの最大の全長が満足させる(メッセージ本体と同様にどんなメッセージヘッダーも含んでいます)メッセージ内容は少なくとも64Kの八重奏であるに違いありません。 マルチメディアメール[12]のインターネット標準の導入以来、インターネットのメッセージ長は劇的に成長しています、そして、できれば、メッセージサイズ制限は避けられるべきです。 制限SHOULDを課さなければならないSMTPサーバーシステムは、「サイズ」がサービス拡大[18]であると実装します、そして、可能であるときに、大きいメッセージを送るSMTPクライアントシステムはそれを利用するはずです。

   recipients buffer
      The minimum total number of recipients that must be buffered is
      100 recipients.  Rejection of messages (for excessive recipients)
      with fewer than 100 RCPT commands is a violation of this
      specification.  The general principle that relaying SMTP servers
      MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation
      tests on message headers suggests that rejecting a message based
      on the total number of recipients shown in header fields is to be
      discouraged.  A server which imposes a limit on the number of
      recipients MUST behave in an orderly fashion,  such as to reject
      additional addresses over its limit rather than silently
      discarding addresses previously accepted.  A client that needs to

受取人はバッファリングされているのが、100人の受取人であるということであるに違いない受取人の最小の総数をバッファリングします。 100未満のRCPTコマンドによるメッセージ(過度の受取人のための)の拒絶はこの仕様の違反です。 SMTPをリレーして、サーバがそうしてはいけない配送SMTPプロトコルのサーバSHOULD NOTがメッセージヘッダーの合法化テストを実行するという一般的な原則は、ヘッダーフィールドで見せられた受取人の総数に基づくメッセージを拒絶するのがお勧めできないことになっていると示唆します。 規則的なファッション(静かに以前に受け入れられたアドレスを捨てるより限界の上でむしろ追加アドレスを拒絶するようなもの)で受取人の数で指し値するサーバは振る舞わなければなりません。 必要があるクライアント

Klensin                     Standards Track                    [Page 55]

RFC 2821             Simple Mail Transfer Protocol            April 2001


      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.


   Errors due to exceeding these limits may be reported by using the
   reply codes.  Some examples of reply codes are:

これらの限界を超えているのによる誤りは、回答コードを使用することによって、報告されるかもしれません。 回答コードに関するいくつかの例は以下の通りです。

      500 Line too long.
      501 Path too long
      452 Too many recipients  (see below)
      552 Too much mail data.

500 あまりに長いときにあまりに長い間. 501Pathを裏打ちしてください。さもないと、452Too多くの受取人(以下を見ます)か552Tooはデータをたくさん郵送します。

   RFC 821 [30] incorrectly listed the error where an SMTP server
   exhausts its implementation limit on the number of RCPT commands
   ("too many recipients") as having reply code 552.  The correct reply
   code for this condition is 452.  Clients SHOULD treat a 552 code in
   this case as a temporary, rather than permanent, failure so the logic
   below works.

RCPTコマンド(「あまりに多くの受取人」)の数における実装限界が回答コード552を持っているとしてSMTPサーバー的でくたくたになるところにRFC821[30]は不当に誤りを記載しました。 この状態のための正しい回答コードは452です。 クライアントSHOULDはこの場合552コードを永久的であるというよりむしろ一時的にaとして扱って、失敗は以下の論理が扱うそうです。

   When a conforming SMTP server encounters this condition, it has at
   least 100 successful RCPT commands in its recipients buffer.  If the
   server is able to accept the message, then at least these 100
   addresses will be removed from the SMTP client's queue.  When the
   client attempts retransmission of those addresses which received 452
   responses, at least 100 of these will be able to fit in the SMTP
   server's recipients buffer.  Each retransmission attempt which is
   able to deliver anything will be able to dispose of at least 100 of
   these recipients.

従うSMTPサーバーがこの状態に遭遇すると、それには、受取人バッファにおける少なくとも100のうまくいっているRCPTコマンドがあります。 そして、少なくともサーバがメッセージを受け入れることができると、SMTPクライアントの待ち行列からこれらの100のアドレスを取り除くでしょう。 クライアントが452の応答を受けたそれらのアドレスの「再-トランスミッション」を試みるとき、少なくともこれらの100はSMTPサーバーの受取人バッファをうまくはめ込むことができるでしょう。 何でも提供できるそれぞれの「再-トランスミッション」試みは少なくともこれらの100人の受取人を処分できるでしょう。

   If an SMTP server has an implementation limit on the number of RCPT
   commands and this limit is exhausted, it MUST use a response code of
   452 (but the client SHOULD also be prepared for a 552, as noted
   above).  If the server has a configured site-policy limitation on the
   number of RCPT commands, it MAY instead use a 5XX response code.
   This would be most appropriate if the policy limitation was intended
   to apply if the total recipient count for a particular message body
   were enforced even if that message body was sent in multiple mail

SMTPサーバーがRCPTコマンドの数に実装限界を持って、この限界が疲れ果てるなら、452の応答コードを使用しなければならない、(クライアントSHOULD、また、552には、用意してください、上で述べたように) サーバがRCPTコマンドの数に構成されたサイト方針制限を持っているなら、それは代わりに5XX応答コードを使用するかもしれません。 複数のメールトランザクションでそのメッセージ本体を送ったとしても特定のメッセージ本体のための総受取人カウントを励行したなら方針制限が適用されるつもりであるなら、これは最も適切でしょうに。 Timeouts タイムアウト

   An SMTP client MUST provide a timeout mechanism.  It MUST use per-
   command timeouts rather than somehow trying to time the entire mail
   transaction.  Timeouts SHOULD be easily reconfigurable, preferably
   without recompiling the SMTP code.  To implement this, a timer is set

SMTPクライアントはタイムアウトメカニズムを提供しなければなりません。 使用しなければならない、-、時間までどうにか全体のメールトランザクションを試みるよりむしろタイムアウトを命令してください。 タイムアウトSHOULDは容易にそうです。望ましくは、SMTPコードを再コンパイルしないで、再構成可能です。 これを実装するために、タイマは設定されます。

Klensin                     Standards Track                    [Page 56]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   for each SMTP command and for each buffer of the data transfer.  The
   latter means that the overall timeout is inherently proportional to
   the size of the message.

それぞれのSMTPコマンドとデータ転送に関する各バッファのために。 後者は、総合的なタイムアウトが本来メッセージのサイズに比例していることを意味します。

   Based on extensive experience with busy mail-relay hosts, the minimum
   per-command timeout values SHOULD be as follows:


   Initial 220 Message: 5 minutes
      An SMTP client process needs to distinguish between a failed TCP
      connection and a delay in receiving the initial 220 greeting
      message.  Many SMTP servers accept a TCP connection but delay
      delivery of the 220 message until their system load permits more
      mail to be processed.

220メッセージに頭文字をつけてください: 5分のAn SMTPクライアントプロセスは、初期の220あいさつメッセージを受け取る失敗したTCP接続と遅れを見分ける必要があります。 それらのシステム・ロードが、より多くのメールが処理されることを許可するまで、多くのSMTPサーバーが、TCP接続を受け入れますが、220メッセージの配送を遅らせます。

   MAIL Command: 5 minutes

コマンドを郵送してください: 5分

   RCPT Command: 5 minutes
      A longer timeout is required if processing of mailing lists and
      aliases is not deferred until after the message was accepted.

RCPTは命令します: メッセージを受け入れた後までメーリングリストと別名の処理が延期されないなら、5分間のAより長いタイムアウトが必要です。

   DATA Initiation: 2 minutes
      This is while awaiting the "354 Start Input" reply to a DATA

データ開始: 2分のThisが「354スタート入力」回答をDATAコマンドにお待ちしている間、あります。

   Data Block: 3 minutes
      This is while awaiting the completion of each TCP SEND call
      transmitting a chunk of data.

データ・ブロック: 3分のThisがデータの塊を伝えながらそれぞれのTCP SEND呼び出しの完成を待っている間、あります。

   DATA Termination: 10 minutes.
      This is while awaiting the "250 OK" reply.  When the receiver gets
      the final period terminating the message data, it typically
      performs processing to deliver the message to a user mailbox.  A
      spurious timeout at this point would be very wasteful and would
      typically result in delivery of multiple copies of the message,
      since it has been successfully sent and the server has accepted
      responsibility for delivery.  See section 6.1 for additional

データ終了: 10 書き留めます。 これは「250OK」回答をお待ちしている間、あります。 ファイナルピリオドが受信機でメッセージデータを終えるとき、それは、ユーザメールボックスにメッセージを提供するために処理を通常実行します。 ここの偽りのタイムアウトは、非常に無駄であるだろう、メッセージの複本の配送を通常もたらすでしょう、首尾よくそれを送って、サーバが配送への責任を引き受けたので。 追加議論に関してセクション6.1を見てください。

   An SMTP server SHOULD have a timeout of at least 5 minutes while it
   is awaiting the next command from the sender.


4.5.4 Retry Strategies

4.5.4 再試行戦略

   The common structure of a host SMTP implementation includes user
   mailboxes, one or more areas for queuing messages in transit, and one
   or more daemon processes for sending and receiving mail.  The exact
   structure will vary depending on the needs of the users on the host

ホストSMTP実装の一般的な構造はユーザメールボックス、トランジットにおけるメッセージを列に並ばせるための1つ以上の領域、および送受信メールのための1つ以上のデーモンプロセスを含んでいます。 ホストの上のユーザの必要性によって、正確な構造は異なるでしょう。

Klensin                     Standards Track                    [Page 57]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   and the number and size of mailing lists supported by the host.  We
   describe several optimizations that have proved helpful, particularly
   for mailers supporting high traffic levels.

ホストによってサポートされたメーリングリストの数とサイズ。 私たちは特に高いトラフィックがレベルであるとサポートする郵送者において役立っていると判明したいくつかの最適化について説明します。

   Any queuing strategy MUST include timeouts on all activities on a
   per-command basis.  A queuing strategy MUST NOT send error messages
   in response to error messages under any circumstances.

どんな列を作り戦略も1コマンドあたり1個のベースにおけるすべての活動でのタイムアウトを含まなければなりません。 列を作り戦略はどうあってもエラーメッセージに対応してエラーメッセージを送ってはいけません。 Sending Strategy 送付戦略

   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

送付者は、1つの試みが失敗した後に特定の目的地を再試行するのを遅らせなければなりません。 一般に、少なくとも30が数分であったなら間隔SHOULDを再試行してください。 しかしながら、SMTPクライアントが非配送の理由を決定できるとき、より高度で可変な戦略は有益になるでしょう。

   Retries continue until the message is transmitted or the sender gives
   up; the give-up time generally needs to be at least 4-5 days.  The
   parameters to the retry algorithm MUST be configurable.

メッセージが送られるか、または送付者があきらめるまで、再試行は続きます。 一般に、上にあきらめ時間は、少なくとも4-5日間である必要があります。 再試行アルゴリズムへのパラメタは構成可能であるに違いありません。

   A client SHOULD keep a list of hosts it cannot reach and
   corresponding connection timeouts, rather than just retrying queued
   mail items.


   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.


   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

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


Klensin                     Standards Track                    [Page 58]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   An SMTP client may have a large queue of messages for each
   unavailable destination host.  If all of these messages were retried
   in every retry cycle, there would be excessive Internet overhead and
   the sending system would be blocked for a long period.  Note that an
   SMTP client can generally determine that a delivery attempt has
   failed only after a timeout of several minutes and even a one-minute
   timeout per connection will result in a very large delay if retries
   are repeated for dozens, or even hundreds, of queued messages to the
   same host.

SMTPクライアントには、それぞれの入手できないあて先ホストへのメッセージの大きい待ち行列があるかもしれません。 これらのメッセージのすべてがあらゆるリトライ・サイクルに再試行されるなら、過度のインターネット・オーバヘッドがあるでしょうに、そして、送付システムは長い間妨げられるでしょう。 一般に、SMTPクライアントが、再試行が同じホストに列に並ばせられたメッセージの数十、または何数百もさえ繰り返されると数分のタイムアウトと1接続あたり1回の1分のタイムアウトさえ非常に大きい遅れをもたらした後にだけ配送試みが失敗したと決心できることに注意してください。

   At the same time, SMTP clients SHOULD use great care in caching
   negative responses from servers.  In an extreme case, if EHLO is
   issued multiple times during the same SMTP connection, different
   answers may be returned by the server.  More significantly, 5yz
   responses to the MAIL command MUST NOT be cached.

同時に、SMTPクライアントSHOULDはサーバから否定応答をキャッシュする際に高度の注意を使用します。 はなはだしきに至っては、同じSMTP接続の間の複数の回をEHLOに発行するなら、サーバは異なった答えを返すかもしれません。よりかなり、メールコマンドへの5yz応答をキャッシュしてはいけません。

   When a mail message is to be delivered to multiple recipients, and
   the SMTP server to which a copy of the message is to be sent is the
   same for multiple recipients, then only one copy of the message
   SHOULD be transmitted.  That is, the SMTP client SHOULD use the
   command sequence:  MAIL, RCPT, RCPT,... RCPT, DATA instead of the
   sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA.  However, if there
   are very many addresses, a limit on the number of RCPT commands per
   MAIL command MAY be imposed.  Implementation of this efficiency
   feature is strongly encouraged.

提供されるメール・メッセージがことであるときには、複数の受取人、およびメッセージのコピーが複数の受取人にとって、送るのが同じであり、次に、メッセージの唯一のコピー1部がSHOULDであるということであるSMTPサーバーに、伝えられてください。 すなわち、SMTPクライアントSHOULDはコマンド・シーケンスを使用します: メール、RCPT、RCPT… RCPT、系列の代わりにDATA: メール、RCPT、データ…, メール、RCPT、データ。 しかしながら、非常に多くのアドレスがあれば、メールコマンドあたりのRCPTコマンドの数における限界は課されるかもしれません。 この効率機能の実装は強く奨励されます。

   Similarly, to achieve timely delivery, the SMTP client MAY support
   multiple concurrent outgoing mail transactions.  However, some limit
   may be appropriate to protect the host from devoting all its
   resources to mail.

同様に、タイムリーな配送を達成するために、SMTPクライアントは、複数の同時発生の送信するメールがトランザクションであるとサポートするかもしれません。 しかしながら、何らかの限界はすべてのリソースをメールにささげるのからホストを保護するのが適切であるかもしれません。 Receiving Strategy 受信戦略

   The SMTP server SHOULD attempt to keep a pending listen on the SMTP
   port at all times.  This requires the support of multiple incoming
   TCP connections for SMTP.  Some limit MAY be imposed but servers that
   cannot handle more than one SMTP transaction at a time are not in
   conformance with the intent of this specification.

未定のaを保つSMTPサーバーSHOULD試みはSMTPポートの上でいつも聴かれます。 これはSMTPのために複数の入って来るTCP接続のサポートを必要とします。 何らかの限界が課されるかもしれませんが、1つ以上のSMTPトランザクションを扱うことができないサーバは一度に、順応この仕様の意図を伴う中ではありません。

   As discussed above, when the SMTP server receives mail from a
   particular host address, it could activate its own SMTP queuing
   mechanisms to retry any mail pending for that host address.


4.5.5   Messages with a null reverse-path

4.5.5 逆経路であることでのヌルメッセージ

   There are several types of notification messages which are required
   by existing and proposed standards to be sent with a null reverse
   path, namely non-delivery notifications as discussed in section 3.7,


Klensin                     Standards Track                    [Page 59]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   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

他の種類のDelivery Status Notifications(DSNs)[24]、およびMessage Disposition Notifications(MDNs)[10]も。 これらの種類に関するメッセージのすべてが前のメッセージに関する通知です、そして、前のメール・メッセージの逆経路にそれらを送ります。 (そのような通知メッセージの配送が失敗するなら、通常、それは通知メッセージが扱われるホストのメールシステムに関する問題を示します。 この理由で、何人かのホストでは、MTAはメールシステムで問題を解決できるだれかにそのような失敗した通知メッセージを転送するためにセットアップされます、例えば、郵便局長別名で。)

   All other types of messages (i.e., any message which is not required
   by a standards-track RFC to have a null reverse-path) SHOULD be sent
   with with a valid, non-null reverse-path.


   Implementors of automated email processors should be careful to make
   sure that the various kinds of messages with null reverse-path are
   handled correctly, in particular such systems SHOULD NOT reply to
   messages with null reverse-path.

自動化されたメールプロセッサの作成者は逆経路であることでのヌル様々な種類に関するメッセージが正しく扱われて、逆経路であることでヌル特に、そのようなシステムSHOULD NOTがメッセージに答えるのを確実にするのに慎重であるはずです。

5. Address Resolution and Mail Handling

5. 解決を扱ってください、そして、取り扱いを郵送してください。

   Once an SMTP client lexically identifies a domain to which mail will
   be delivered for processing (as described in sections 3.6 and 3.7), a
   DNS lookup MUST be performed to resolve the domain name [22].  The
   names are expected to be fully-qualified domain names (FQDNs):
   mechanisms for inferring FQDNs from partial names or local aliases
   are outside of this specification and, due to a history of problems,
   are generally discouraged.  The lookup first attempts to locate an MX
   record associated with the name.  If a CNAME record is found instead,
   the resulting name is processed as if it were the initial name.  If
   no MX records are found, but an A RR is found, the A RR is treated as
   if it was associated with an implicit MX RR, with a preference of 0,
   pointing to that host.  If one or more MX RRs are found for a given
   name, SMTP systems MUST NOT utilize any A RRs associated with that
   name unless they are located using the MX RRs; the "implicit MX" rule
   above applies only if there are no MX records present.  If MX records
   are present, but none of them are usable, this situation MUST be
   reported as an error.

SMTPクライアントがいったん、辞書的に、メールが処理のために提供されるドメインを特定すると(セクション3.6と3.7で説明されるように)、ドメイン名[22]を決議するためにDNSルックアップを実行しなければなりません。 名前は完全修飾ドメイン名(FQDNs)であると予想されます: 部分的な名前かローカルの別名からFQDNsを推論するためのメカニズムは、この仕様の外にあって、一般に、問題の歴史のためがっかりしています。 ルックアップは、最初に、名前に関連しているMX記録の場所を見つけるのを試みます。 CNAME記録が代わりに見つけられるなら、結果として起こる名前はまるでそれが初期の名前であるかのように処理されます。 MX記録が全く見つけられませんが、A RRが見つけられるなら、まるでそれが内在しているMX RRに関連しているかのようにA RRは扱われます、0の優先で、そのホストを示して。 1MX RRsが名に関して見つけられて、彼らがMX RRsを使用することで見つけられていない場合、SMTPシステムはその名前に関連している少しのA RRsも利用してはいけません。 どんな存在しているMX記録もない場合にだけ、上の「内在しているMX」規則は適用されます。 MX記録が存在していますが、それらのいずれも使用可能でないなら、誤りとしてこの状況を報告しなければなりません。

   When the lookup succeeds, the mapping can result in a list of
   alternative delivery addresses rather than a single address, because
   of multiple MX records, multihoming, or both.  To provide reliable
   mail transmission, the SMTP client MUST be able to try (and retry)
   each of the relevant addresses in this list in order, until a
   delivery attempt succeeds.  However, there MAY also be a configurable
   limit on the number of alternate addresses that can be tried.  In any
   case, the SMTP client SHOULD try at least two addresses.

ルックアップが成功すると、マッピングはただ一つのアドレスよりむしろ代替の品物の配達先のリストをもたらすことができます、複数のMX記録、マルチホーミング、または両方のために。 信頼できるメール送信を提供するために、SMTPクライアントはこのリストのオーダーにおける、それぞれの関連アドレスを試みることができなければなりません(再試行してください)、配送試みが成功するまで。 しかしながら、また、構成可能な限界が試みることができる代替アドレスの数にあるかもしれません。 どのような場合でも、SMTPクライアントSHOULDは少なくとも2つのアドレスを試みます。

Klensin                     Standards Track                    [Page 60]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   Two types of information is used to rank the host addresses: multiple
   MX records, and multihomed hosts.

2つのタイプの情報はホスト・アドレスを格付けするのに使用されます: 複数のMX記録、および「マルチ-家へ帰」っているホスト。

   Multiple MX records contain a preference indication that MUST be used
   in sorting (see below).  Lower numbers are more preferred than higher
   ones.  If there are multiple destinations with the same preference
   and there is no clear reason to favor one (e.g., by recognition of an
   easily-reached address), then the sender-SMTP MUST randomize them to
   spread the load across multiple mail exchangers for a specific

複数のMX記録がソーティングに使用しなければならない好みの指示を含んでいます(以下を見てください)。 下側..数..以上..都合のよい..高い..もの 同じ好みがある複数の目的地があって、1つ(例えば、容易に達しているアドレスの認識による)を支持するどんな明確な理由もなければ、送付者-SMTP MUSTが、特定の組織のために複数のメール交換器の向こう側に負荷を広げるためにそれらをランダマイズします。

   The destination host (perhaps taken from the preferred MX record) may
   be multihomed, in which case the domain name resolver will return a
   list of alternative IP addresses.  It is the responsibility of the
   domain name resolver interface to have ordered this list by
   decreasing preference if necessary, and SMTP MUST try them in the
   order presented.

あて先ホスト(恐らく、都合のよいMX記録から、取る)は「マルチ-家へ帰」るかもしれません、その場合、ドメイン名レゾルバが代替のIPアドレスのリストを返すでしょう。 必要なら、好みを減少させることによってこのリストを注文したのが、ドメイン名レゾルバインタフェースの責任であり、SMTP MUSTは提示されたオーダーでそれらを試みます。

   Although the capability to try multiple alternative addresses is
   required, specific installations may want to limit or disable the use
   of alternative addresses.  The question of whether a sender should
   attempt retries using the different addresses of a multihomed host
   has been controversial.  The main argument for using the multiple
   addresses is that it maximizes the probability of timely delivery,
   and indeed sometimes the probability of any delivery; the counter-
   argument is that it may result in unnecessary resource use.  Note
   that resource use is also strongly determined by the sending strategy
   discussed in section

複数の代替アドレスを試みる能力が必要ですが、特定のインストールは、代替アドレスの使用を制限したいか、または無効にしたがっているかもしれません。 送付者が「マルチ-家へ帰」っているホストの異なったアドレスを使用することで再試行を試みるべきであるかどうかに関する質問は論議を呼んでいます。 複数のアドレスを使用するための主な議論はタイムリーな配送の確率、および本当に時々どんな配送の確率も最大にするということです。 カウンタ議論は不要なリソース使用をもたらすかもしれないということです。 また、リソース使用がセクション4.5.4で.1に議論した送付戦略で強く決定することに注意してください。

   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

SMTPサーバーがそれがメールeXchangerに指定されたaである目的地でメッセージを受け取るなら、SMTPによって提供された輸送環境の外に何らかのメカニズムを使用して、それは、メッセージ(潜在的に、後にMAIL FROM、そして/または、RCPT TOアドレスを書き直した)をリレーするか、メッセージの最終的な配送をするか、またはそれを渡すかもしれません。 もちろん、後者のどちらもMX記録のリストがさらに調べられるのを必要としません。

   If it determines that it should relay the message without rewriting
   the address, it MUST sort the MX records to determine candidates for
   delivery.  The records are first ordered by preference, with the
   lowest-numbered records being most preferred.  The relay host MUST
   then inspect the list for any of the names or addresses by which it
   might be known in mail transactions.  If a matching record is found,
   all records at that preference level and higher-numbered ones MUST be
   discarded from consideration.  If there are no records left at that
   point, it is an error condition, and the message MUST be returned as
   undeliverable.  If records do remain, they SHOULD be tried, best
   preference first, as described above.

アドレスを書き直さないでメッセージをリレーするべきであることを決定するなら、それは、配送の候補を決定するためにMX記録を分類しなければなりません。 最も低く番号付の記録が最も好まれている状態で、記録は最初に、好みで注文されます。 そして、中継ホストはそれがメールトランザクションで知られているかもしれない名前かアドレスのいずれがないかどうかもリストを点検しなければなりません。 合っている記録が見つけられるなら、考慮からその好みのレベルと、より高く番号付のものにおけるすべての記録を捨てなければなりません。 記録が全くその時残っていないなら、それはエラー条件です、そして、「非-提出物」としてメッセージを返さなければなりません。 記録は残っていて、それらはSHOULDです。上で最初に、説明されるとしての試験済みの、そして、最も良い好みになってください。

Klensin                     Standards Track                    [Page 61]

RFC 2821             Simple Mail Transfer Protocol            April 2001


6. Problem Detection and Handling

6. 問題検出と取り扱い

6.1 Reliable Delivery and Replies by Email

6.1 メールによる信頼できる配信と回答

   When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
   message in response to DATA), it is accepting responsibility for
   delivering or relaying the message.  It must take this responsibility
   seriously.  It MUST NOT lose the message for frivolous reasons, such
   as because the host later crashes or because of a predictable
   resource shortage.

受信機-SMTPが1つのメール(データに対応して「250OK」メッセージを送るのによる)を受け入れるとき、それはメッセージを提供するか、またはリレーすることへの責任を引き受けています。 それは真剣にこの責任を受け止めなければなりません。 それはホストが後でダウンするか、予測できるリソース不足などの軽薄な理由でメッセージを失ってはいけません。

   If there is a delivery failure after acceptance of a message, the
   receiver-SMTP MUST formulate and mail a notification message.  This
   notification MUST be sent using a null ("<>") reverse path in the
   envelope.  The recipient of this notification MUST be the address
   from the envelope return path (or the Return-Path: line).  However,
   if this address is null ("<>"), the receiver-SMTP MUST NOT send a
   notification.  Obviously, nothing in this section can or should
   prohibit local decisions (i.e., as part of the same system
   environment as the receiver-SMTP) to log or otherwise transmit
   information about null address events locally if that is desired.  If
   the address is an explicit source route, it MUST be stripped down to
   its final hop.

配信障害がメッセージの承認の後にあれば、受信機-SMTP MUSTは通知メッセージを定式化して、郵送します。 この通知に封筒のヌル(「<>」)逆の経路を使用させなければなりません。 この通知の受取人は封筒リターンパスからのアドレスであるに違いありません(Return-経路: 立ち並んでください)。 しかしながら、このアドレスがヌルであるなら(「<>」)、受信機-SMTPは通知書を送ってはいけません。 明らかに、禁止できるべきであるか、またはそれが望まれているなら、このセクションの何も局所的に空アドレスイベントの情報を登録するか、またはそうでなければ伝えるというローカルの決定(すなわち、受信機-SMTPと同じシステム環境の一部としての)を禁止するべきではありません。 アドレスが明白な送信元経路であるなら、それを最終的なホップまで剥取らなければなりません。

   For example, suppose that an error notification must be sent for a
   message that arrived with:


      MAIL FROM:<@a,@b:user@d>

メール FROM:<@a 、@b: ユーザ@d>。

   The notification message MUST be sent using:


      RCPT TO:<user@d>

RCPT TO:<user@d 、gt。

   Some delivery failures after the message is accepted by SMTP will be
   unavoidable.  For example, it may be impossible for the receiving
   SMTP server to validate all the delivery addresses in RCPT command(s)
   due to a "soft" domain system error, because the target is a mailing
   list (see earlier discussion of RCPT), or because the server is
   acting as a relay and has no immediate access to the delivering

メッセージがSMTPによって受け入れられた後にいくつかの配信障害が避けられなくなるでしょう。 例えば、受信SMTPサーバーが「柔らかい」ドメインシステム・エラーによるRCPTコマンドにおけるすべての品物の配達先を有効にするのは、不可能であるかもしれません、サーバが目標がメーリングリスト(RCPTの以前の議論を見る)である、リレーとして機能していて、またはどんな即座のアクセスも配送システムに持っていないので。

   To avoid receiving duplicate messages as the result of timeouts, a
   receiver-SMTP MUST seek to minimize the time required to respond to
   the final <CRLF>.<CRLF> end of data indicator.  See RFC 1047 [28] for
   a discussion of this problem.

CRLF>データインディケータの<CRLF>エンドを最終的な<に反応させるのに必要である時間を最小にするためにタイムアウトでは、受信機-SMTP MUSTが探すという結果として写しメッセージを受け取るのを避けるために。 この問題の議論のためのRFC1047[28]を見てください。

Klensin                     Standards Track                    [Page 62]

RFC 2821             Simple Mail Transfer Protocol            April 2001


6.2 Loop Detection

6.2 輪の検出

   Simple counting of the number of "Received:" headers in a message has
   proven to be an effective, although rarely optimal, method of
   detecting loops in mail systems.  SMTP servers using this technique
   SHOULD use a large rejection threshold, normally at least 100
   Received entries.  Whatever mechanisms are used, servers MUST contain
   provisions for detecting and stopping trivial loops.

「受け取った」数の簡単な勘定 有効です、めったに最適ではありませんが、検出のメソッドはメールシステムで輪にされます。中のメッセージが判明したヘッダー、このテクニックSHOULDを使用するSMTPサーバーが大きい拒絶敷居、通常少なくとも100のReceivedエントリーを使用します。 いかなるメカニズムも使用されていても、サーバは些細な輪を検出して、止めるための条項を含まなければなりません。

6.3 Compensating for Irregularities

6.3 不規則を補うこと。

   Unfortunately, variations, creative interpretations, and outright
   violations of Internet mail protocols do occur; some would suggest
   that they occur quite frequently.  The debate as to whether a well-
   behaved SMTP receiver or relay should reject a malformed message,
   attempt to pass it on unchanged, or attempt to repair it to increase
   the odds of successful delivery (or subsequent reply) began almost
   with the dawn of structured network mail and shows no signs of
   abating.  Advocates of rejection claim that attempted repairs are
   rarely completely adequate and that rejection of bad messages is the
   only way to get the offending software repaired.  Advocates of
   "repair" or "deliver no matter what" argue that users prefer that
   mail go through it if at all possible and that there are significant
   market pressures in that direction.  In practice, these market
   pressures may be more important to particular vendors than strict
   conformance to the standards, regardless of the preference of the
   actual developers.

残念ながら、インターネットメールプロトコルの変化、創造的な解釈、および完全な違反は起こります。 或るものは、それらがかなり頻出するのを示すでしょう。 よく振る舞っているSMTP受信機かリレーが、うまくいっている配送(または、その後の回答)の可能性を増強するために奇形のメッセージを拒絶するはずであるか、変わりがない状態でそれを伝えるのを試みるはずであるか、またはそれを修理するのを試みるはずであるかに関する討論はほとんど構造化されたネットワークメールとショーの夜明けで減少のサインを全く始めませんでした。 拒絶の支持者は試みられた修理が完全にめったに適切であるというわけではなく、悪いメッセージの拒絶が間違っているソフトウェアを修理させる唯一の方法であると主張します。 「修理」か「たとえ何があっても、配送してください」の支持者は、ユーザができれば、メールがひどい目に遭って、重要な市場圧がその方向にあるのを好むと主張します。 実際には、これらの市場圧は規格への厳しい順応より特定のベンダーに重要であるかもしれません、実際の開発者の好みにかかわらず。

   The problems associated with ill-formed messages were exacerbated by
   the introduction of the split-UA mail reading protocols [3, 26, 5,
   21].  These protocols have encouraged the use of SMTP as a posting
   protocol, and SMTP servers as relay systems for these client hosts
   (which are often only intermittently connected to the Internet).
   Historically, many of those client machines lacked some of the
   mechanisms and information assumed by SMTP (and indeed, by the mail
   format protocol [7]).  Some could not keep adequate track of time;
   others had no concept of time zones; still others could not identify
   their own names or addresses; and, of course, none could satisfy the
   assumptions that underlay RFC 822's conception of authenticated

不適格なメッセージに関連している問題は分裂-UAメール読書プロトコル[3、26、5、21]の導入で悪化させられました。 これらのプロトコルは任命プロトコルとしてのSMTP、およびこれらのクライアントホストのリレー方式としてのSMTPサーバー(しばしば断続的にインターネットに関連づけられるだけである)の使用を奨励しました。 そして、歴史的に、それらのクライアントマシンの多くがSMTPによって想定されたメカニズムと何らかの情報を欠いていた、(本当に、メール書式で、[7])について議定書の中で述べてください。 或るものは時間の適切な道を保つことができませんでした。 他のものには、時間帯の概念が全くありませんでした。 それでも、他のものはそれら自身の名前かアドレスを特定できませんでした。 もちろん、そして、なにもRFC822の認証されたアドレスに関する概念を下に置いた仮定は満たすことができませんでした。

   In response to these weak SMTP clients, many SMTP systems now
   complete messages that are delivered to them in incomplete or
   incorrect form.  This strategy is generally considered appropriate
   when the server can identify or authenticate the client, and there
   are prior agreements between them.  By contrast, there is at best
   great concern about fixes applied by a relay or delivery SMTP server
   that has little or no knowledge of the user or client machine.

これらの弱いSMTPクライアントに対応して、多くのSMTPシステムが今、不完全であるか不正確なフォームでそれらに提供されるメッセージを完成します。 サーバがクライアントを特定するか、または認証できて、それらの間に事前同意があるとき、一般に、この戦略は適切であると考えられます。 対照的に、まずユーザかクライアントマシンに関する知識を持っていないリレーか配送SMTPサーバによって適用されたフィックスに関してせいぜい大きな心配があります。

Klensin                     Standards Track                    [Page 63]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   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:


   -  Addition of a message-id field when none appears

- なにもであるときに、メッセージイド分野の追加は現れます。

   -  Addition of a date, time or time zone when none appears

- なにもであるときに、日付、時間または時間帯の追加は現れます。

   -  Correction of addresses to proper FQDN format

- 適切なFQDN形式へのアドレスの修正

   The less information the server has about the client, the less likely
   these changes are to be correct and the more caution and conservatism
   should be applied when considering whether or not to perform fixes
   and how.  These changes MUST NOT be applied by an SMTP server that
   provides an intermediate relay function.

サーバがクライアントに関して持っている情報が少なければ少ないほど、これらの変化は正しいことになっていなさそうにはありません、そして、フィックスとどのようにを実行するかどうか考えるとき、より多くの警告と保守主義は申し込まれるべきです。 これらの変化は中間的リレー機能を提供するSMTPサーバーによって当てはまられてはいけません。

   In all cases, properly-operating clients supplying correct
   information are preferred to corrections by the SMTP server.  In all
   cases, documentation of actions performed by the servers (in trace
   fields and/or header comments) is strongly encouraged.

すべての場合では、正確な情報を提供する適切に稼働しているクライアントは修正より. Inがすべてケースに入れるSMTPサーバーによって好まれて、サーバ(跡の分野、そして/または、ヘッダーコメントにおける)によって実行された動作のドキュメンテーションは強く奨励されます。

7. Security Considerations

7. セキュリティ問題

7.1 Mail Security and Spoofing

7.1 メールセキュリティとスプーフィング

   SMTP mail is inherently insecure in that it is feasible for even
   fairly casual users to negotiate directly with receiving and relaying
   SMTP servers and create messages that will trick a naive recipient
   into believing that they came from somewhere else.  Constructing such
   a message so that the "spoofed" behavior cannot be detected by an
   expert is somewhat more difficult, but not sufficiently so as to be a
   deterrent to someone who is determined and knowledgeable.
   Consequently, as knowledge of Internet mail increases, so does the
   knowledge that SMTP mail inherently cannot be authenticated, or
   integrity checks provided, at the transport level.  Real mail
   security lies only in end-to-end methods involving the message
   bodies, such as those which use digital signatures (see [14] and,
   e.g., PGP [4] or S/MIME [31]).

かなりカジュアルなユーザさえ直接、SMTPサーバーを受け取って、リレーすると交渉して、ナイーブな受取人が、他のどこかから来たと信じているようにだますメッセージを作成するのが、可能であるので、SMTPメールは本来不安定です。 そのようなメッセージを構成するのは、いくらか難しいのですが、専門家が「偽造している」振舞いを検出できないくらい断固としてだれか博識な人への抑止力になるように十分難しいというわけではありません。 その結果、インターネット・メールに関する知識が増加するのに従って、本来SMTPメールを認証できなかったか、または保全チェックが提供されたという知識もそうします、輸送レベルで。 そして、本当のメールセキュリティが単に終わりから終わりへのメッセージ本体を伴うメソッドであります、デジタル署名を使用するものなどのように([14]を見てください、例えば、PGP[4]かS/MIME[31])。

   Various protocol extensions and configuration options that provide
   authentication at the transport level (e.g., from an SMTP client to
   an SMTP server) improve somewhat on the traditional situation
   described above.  However, unless they are accompanied by careful
   handoffs of responsibility in a carefully-designed trust environment,
   they remain inherently weaker than end-to-end mechanisms which use
   digitally signed messages rather than depending on the integrity of
   the transport system.

輸送レベル(例えば、SMTPクライアントからSMTPサーバーまでの)で認証を提供する様々なプロトコル拡大と設定オプションが上で説明された伝統的な状況をいくらか改良します。 しかしながら、入念に設計された信頼環境における責任の慎重なhandoffsによって伴われない場合、それらは本来輸送システムの保全によるより終わりから終わりへのむしろデジタルに署名しているメッセージを使用するメカニズムより弱いままで残っています。

Klensin                     Standards Track                    [Page 64]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   Efforts to make it more difficult for users to set envelope return
   path and header "From" fields to point to valid addresses other than
   their own are largely misguided: they frustrate legitimate
   applications in which mail is sent by one user on behalf of another
   or in which error (or normal) replies should be directed to a special
   address.  (Systems that provide convenient ways for users to alter
   these fields on a per-message basis should attempt to establish a
   primary and permanent mailbox address for the user so that Sender
   fields within the message data can be generated sensibly.)

ユーザが、封筒リターンパスとヘッダー“From"分野にそれら自身のを除いた有効なアドレスを示すように設定するのをより難しくする取り組みは主に指導を誤られます: 彼らはメールが別のものを代表して1人のユーザによって送られるか、または誤り(または、標準)回答が特別なアドレスに向けられるべきである正統のアプリケーションをだめにします。 (ユーザが1メッセージあたり1個のベースでこれらの分野を変更する便利な方法を提供するシステムは、分別よくメッセージデータの中のSender分野を生成することができて、ユーザのためにプライマリの、そして、永久的なメールボックスアドレスを確立するのを試みるはずです。)

   This specification does not further address the authentication issues
   associated with SMTP other than to advocate that useful functionality
   not be disabled in the hope of providing some small margin of
   protection against an ignorant user who is trying to fake mail.


7.2 "Blind" Copies

7.2 「盲目」のコピー

   Addresses that do not appear in the message headers may appear in the
   RCPT commands to an SMTP server for a number of reasons.  The two
   most common involve the use of a mailing address as a "list exploder"
   (a single address that resolves into multiple addresses) and the
   appearance of "blind copies".  Especially when more than one RCPT
   command is present, and in order to avoid defeating some of the
   purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
   the full set of RCPT command arguments into the headers, either as
   part of trace headers or as informational or private-extension
   headers.  Since this rule is often violated in practice, and cannot
   be enforced, sending SMTP systems that are aware of "bcc" use MAY
   find it helpful to send each blind copy as a separate message
   transaction containing only a single RCPT command.

メッセージヘッダーに現れないアドレスはRCPTコマンドにSMTPサーバーにおいて様々な意味で現れるかもしれません。 2、ほとんどのコモンが「リスト発破器」(複数のアドレスに変えるただ一つのアドレス)としての郵送先住所の使用と「盲目のコピー」の外観にかかわります。 特に1つ以上のRCPTコマンドが存在しているとき、これらのメカニズムの目的のいくつかをくつがえすのを避けるために、SMTPクライアントとサーバSHOULD NOTは跡のヘッダーの一部とした、または、ヘッダーか、情報としたRCPTコマンド議論か個人的な拡張ヘッダーのフルセットをコピーします。 この規則に実際にはしばしば違反して、励行できないので、"bcc"使用を意識している送付SMTPシステムは、ただ一つのRCPTコマンドだけを含む別々のメッセージトランザクションとしてそれぞれの盲目のコピーを送るのに役立っているのがわかるかもしれません。

   There is no inherent relationship between either "reverse" (from
   MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
   transaction ("envelope") and the addresses in the headers.  Receiving
   systems SHOULD NOT attempt to deduce such relationships and use them
   to alter the headers of the message for delivery.  The popular
   "Apparently-to" header is a violation of this principle as well as a
   common source of unintended information disclosure and SHOULD NOT be

SMTPトランザクション(「封筒」)の「逆(メール、SAMLなどからのコマンド)」の、または、「前進」の(RCPT)アドレスとアドレスとのどんな固有の関係もヘッダーにありません。 受電方式SHOULD NOTは配送へのメッセージのヘッダーを変更するのにそのような関係を推論して、それらを使用するのを試みます。 」 ヘッダーは故意でない情報公開とSHOULD NOTの共通ソースと同様にこの原則の違反です。ポピュラーである、「明らかである、-、使用されます。

7.3 VRFY, EXPN, and Security

7.3 VRFY、EXPN、およびセキュリティ

   As discussed in section 3.5, individual sites may want to disable
   either or both of VRFY or EXPN for security reasons.  As a corollary
   to the above, implementations that permit this MUST NOT appear to
   have verified addresses that are not, in fact, verified.  If a site

セクション3.5で議論するように、個々のサイトは安全保障上の理由でVRFYかEXPNのどちらかか両方を無効にしたがっているかもしれません。 上記での推論として、これを可能にする実装は事実上、確かめられないアドレスについて確かめたように見えてはいけません。 サイトです。

Klensin                     Standards Track                    [Page 65]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   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.


   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

構文だけがないかどうかそれをチェックした後にアドレスがVRFYコマンドで記載されている状態で250回答コードを返すと、この規則は違反されます。 もちろん、アドレスが有効であるか否かに関係なく、VRFYをいつも戻っている550「サポートする」実装は順応で等しくそうしていません。

   Within the last few years, the contents of mailing lists have become
   popular as an address information source for so-called "spammers."
   The use of EXPN to "harvest" addresses has increased as list
   administrators have installed protections against inappropriate uses
   of the lists themselves.  Implementations SHOULD still provide
   support for EXPN, but sites SHOULD carefully evaluate the tradeoffs.
   As authentication mechanisms are introduced into SMTP, some sites may
   choose to make EXPN available only to authenticated requestors.

ここ数年以内に、メーリングリストの内容はいわゆる「スパマー」のためのアドレスの情報源としてポピュラーになりました。 リスト管理者がリスト自体の不適当な用途に対する保護をインストールするのに従って、「収穫」アドレスへのEXPNの使用は増加しました。 実装SHOULDはまだEXPNのサポートを提供していますが、サイトSHOULDは慎重に見返りを評価します。 認証機構がSMTPに紹介されるとき、いくつかのサイトが、EXPNを認証された要請者だけに利用可能にするのを選ぶかもしれません。

7.4 Information Disclosure in Announcements

7.4 発表における情報公開

   There has been an ongoing debate about the tradeoffs between the
   debugging advantages of announcing server type and version (and,
   sometimes, even server domain name) in the greeting response or in
   response to the HELP command and the disadvantages of exposing
   information that might be useful in a potential hostile attack.  The
   utility of the debugging information is beyond doubt.  Those who
   argue for making it available point out that it is far better to
   actually secure an SMTP server rather than hope that trying to
   conceal known vulnerabilities by hiding the server's precise identity
   will provide more protection.  Sites are encouraged to evaluate the
   tradeoff with that issue in mind; implementations are strongly
   encouraged to minimally provide for making type and version
   information available in some way to other network hosts.

挨拶応答かHELPコマンドに対応してサーバタイプとバージョン(そして、時々同等のサーバドメイン名)を発表するデバッグ有利な立場の間には、見返りの進行中の討論がありました、そして、情報がそれであると暴露する損失は潜在的敵対的な攻撃で役に立つかもしれません。 デバッグ情報に関するユーティリティは疑問を超えています。 それを利用可能にするように論争する人は、サーバの正確なアイデンティティを隠すことによって知られている脆弱性を隠そうとするなら、より多くの保護が提供されることを望んでいるより実際にむしろSMTPサーバーを保証するのがはるかに良いと指摘します。 サイトが念頭でその問題で見返りを評価するよう奨励されます。 実装が他のネットワークホストへの何らかの方法で手があいている作成タイプとバージョン情報に最少量で備えるよう強く奨励されます。

7.5 Information Disclosure in Trace Fields

7.5 跡の分野での情報公開

   In some circumstances, such as when mail originates from within a LAN
   whose hosts are not directly on the public Internet, trace
   ("Received") fields produced in conformance with this specification
   may disclose host names and similar information that would not
   normally be available.  This ordinarily does not pose a problem, but
   sites with special concerns about name disclosure should be aware of
   it.  Also, the optional FOR clause should be supplied with caution or
   not at all when multiple recipients are involved lest it
   inadvertently disclose the identities of "blind copy" recipients to

メールが中から、ホストが直接公共のインターネットにいないLANを溯源する時などのいくつかの事情では、順応でこの仕様で生産された跡(「受信する」)の分野は通常、利用可能でないホスト名と同様の情報を明らかにするかもしれません。 これは通常問題を設定しませんが、名前公開に関する特別な心配があるサイトはそれを意識しているべきです。 また、うっかり「盲目のコピー」受取人のアイデンティティを他のものに明らかにするといけないので複数の受取人がかかわるとき、任意のFOR節を慎重か全く提供するべきではありません。

Klensin                     Standards Track                    [Page 66]

RFC 2821             Simple Mail Transfer Protocol            April 2001


7.6 Information Disclosure in Message Forwarding

7.6 メッセージ推進における情報公開

   As discussed in section 3.4, use of the 251 or 551 reply codes to
   identify the replacement address associated with a mailbox may
   inadvertently disclose sensitive information.  Sites that are
   concerned about those issues should ensure that they select and
   configure servers appropriately.

セクション3.4で議論するように、メールボックスに関連している交換アドレスを特定する251か551の回答コードの使用はうっかり機密情報を明らかにするかもしれません。 それらの問題に関して心配しているサイトは適切にサーバを選択して、構成するのを確実にするべきです。

7.7 Scope of Operation of SMTP Servers

7.7 SMTPサーバの操作の範囲

   It is a well-established principle that an SMTP server may refuse to
   accept mail for any operational or technical reason that makes sense
   to the site providing the server.  However, cooperation among sites
   and installations makes the Internet possible.  If sites take
   excessive advantage of the right to reject traffic, the ubiquity of
   email availability (one of the strengths of the Internet) will be
   threatened; considerable care should be taken and balance maintained
   if a site decides to be selective about the traffic it will accept
   and process.

サーバを提供するサイトに理解できるのは、SMTPサーバーが、どんな操作上的、または、技術的な理由でもメールを受け入れるのを拒否するかもしれないという安定している原則です。しかしながら、サイトとインストールの中の協力で、インターネットは可能になります。 サイトが過度の利点を活用すると、トラフィック、メールの有用性の偏在を拒絶する権利では、(インターネットの強さの1つ)は脅かされるでしょう。 かなりの注意が払われるべきであり、バランスはサイトが、トラフィックに関して選択していると決めると、それが受け入れて、処理されると主張しました。

   In recent years, use of the relay function through arbitrary sites
   has been used as part of hostile efforts to hide the actual origins
   of mail.  Some sites have decided to limit the use of the relay
   function to known or identifiable sources, and implementations SHOULD
   provide the capability to perform this type of filtering.  When mail
   is rejected for these or other policy reasons, a 550 code SHOULD be
   used in response to EHLO, MAIL, or RCPT as appropriate.

近年、任意のサイトを通したリレー機能の使用は、メールの実際の発生源を隠すのに敵対的な取り組みの一部として使用されました。 いくつかのサイトが、リレー機能の使用を知られているか身元保証可能なソースに制限すると決めました、そして、実装SHOULDはこのタイプのフィルタリングを実行する能力を前提とします。 メールがいつこれらのために拒絶されるか、そして、他の方針が推論します、550コードSHOULD。EHLO、メール、またはRCPTに対応して、適宜使用されてください。

8. IANA Considerations

8. IANA問題

   IANA will maintain three registries in support of this specification.
   The first consists of SMTP service extensions with the associated
   keywords, and, as needed, parameters and verbs.  As specified in
   section 2.2.2, no entry may be made in this registry that starts in
   an "X".  Entries may be made only for service extensions (and
   associated keywords, parameters, or verbs) that are defined in
   standards-track or experimental RFCs specifically approved by the
   IESG for this purpose.

IANAはこの仕様を支持して3つの登録を維持するでしょう。 1番目は必要に応じて関連キーワード、パラメタ、および動詞でSMTPサービス拡張子から成ります。 セクション2.2.2で指定されるように、「X」で始まるこの登録でエントリーを全くしないかもしれません。 標準化過程かIESGによって明確にこのために承認された実験的なRFCsで定義されるサービス拡大(そして、関連キーワード、パラメタ、または動詞)のためだけにエントリーをするかもしれません。

   The second registry consists of "tags" that identify forms of domain
   literals other than those for IPv4 addresses (specified in RFC 821
   and in this document) and IPv6 addresses (specified in this
   document).  Additional literal types require standardization before
   being used; none are anticipated at this time.

2番目の登録はIPv4アドレス(RFC821に本書では指定される)とIPv6アドレス(本書では指定される)のためのそれら以外のドメインリテラルのフォームを特定する「タグ」から成ります。 使用される前に追加文字通りのタイプは標準化を必要とします。 なにもこのとき、予期されません。

   The third, established by RFC 821 and renewed by this specification,
   is a registry of link and protocol identifiers to be used with the
   "via" and "with" subclauses of the time stamp ("Received: header")

」 タイムスタンプの“with" subclausesを通してRFC821によって設立されて、この仕様で更新された3番目が使用されるリンクとプロトコル識別子の登録である、「。(「: ヘッダーを受けます」)

Klensin                     Standards Track                    [Page 67]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   described in section 4.4.  Link and protocol identifiers in addition
   to those specified in this document may be registered only by
   standardization or by way of an RFC-documented, IESG-approved,
   Experimental protocol extension.

セクション4.4で、説明されます。 リンクしてください。そうすれば、本書では指定されたものに加えたプロトコル識別子は単に標準化かRFCによって記録されて、IESGによって承認されたExperimentalプロトコル拡張子を通して登録されてもよいです。

9. References

9. 参照

   [1]  American National Standards Institute (formerly United States of
        America Standards Institute), X3.4, 1968, "USA Code for
        Information Interchange". ANSI X3.4-1968 has been replaced by
        newer versions with slight modifications, but the 1968 version
        remains definitive for the Internet.

[1]American National Standards Institut(以前アメリカ合衆国規格研究所)、X3.4、1968、「米国情報交換用符号。」 わずかな変更でANSI X3.4-1968をより新しいバージョンに取り替えましたが、1968年のバージョンはインターネットに決定的に残っています。

   [2]  Braden, R., "Requirements for Internet hosts - application and
        support", STD 3, RFC 1123, October 1989.

[2] ブレーデンと、R.と、「インターネット・ホスト--アプリケーションのための要件とサポート」、STD3、RFC1123、10月1989日

   [3]  Butler, M., Chase, D., Goldberger, J., Postel, J. and J.
        Reynolds, "Post Office Protocol - version 2", RFC 937, February

[3] バトラー、M.、チェイス、D.、Goldberger(J.、ポステル、J.、およびJ.レイノルズ)は「バージョン2インチ、RFC937、1985年オフィスプロトコル--2月を掲示します」。

   [4]  Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
        Message Format", RFC 2440, November 1998.

[4] カラスとJ.とDonnerhackeとL.とフィニーとH.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC2440、1998年11月。

   [5]  Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC
        1176, August 1990.

[5] クリスピン、M.、「バージョン2インチ、RFC1176、1990年対話的なメールアクセス・プロトコル--8月。」

   [6]  Crispin, M., "Internet Message Access Protocol - Version 4", RFC
        2060, December 1996.

[6] クリスピン、M.、「バージョン4インチ、RFC2060、1996年インターネットメッセージアクセス・プロトコル--12月。」

   [7]  Crocker, D., "Standard for the Format of ARPA Internet Text
        Messages", RFC 822, August 1982.

[7] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、RFC822、1982年8月。

   [8]  Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

[8] クロッカーとD.とP.Overell、Eds、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。

   [9]  De Winter, J., "SMTP Service Extension for Remote Message Queue
        Starting", RFC 1985, August 1996.

[9] De冬、J.、「リモートメッセージキュー始めのためのSMTPサービス拡張子」、RFC1985、1996年8月。

   [10] Fajman, R., "An Extensible Message Format for Message
        Disposition Notifications", RFC 2298, March 1998.


   [11] Freed, N, "Behavior of and Requirements for Internet Firewalls",
        RFC 2979, October 2000.


   [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, December 1996.

解放された[12]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年12月。

Klensin                     Standards Track                    [Page 68]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   [13] Freed, N., "SMTP Service Extension for Command Pipelining", RFC
        2920, September 2000.


   [14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
        Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
        RFC 1847, October 1995.

[14] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「サインされて複合の/がコード化した複合/」、RFC1847、1995年10月。

   [15] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
        December 1998.


   [16] Kille, S., "Mapping between X.400 and RFC822/MIME", RFC 2156,
        January 1998.


   [17] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

[17]HindenとRとS.デアリング、Eds。 「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。

   [18] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for
        Message Size Declaration", STD 10, RFC 1870, November 1995.


   [19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
        "SMTP Service Extensions", STD 10, RFC 1869, November 1995.


   [20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
        "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July


   [21] Lambert, M., "PCMAIL: A distributed mail system for personal
        computers", RFC 1056, July 1988.

[21] ランバート、M.、「PCMAIL:」 「パーソナルコンピュータの分配されたメールシステム」、RFC1056、1988年7月。

   [22] Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.


        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.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年12月。

   [24] Moore, K., "SMTP Service Extension for Delivery Status
        Notifications", RFC 1891, January 1996.

[24] ムーア、K.、「配送状態通知のためのSMTPサービス拡張子」、RFC1891、1996年1月。

   [25] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
        Delivery Status Notifications", RFC 1894, January 1996.

[25] ムーア、K.、およびG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC1894、1996年1月。

   [26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
        53, RFC 1939, May 1996.

[26] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」

Klensin                     Standards Track                    [Page 69]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   [27] Partridge, C., "Mail routing and the domain system", RFC 974,
        January 1986.

[27] ヤマウズラ、C.が「ルーティングとドメインシステムを郵送する」、RFC974、1月1986日

   [28] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February

[28] ヤマウズラ、C.が「メッセージとSMTPをコピーする」、RFC1047、2月1988日

   [29] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
        Program Protocol Specification", STD 7, RFC 793, September 1981.

[29] ポステル、J.、教育、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD7、RFC793、9月1981日

   [30] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August

[30] ポステル、J.、「簡単なメール転送プロトコル」、RFC821、1982年8月。

   [31] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC
        2633, June 1999.


   [32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April

[32] レズニック、P.、エド、「インターネットメッセージ・フォーマット」、RFC2822、4月2001日

   [33] Vaudreuil, G., "SMTP Service Extensions for Transmission of
        Large and Binary MIME Messages", RFC 1830, August 1995.

[33] ボードルイ、G.、「大きくて2進のMIMEメッセージの伝達のためのSMTPサービス拡張子」、RFC1830、1995年8月。

   [34] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
        January 1996.

[34] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC1893、1996年1月。

10. Editor's Address

10. エディタのアドレス

   John C. Klensin
   AT&T Laboratories
   99 Bedford St
   Boston, MA 02111 USA

ジョンC.Klensin AT&T研究所99ベッドフォード・St MA02111ボストン(米国)

   Phone: 617-574-3076
   EMail: klensin@research.att.com

以下に電話をしてください。 617-574-3076 メールしてください: klensin@research.att.com

11. Acknowledgments

11. 承認

   Many people worked long and hard on the many iterations of this
   document.  There was wide-ranging debate in the IETF DRUMS Working
   Group, both on its mailing list and in face to face discussions,
   about many technical issues and the role of a revised standard for
   Internet mail transport, and many contributors helped form the
   wording in this specification.  The hundreds of participants in the
   many discussions since RFC 821 was produced are too numerous to
   mention, but they all helped this document become what it is.

多くの人々がこのドキュメントの多くの繰り返しのときに長時間懸命に働きました。 IETF DRUMS作業部会には広範囲の討論がありました、メーリングリストと面と向かって議論における両方、インターネット・メール輸送の改訂された規格の多くの専門的な問題と役割に関して、そして、多くの貢献者がこの仕様で言葉遣いを形成するのを助けました。 RFC821が生産されたので、多くの議論の何百人もの関係者が言及できないくらい非常に多いのですが、それらは皆、このドキュメントがそれが何であるかということになるのを助けました。

Klensin                     Standards Track                    [Page 70]

RFC 2821             Simple Mail Transfer Protocol            April 2001




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

TCP接続は8ビットのバイトの送信を支持します。 SMTPデータは7ビットのASCII文字です。 高位のビットがゼロまできれいにされている状態で、各キャラクタは8ビットのバイトとして伝えられます。 サービス拡大は、メッセージ身体の一部として完全な8ビットのデータバイトの送信を可能にするようにこの規則を変更しますが、SMTPコマンドか応答で変更するかもしれないというわけではありません。

B. Generating SMTP Commands from RFC 822 Headers

B。 RFC822ヘッダーからSMTPコマンドを発生させます。

   Some systems use RFC 822 headers (only) in a mail submission
   protocol, or otherwise generate SMTP commands from RFC 822 headers
   when such a message is handed to an MTA from a UA.  While the MTA-UA
   protocol is a private matter, not covered by any Internet Standard,
   there are problems with this approach.  For example, there have been
   repeated problems with proper handling of "bcc" copies and
   redistribution lists when information that conceptually belongs to a
   mail envelopes is not separated early in processing from header
   information (and kept separate).

いくつかのシステムがメール服従プロトコルだけにRFC822ヘッダーを使用するか、またはさもなければ、RFCからSMTPコマンドを発生させてください。そのようなメッセージがUAからMTAに手渡される822個のヘッダー。 MTA-UAプロトコルはどんなインターネットStandardでも覆われるのではなく、個人的な問題ですが、このアプローチに関する問題があります。 概念的にメール封筒に属す情報が早くヘッダー情報(そして、別々のままである)と処理で切り離されないとき、例えば、"bcc"コピーと再分配リストの適切な取り扱いに関する繰り返された問題がありました。

   It is recommended that the UA provide its initial ("submission
   client") MTA with an envelope separate from the message itself.
   However, if the envelope is not supplied, SMTP commands SHOULD be
   generated as follows:

UAが(「服従クライアント」)初期のMTAをメッセージ自体から別々の封筒に供給するのは、お勧めです。 SMTPが封筒が供給されないならどのようにSHOULDを命令しても、以下の通り発生してください:

   1. Each recipient address from a TO, CC, or BCC header field SHOULD
      be copied to a RCPT command (generating multiple message copies if
      that is required for queuing or delivery).  This includes any
      addresses listed in a RFC 822 "group".  Any BCC fields SHOULD then
      be removed from the headers.  Once this process is completed, the
      remaining headers SHOULD be checked to verify that at least one
      To:, Cc:, or Bcc: header remains.  If none do, then a bcc: header
      with no additional information SHOULD be inserted as specified in

1. 各受取人はTO、CC、またはBCCからヘッダーフィールドSHOULDを記述します。RCPTコマンド(それが列を作りに必要であるなら複数のメッセージコピーを発生させるか、配送)にコピーされてください。 これはRFC822「グループ」で記載されたどんなアドレスも含んでいます。 どんなBCCもSHOULDをさばいて、次に、ヘッダーから取り外されてください。 一度、この過程が完了している、ヘッダーSHOULDのままで残っていて、チェックされて、そんなに少なくとも1つTo:、Cc:、またはBcc:について確かめてください。 ヘッダーは残っています。 そして、なにもbcc:をしません。 [32]の追加情報がないSHOULDが指定されるとして挿入されているヘッダー。

   2. The return address in the MAIL command SHOULD, if possible, be
      derived from the system's identity for the submitting (local)
      user, and the "From:" header field otherwise.  If there is a
      system identity available, it SHOULD also be copied to the Sender
      header field if it is different from the address in the From
      header field.  (Any Sender field that was already there SHOULD be
      removed.)  Systems may provide a way for submitters to override
      the envelope return address, but may want to restrict its use to
      privileged users.  This will not prevent mail forgery, but may
      lessen its incidence; see section 7.1.

2. メールコマンドSHOULD、できれば提出のためにシステムのアイデンティティから派生している(地方の)ユーザ、および「From:」の返送先 そうでなければ、ヘッダーはさばきます。 アイデンティティ利用可能なシステムがあります、また、それはSHOULDです。それがFromヘッダーフィールドにおけるアドレスと異なるなら、Senderヘッダーフィールドにコピーされてください。 既に、SHOULDがありました。(どんなSenderもそれをさばく、取り除く、) システムは、submittersが封筒返送先をくつがえす方法を提供しますが、使用を特権ユーザに制限したがっているかもしれません。 これは、メール偽造を防ぎませんが、発生を少なくするかもしれません。 セクション7.1を見てください。

Klensin                     Standards Track                    [Page 71]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   When an MTA is being used in this way, it bears responsibility for
   ensuring that the message being transmitted is valid.  The mechanisms
   for checking that validity, and for handling (or returning) messages
   that are not valid at the time of arrival, are part of the MUA-MTA
   interface and not covered by this specification.

MTAがこのように使用されているとき、それは、送られるメッセージが確実に有効になるようにするために責任を負います。 この仕様によってその正当性をチェックする、および到着時点で有効でない取り扱い(または、帰り)メッセージのためのメカニズムはMUA-MTAインタフェースであって覆われないことの一部です。

   A submission protocol based on Standard RFC 822 information alone
   MUST NOT be used to gateway a message from a foreign (non-SMTP) mail
   system into an SMTP environment.  Additional information to construct
   an envelope must come from some source in the other environment,
   whether supplemental headers or the foreign system's envelope.

SMTP環境への外国(非SMTPの)のメールシステムからのゲートウェイaメッセージに単独でStandard RFC822情報に基づく服従プロトコルを使用してはいけません。 封筒を組み立てる追加情報はソースからもう片方の環境で来なければなりません、補足のヘッダーか外国システムの封筒であることにかかわらず。

   Attempts to gateway messages using only their header "to" and "cc"
   fields have repeatedly caused mail loops and other behavior adverse
   to the proper functioning of the Internet mail environment.  These
   problems have been especially common when the message originates from
   an Internet mailing list and is distributed into the foreign
   environment using envelope information.  When these messages are then
   processed by a header-only remailer, loops back to the Internet
   environment (and the mailing list) are almost inevitable.

それらのヘッダー“to"だけを使用するゲートウェイメッセージと「cc」分野への試みは繰り返してインターネット・メール環境の適切な機能に不利なメール輪と他の振舞いを引き起こしました。 メッセージがインターネットメーリングリストから発して、封筒情報を使用することで外国環境に分配されるとき、これらの問題は特に一般的です。 次に、これらのメッセージがヘッダーだけ「再-郵送者」が処理されるとき、インターネット環境(そして、メーリングリスト)への輪はほとんど必然です。

C. Source Routes

C。 送信元経路

   Historically, the <reverse-path> was a reverse source routing list of
   hosts and a source mailbox.  The first host in the <reverse-path>
   SHOULD be the host sending the MAIL command.  Similarly, the
   <forward-path> may be a source routing lists of hosts and a
   destination mailbox.  However, in general, the <forward-path> SHOULD
   contain only a mailbox and domain name, relying on the domain name
   system to supply routing information if required.  The use of source
   routes is deprecated; while servers MUST be prepared to receive and
   handle them as discussed in section 3.3 and F.2, clients SHOULD NOT
   transmit them and this section was included only to provide context.

<逆経路>は歴史的に、ホストの逆のソースルーティングリストとソースメールボックスでした。 1番目はホスト発信がメールコマンドであったなら<逆経路で>SHOULDを接待します。 同様に、<フォワードパス>はホストのリストとあて先メールボックスを発送するソースであるかもしれません。 しかしながら、一般に、<フォワードパス>SHOULDはメールボックスとドメイン名だけを含んでいます、必要なら、ルーティング情報を提供するためにドメイン名システムを当てにして。 送信元経路の使用は推奨しないです。 セクション3.3とF.2で論じられるようにそれらを受けて、扱うようにサーバを準備しなければならない間、クライアントSHOULD NOTは彼らを伝えます、そして、このセクションは含まれていましたが、文脈を提供しました。

   For relay purposes, the forward-path may be a source route of the
   form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully-
   qualified domain names.  This form is used to emphasize the
   distinction between an address and a route.  The mailbox is an
   absolute address, and the route is information about how to get
   there.  The two concepts should not be confused.

「: リレー目的のために、フォワードパスは」 形式の送信元経路が@1であったならそうするかもしれなくて、@TWOは JOE@THREE です」、1、2、および3が完全に適切なドメイン名であるに違いないところで。 このフォームは、アドレスとルートの区別を強調するのに使用されます。 メールボックスは絶対アドレスです、そして、ルートはどうそこに到着するかの情報です。 2つの概念は混乱するべきではありません。

   If source routes are used, RFC 821 and the text below should be
   consulted for the mechanisms for constructing and updating the
   forward- and reverse-paths.


Klensin                     Standards Track                    [Page 72]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   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.


   Notice that the forward-path and reverse-path appear in the SMTP
   commands and replies, but not necessarily in the message.  That is,
   there is no need for these paths and especially this syntax to appear
   in the "To:" , "From:", "CC:", etc. fields of the message header.
   Conversely, SMTP servers MUST NOT derive final message delivery
   information from message header fields.

フォワードパスと逆経路がメッセージにSMTPコマンドと回答に現れますが、必ず現れるというわけではないのに注意してください。 すなわち、これらの経路と特にこの構文が「To:」に現れる必要は全くありません。 , 「From:」、「CC:」、メッセージヘッダーのなど分野。 逆に、SMTPサーバーが最終的なメッセージ配送情報にメッセージヘッダーフィールドに由来していてはいけません。

   When the list of hosts is present, it is a "reverse" source route and
   indicates that the mail was relayed through each host on the list
   (the first host in the list was the most recent relay).  This list is
   used as a source route to return non-delivery notices to the sender.
   As each relay host adds itself to the beginning of the list, it MUST
   use its name as known in the transport environment to which it is
   relaying the mail rather than that of the transport environment from
   which the mail came (if they are different).

ホストのリストが存在しているとき、それは、「逆」の送信元経路であり、メールがリストの上の各ホストを通してリレーされたのを示します(第1代リストにおけるホストは最新のリレーでした)。 このリストは、非引渡通告書を送付者に返すのに送信元経路として使用されます。 各中継ホストがリストの始まりにそれ自体を加えるとき、それはそれがメールが来た輸送環境のものよりむしろメールをリレーしている輸送環境で知られているように(それらが異なるなら)人の名前を引合いに出さなければなりません。

D. Scenarios

D。 シナリオ

   This section presents complete scenarios of several types of SMTP
   sessions.  In the examples, "C:" indicates what is said by the SMTP
   client, and "S:" indicates what is said by the SMTP server.

このセクションはいくつかのタイプのSMTPセッションの完全なシナリオを提示します。 例で「C:」 そして、SMTPクライアントによって言われていることを示す、「S:」 SMTPサーバーによって言われていることを示します。

D.1 A Typical SMTP Transaction Scenario


   This SMTP example shows mail sent by Smith at host bar.com, to Jones,
   Green, and Brown at host foo.com.  Here we assume that host bar.com
   contacts host foo.com directly.  The mail is accepted for Jones and
   Brown.  Green does not have a mailbox at host foo.com.

このSMTPの例はホストfoo.comにスミスによってホストbar.comに送られたメールをジョーンズ、グリーン、およびブラウンに示しています。 ここで、私たちは、ホストbar.comが直接ホストfoo.comに連絡すると思います。 ジョーンズとブラウンのためにメールを受け入れます。 グリーンはホストfoo.comにメールボックスを持っていません。

      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN
      S: 250 HELP
      C: MAIL FROM:<Smith@bar.com>
      S: 250 OK
      C: RCPT TO:<Jones@foo.com>
      S: 250 OK
      C: RCPT TO:<Green@foo.com>
      S: 550 No such user here
      C: RCPT TO:<Brown@foo.com>

S: 220 foo.com SimpleメールTransfer Service Ready C: EHLO bar.com S: 250-foo.comはbar.com Sに挨拶します: 250-8BITMIME S: 250サイズS: 250-DSN S: 250はCを助けます: FROM:<Smith@bar.com に郵送してください、gt;、S: 250 OK C: RCPT TO:<Jones@foo.com 、gt;、S: 250 OK C: RCPT TO:<Green@foo.com 、gt;、S: ここのそのような550人のユーザでない、C: RCPT TO:<Brown@foo.com 、gt。

Klensin                     Standards Track                    [Page 73]

RFC 2821             Simple Mail Transfer Protocol            April 2001


      S: 250 OK
      C: DATA
      S: 354 Start mail input; end with <CRLF>.<CRLF>
      C: Blah blah blah...
      C: ...etc. etc. etc.
      C: .
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

S: 250 OK C: データS: 354 メール入力を始めてください。 <CRLF><CRLF>Cで、終わってください: 何のかの… C: ...などなどなど C: . S: 250 OK C: Sをやめてください: 221 トランスミッションを終えるfoo.com Serviceが精神を集中します。

D.2 Aborted SMTP Transaction Scenario


      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN
      S: 250 HELP
      C: MAIL FROM:<Smith@bar.com>
      S: 250 OK
      C: RCPT TO:<Jones@foo.com>
      S: 250 OK
      C: RCPT TO:<Green@foo.com>
      S: 550 No such user here
      C: RSET
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

S: 220 foo.com SimpleメールTransfer Service Ready C: EHLO bar.com S: 250-foo.comはbar.com Sに挨拶します: 250-8BITMIME S: 250サイズS: 250-DSN S: 250はCを助けます: FROM:<Smith@bar.com に郵送してください、gt;、S: 250 OK C: RCPT TO:<Jones@foo.com 、gt;、S: 250 OK C: RCPT TO:<Green@foo.com 、gt;、S: ここのそのような550人のユーザでない、C: RSET S: 250 OK C: Sをやめてください: 221 トランスミッションを終えるfoo.com Serviceが精神を集中します。

D.3 Relayed Mail Scenario


   Step 1  --  Source Host to Relay Host


      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN
      S: 250 HELP
      C: MAIL FROM:<JQP@bar.com>
      S: 250 OK
      C: RCPT TO:<@foo.com:Jones@XYZ.COM>
      S: 250 OK
      C: DATA
      S: 354 Start mail input; end with <CRLF>.<CRLF>
      C: Date: Thu, 21 May 1998 05:33:29 -0700

S: 220 foo.com SimpleメールTransfer Service Ready C: EHLO bar.com S: 250-foo.comはbar.com Sに挨拶します: 250-8BITMIME S: 250サイズS: 250-DSN S: 250はCを助けます: FROM:<JQP@bar.com に郵送してください、gt;、S: 250 OK C: RCPT TO:<@foo.com : ジョーンズ@XYZ.COM>S: 250 OK C: データS: 354 メール入力を始めてください。 <CRLF><CRLF>Cで、終わってください: 日付: 木曜日、1998年5月21日05:33:29 -0700

Klensin                     Standards Track                    [Page 74]

RFC 2821             Simple Mail Transfer Protocol            April 2001


      C: From: John Q. Public <JQP@bar.com>
      C: Subject:  The Next Meeting of the Board
      C: To: Jones@xyz.com
      C: Bill:
      C: The next meeting of the board of directors will be
      C: on Tuesday.
      C:                         John.
      C: .
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

C: From: ジョンQ. Public <JQP@bar.com 、gt;、C: Subject: 次の重役会の会合C: To: Jones@xyz.com C: C: ビル: C: 次の取締役会はCになるでしょう: 火曜日に。 C: ジョン。 C: . S: 250 OK C: Sをやめてください: 221 トランスミッションを終えるfoo.com Serviceが精神を集中します。

   Step 2  --  Relay Host to Destination Host


      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: Bill:
      C: The next meeting of the board of directors will be
      C: on Tuesday.
      C:                         John.
      C: .
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

S: 220 xyz.com SimpleメールTransfer Service Ready C: EHLO foo.com S: 250 xyz.comは放送されたCです: メール FROM:<@foo.com : JQP@bar.com>S: 250 OK C: RCPT TO:<Jones@XYZ.COM 、gt;、S: 250 OK C: データS: 354 メール入力を始めてください。 <CRLF><CRLF>Cで、終わってください: 受け取られている: foo.comによるbar.comから。 木曜日、1998年5月21日C: 05:33:29 -0700C: 日付: 木曜日、1998年5月21日の05:33:22 -0700C: From: ジョンQ. Public <JQP@bar.com 、gt;、C: Subject: 次の重役会の会合C: To: Jones@xyz.com C: C: ビル: C: 次の取締役会はCになるでしょう: 火曜日に。 C: ジョン。 C: . S: 250 OK C: Sをやめてください: 221 トランスミッションを終えるfoo.com Serviceが精神を集中します。

D.4 Verifying and Sending Scenario


      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN

S: 220 foo.com SimpleメールTransfer Service Ready C: EHLO bar.com S: 250-foo.comはbar.com Sに挨拶します: 250-8BITMIME S: 250サイズS: 250-DSN

Klensin                     Standards Track                    [Page 75]

RFC 2821             Simple Mail Transfer Protocol            April 2001


      S: 250-VRFY
      S: 250 HELP
      C: VRFY Crispin
      S: 250 Mark Crispin <Admin.MRC@foo.com>
      C: SEND FROM:<EAK@bar.com>
      S: 250 OK
      C: RCPT TO:<Admin.MRC@foo.com>
      S: 250 OK
      C: DATA
      S: 354 Start mail input; end with <CRLF>.<CRLF>
      C: Blah blah blah...
      C: ...etc. etc. etc.
      C: .
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

S: 250-VRFY S: 250はCを助けます: VRFYクリスピンS: 250が Crispin <Admin.MRC@foo.com をマークする、gt;、C: FROM:<EAK@bar.com を送ってください、gt;、S: 250 OK C: RCPT TO:<Admin.MRC@foo.com 、gt;、S: 250 OK C: データS: 354 メール入力を始めてください。 <CRLF><CRLF>Cで、終わってください: 何のかの… C: ...などなどなど C: . S: 250 OK C: Sをやめてください: 221 トランスミッションを終えるfoo.com Serviceが精神を集中します。

E. Other Gateway Issues

E。 他のゲートウェイ問題

   In general, gateways between the Internet and other mail systems
   SHOULD attempt to preserve any layering semantics across the
   boundaries between the two mail systems involved.  Gateway-
   translation approaches that attempt to take shortcuts by mapping,
   (such as envelope information from one system to the message headers
   or body of another) have generally proven to be inadequate in
   important ways.  Systems translating between environments that do not
   support both envelopes and headers and Internet mail must be written
   with the understanding that some information loss is almost

一般に、インターネットと他のメールシステムSHOULDの間のゲートウェイは、2台のメールシステムの間の境界の向こう側の意味論がかかわったどんなレイヤリングも保存するのを試みます。 ゲートウェイ翻訳はマッピングで近道を取るその試みにアプローチして、一般に、(別のもののメッセージヘッダーか1台のシステムからボディーまでの封筒情報としてのそのようなもの)は重要な方法で不十分であると判明しました。 いくらかの情報の損失がほとんど必然であるという条件で封筒とヘッダーの両方を支えない環境の間で翻訳されるシステムとインターネット・メールを書かなければなりません。

F. Deprecated Features of RFC 821

F。 RFC821の推奨しない特徴

   A few features of RFC 821 have proven to be problematic and SHOULD
   NOT be used in Internet mail.

RFC821の特徴が問題が多いと立証したいくつかとSHOULD NOT、インターネット・メールで使用されてください。



   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

RFC821で説明されたこのコマンドは、クライアントとサーバが役割を切り換えるよう要求するホストの強い認証がないとき正しい目的地からのメールを紛らすのに容易にそれを使用できるので、重要な安全保障問題を提起します。 使用は推奨しないです。 サーバがクライアントを認証できないなら、SMTPシステムSHOULD NOTはそれを使用します。

Klensin                     Standards Track                    [Page 76]

RFC 2821             Simple Mail Transfer Protocol            April 2001


F.2 Source Routing


   RFC 821 utilized the concept of explicit source routing to get mail
   from one host to another via a series of relays.  The requirement to
   utilize source routes in regular mail traffic was eliminated by the
   introduction of the domain name system "MX" record and the last
   significant justification for them was eliminated by the
   introduction, in RFC 1123, of a clear requirement that addresses
   following an "@" must all be fully-qualified domain names.
   Consequently, the only remaining justifications for the use of source
   routes are support for very old SMTP clients or MUAs and in mail
   system debugging.  They can, however, still be useful in the latter
   circumstance and for routing mail around serious, but temporary,
   problems such as problems with the relevant DNS records.

RFC821は、一連のリレーで1人のホストから別のホストまでメールを受け取るのに明白なソースルーティングの概念を利用しました。 通常のメール交通で送信元経路を利用するという要件はドメイン名システム「Mx」記録の導入で排除されました、そして、それらのための最後の重要な正当化は"@"に続くアドレスがすべて、完全修飾ドメイン名であるに違いないという明確な要件についてRFC1123の序論で排除されました。 その結果、送信元経路の使用のための唯一の残っている正当化は非常に年上のSMTPクライアントかMUAsとメールシステムデバッグでサポートです。 しかしながら、それらはまだ後者の状況と問題などの重大な、しかし、一時的な問題の周りの関連DNS記録があるルーティングメールの役に立っている場合があります。

   SMTP servers MUST continue to accept source route syntax as specified
   in the main body of this document and in RFC 1123.  They MAY, if
   necessary, ignore the routes and utilize only the target domain in
   the address.  If they do utilize the source route, the message MUST
   be sent to the first domain shown in the address.  In particular, a
   server MUST NOT guess at shortcuts within the source route.

SMTPサーバーは、送信元経路構文がこのドキュメントの本体とRFC1123で指定されていると受け入れ続けなければなりません。 彼らは、必要なら、ルートを無視して、アドレスでターゲット・ドメインだけを利用するかもしれません。 彼らが送信元経路を利用するなら、アドレスに示された最初のドメインにメッセージを送らなければなりません。 特に、サーバは送信元経路の中で近道を推測してはいけません。

   Clients SHOULD NOT utilize explicit source routing except under
   unusual circumstances, such as debugging or potentially relaying
   around firewall or mail system configuration errors.

珍しい状況を除いて、クライアントSHOULD NOTは明白なソースルーティングを利用します、ファイアウォールの周りのデバッグか潜在的にリレーやメールシステム構成誤りなどのように。



   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


   RFC 821 provided for specifying an Internet address as a decimal
   integer host number prefixed by a pound sign, "#".  In practice, that
   form has been obsolete since the introduction of TCP/IP.  It is
   deprecated and MUST NOT be used.

RFC821は、「#」と1ポンドのサインによって前に置かれた10進整数ホスト番号としてインターネット・アドレスを指定するのに前提としました。 実際には、TCP/IPの導入以来そのフォームは時代遅れです。 それは、推奨しなく、使用されてはいけません。

F.5 Dates and Years


   When dates are inserted into messages by SMTP clients or servers
   (e.g., in trace fields), four-digit years MUST BE used.  Two-digit
   years are deprecated; three-digit years were never permitted in the
   Internet mail system.

SMTPクライアントかサーバ(例えば、跡の分野の)によって日付がメッセージに挿入されるとき、4ケタの年を費やさなければなりません。 2ケタの年は推奨しないです。 3ケタの年はインターネット・メールシステムで決して受入れられませんでした。

Klensin                     Standards Track                    [Page 77]

RFC 2821             Simple Mail Transfer Protocol            April 2001


F.6 Sending versus Mailing


   In addition to specifying a mechanism for delivering messages to
   user's mailboxes, RFC 821 provided additional, optional, commands to
   deliver messages directly to the user's terminal screen.  These
   commands (SEND, SAML, SOML) were rarely implemented, and changes in
   workstation technology and the introduction of other protocols may
   have rendered them obsolete even where they are implemented.

ユーザのメールボックスにメッセージを渡すのにメカニズムを指定することに加えて、RFC821は直接ユーザの端末のスクリーンにメッセージを渡す追加していて、任意のコマンドを提供しました。 これらのコマンド(SEND、SAML、SOML)はめったに実行されませんでした、そして、それらが実行さえされるところでワークステーション技術における変化と他のプロトコルの導入はそれらを時代遅れにしたかもしれません。

   Clients SHOULD NOT provide SEND, SAML, or SOML as services.  Servers
   MAY implement them.  If they are implemented by servers, the
   implementation model specified in RFC 821 MUST be used and the
   command names MUST be published in the response to the EHLO command.

クライアントSHOULD NOTはサービスとしてSEND、SAML、またはSOMLを提供します。 サーバはそれらを実行するかもしれません。 それらがサーバによって実行されるなら、RFC821で指定された実現モデルを使用しなければなりません、そして、EHLOコマンドへの応答でコマンド名を発表しなければなりません。

Klensin                     Standards Track                    [Page 78]

RFC 2821             Simple Mail Transfer Protocol            April 2001


Full Copyright Statement


   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.


   This document and the information contained herein is provided on an




   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Klensin                     Standards Track                    [Page 79]




 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200