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 . The commands themselves are alphabetic characters terminated by if parameters follow and otherwise. (In the interest of improved interoperability, SMTP receivers are encouraged to tolerate trailing white space before the terminating .) 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コマンドはで終わる文字列である。コマンド自身は、 でなくても、パラメータが続くならで終わるアルファベット文字である。 (相互運用性を高める関心から、SMTPの受信者は終了のの前にホワイト スペースをひきずっても問題にならないことが推奨される。)メールボックス のローカルパートの構文は受信サイトの約束事に適合しなければならず、セク ション4.1.2に構文が規定されている。SMTP応答についてはセクション4.2で議 論されている。 A mail transaction involves several data objects which are communicated as arguments to different commands. The reverse-path is the argument of the MAIL command, the forward-path is the argument of the RCPT command, and the mail data is the argument of the DATA command. These arguments or data objects must be transmitted and held pending the confirmation communicated by the end of mail data indication which finalizes the transaction. The model for this is that distinct buffers are provided to hold the types of data objects, that is, there is a reverse-path buffer, a forward-path buffer, and a mail data buffer. Specific commands cause information to be appended to a specific buffer, or cause one or more buffers to be cleared. メールトランザクションは、別のコマンドに引数として伝達されるいくつかの データオブジェクトを含む。reverse-pathはMAILコマンドの引数であり、 forward-pathはRCPTコマンドの引数であり、メールデータはDATAコマンドの引 数である。これらの引数やデータオブジェクトは伝送され、トランザクション をおわらせる、メールデータが終わりである印によってコミュニケーションが 確認されるまでペンディングにしなければならない。このためのモデルとして は、別個のバッファがデータオブジェクトの型を持つために、つまり、 reverse-pathバッファ、forward-pathバッファ、メールデータバッファが提供 される。特定のコマンドは、特定のバッファへの追加や、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)はパラメータを許さないよう規定され ている。サーバがある仕様拡張を提供し、クライアントがそれを受け入れるの でないなら、クライアントはそのようなパラメータを送ってはならない(MUST NOT)し、サーバは不正な構文を持つものとしてそのコマンドを拒否すべきであ る(SHOULD)。 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) 4.1.1.1 拡張されたHELLO (EHLO) あるいは HELLO (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 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. これらのコマンドは、SMTPサーバがSMTPクライアントを識別するのに使われる。 引数のフィールドには、もし利用可能なら、SMTPクライアントのFQDNが含まれ る。SMTPクライアントシステムが意味のあるドメイン名を持たない場合(例え ば、そのアドレスは動的に割り当てられ、逆引きのマッピングを持たない等)、 クライアントは文字通りのアドレスを送り(セクション4.1.3を見よ)、オプショ ンで、続いてクライアントシステムを識別するのに助けとなる情報を送る。 Klensin Standards Track [Page 29] RFC 2821 Simple Mail Transfer Protocol April 2001 The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command. SMTPサーバはSMTPクライアントに対し、コネクション開始時のグリーティング 応答で、このコマンドへの応えとして、サーバ自身を識別する。 A client SMTP SHOULD start an SMTP session by issuing the EHLO command. If the SMTP server supports the SMTP service extensions it will give a successful response, a failure response, or an error response. If the SMTP server, in violation of this specification, does not support any SMTP service extensions it will generate an error response. Older client SMTP systems MAY, as discussed above, use HELO (as specified in RFC 821) instead of EHLO, and servers MUST support the HELO command and reply properly to it. In any event, a client MUST issue HELO or EHLO before starting a mail transaction. クライアントのSMTPは、EHLOコマンドを発行することでSMTPセッションを開始 すべきである(SHOULD)。もしもSMTPサーバがSMTPサービス拡張をサポートして いるなら、成功、失敗、エラーのいずれかの応答が返るだろう。もしもSMTPサー バが、この仕様に反してSMTPサービス拡張をまったくサポートしないなら、エ ラー応答が生成される。上で議論したように、より古いクライアントSMTPシス テムは、EHLOの代わりにHELO(RFC 821に規定されている)を用いるかもしれず (MAY)、また、サーバはHELOコマンドをサポートし、それに対してきちんとし た応答をしなければならない(MUST)。いかなる場合でも、クライアントはメー ルトランザクションを始める前にHELOないしEHLOを発行しなければならない。 These commands, and a "250 OK" reply to one of them, confirm that both the SMTP client and the SMTP server are in the initial state, that is, there is no transaction in progress and all state tables and buffers are cleared. これらのコマンドと、それに対する"250 OK"の応答は、SMTPクライアントと SMTPサーバ双方がイニシャルステートにあることを確認し、つまり、進行中の トランザクションは存在せず、すべてのステートテーブルとバッファがクリア されたことを示す。 Syntax: ehlo = "EHLO" SP Domain CRLF helo = "HELO" SP Domain CRLF 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つないし複数のパラメータを含んでいる。以下は複数行 応答の一般的な構文であり、これらのキーワードは、最終行以外のすべての行 ではコード(250)、ハイフンの続きのあとに来、最終行ではコード、スペース に続く。ABNF表記法と[8]のターミナルシンボルを用いたポジティブ応答の構 文は以下の通りである。 ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF ) / ( "250-" domain [ SP ehlo-greet ] CRLF *( "250-" ehlo-line CRLF ) "250" SP ehlo-line CRLF ) ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127) ; string of any characters other than CR or LF ehlo-line = ehlo-keyword *( SP ehlo-param ) ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") ; additional syntax of ehlo-params depends on ; ehlo-keyword ehlo-param = 1*(%d33-127) ; any CHAR excluding and all ; control characters (US-ASCII 0-31 inclusive) Klensin Standards Track [Page 30] RFC 2821 Simple Mail Transfer Protocol April 2001 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キーワードは大文字、小文字、その混合で指定されているかもしれないが、 それらは常に解釈され、大文字小文字を無視した方法で処理されなければなら ない(MUST)。これは、単にRFC 821とセクション2.4.1に規定されていることの 履行にすぎない。 4.1.1.2 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. 4.1.1.2 MAIL (MAIL) このコマンドは、メールデータが1つないし複数のメールボックスに配送され たり、別のシステムへと(おそらくSMTPを用いて)渡されたりする、SMTPサーバ への配送中の、メールトランザクションの初期化に使われる。引数フィールド には、reverse-pathと、場合によってはオプションのパラメータが含まれる。 一般に、MAILコマンドはメールトランザクションが進行中でない時にのみ送る ことが許される。セクション4.1.4を見よ。 The reverse-path consists of the sender mailbox. Historically, that mailbox might optionally have been preceded by a list of hosts, but that behavior is now deprecated (see appendix C). In some types of reporting messages for which a reply is likely to cause a mail loop (for example, mail delivery and nondelivery notifications), the reverse-path may be null (see section 3.7). reverse-pathは送り主のメールボックスからなる。歴史的にはメールボックス はオプションでホストのリストが前置されても良かったが、今やその振舞いは 良くないものとされている(Appendix Cを見よ)。 リプライがメールループを起こしかねない報告メッセージのいくつかの型(例 えば、メール配送や配送不能のお知らせ)では、reverse-pathはnullかもしれ ない(セクション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. このコマンドはreverse-pathバッファ、forward-pathバッファ、メールデータ バッファをクリアする;そして、このコマンドによるreverse-path情報を reverse-pathバッファへと入れる。 If service extensions were negotiated, the MAIL command may also carry parameters associated with a particular service extension. もしサービス拡張が取り決められたなら、MAILコマンドは、特定のサービス拡 張に関連したパラメータを持つこともできる。 Syntax: "MAIL FROM:" ("<>" / Reverse-Path) [SP Mail-parameters] CRLF 4.1.1.3 RECIPIENT (RCPT) 4.1.1.3 RECIPIENT (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. このコマンドは、メールデータの個々の受け手を確認するのに使われる;複数 の受け手は、このコマンドを複数回使うことで指示する。引数フィールドは forward-pathと、場合によってはオプションでパラメータを含む。 The forward-path normally consists of the required destination mailbox. Sending systems SHOULD not generate the optional list of hosts known as a source route. Receiving systems MUST recognize source route syntax but SHOULD strip off the source route specification and utilize the domain name associated with the mailbox as if the source route had not been provided. 普通、forward-pathは要求された宛て先メールボックスからなる。 送るシステムは、ソースルーティングとして知られるオプションのホストのリ ストを生成すべきではない(SHOULD NOT)。受けとるシステムはソースルーティ ングの構文を理解しなければならない(MUST)が、ソースルーティングの列挙を とりはずし、あたかもソースルーティングが提供されていなかったようにメー ルボックスに関連したドメイン名を利用するべきである(SHOULD)。 Klensin Standards Track [Page 31] RFC 2821 Simple Mail Transfer Protocol April 2001 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)、名前をreverse-pathへとコピーしてはならない(MUST NOT)。メール が最終的な宛て先に到着したとき(forward-pathに宛て先のメールボックスだ けが含まれる)、SMTPサーバはreverse-pathを、そのホストでのメールでの約 束事にあうように宛て先のメールボックスへと入れる。 For example, mail received at relay host xyz.com with envelope commands 例えば、以下のエンベロープコマンドでリレーホストであるxyz.comから受け とったメール: MAIL FROM: RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> will normally be sent directly on to host d.bar.org with envelope commands は、普通以下のエンベロープコマンドで、ホストd.bar.org へ直接送られる: MAIL FROM: RCPT TO: As provided in appendix C, xyz.com MAY also choose to relay the message to hosta.int, using the envelope commands Appendix Cにあるように、xyz.comはまた、以下のエンベロープコマンドを使っ て、hosta.int へとメッセージをリレーすることを選んでもよい(MAY): MAIL FROM: RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> or to jkl.org, using the envelope commands jkl.org へなら、以下のエンベロープコマンドを用いる: MAIL FROM: RCPT TO:<@jkl.org:userc@d.bar.org> Of course, since hosts are not required to relay mail at all, xyz.com may also reject the message entirely when the RCPT command is received, using a 550 code (since this is a "policy reason"). もちろん、ホストはメールをリレーする必要はまったくないので、RCPTコマン ドを受けとったとき、550コード(これはポリシー上の理由なので)を用いて、 メッセージ全体を拒否するかもしれない。 If service extensions were negotiated, the RCPT command may also carry parameters associated with a particular service extension offered by the server. The client MUST NOT transmit parameters other than those associated with a service extension offered by the server in its EHLO response. もしサービス拡張がとりきめられたなら、RCPTコマンドもまた、サーバが提案 した特定のサービス拡張に関連したパラメータを含んでもよい。クライアント は、EHLOへの応答でサーバから提供されたサービス拡張に関連したもの以外のパ ラメータを送出してはならない(MUST NOT)。 Syntax: "RCPT TO:" ("" / "" / Forward-Path) [SP Rcpt-parameters] CRLF 4.1.1.4 DATA (DATA) 4.1.1.4 DATA (DATA) The receiver normally sends a 354 response to DATA, and then treats the lines (strings ending in sequences, as described in section 2.3.7) following the command as mail data from the sender. 受信者は、普通DATAに対して354応答を送り、そのときそのコマンドに続く行 (で終わる文字列であり、セクション2.3.7に記述がある)を送り手から のメールデータであるとして扱う。 Klensin Standards Track [Page 32] RFC 2821 Simple Mail Transfer Protocol April 2001 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. このコマンドにより、メールデータはメールデータバッファに追加される。メー ルデータは、経験上SP, HT, CR, LF以外のコントロール文字を使うことは問題 を引き起こすかもしれず、可能なら避けるべき(SHOULD)だが、128種のASCII文 字コードのいずれも含むかもしれない。 The mail data is terminated by a line containing only a period, that is, the character sequence "." (see section 4.5.2). This is the end of mail data indication. Note that the first of this terminating sequence is also the that ends the final line of the data (message text) or, if there was no data, ends the DATA command itself. An extra 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 ; in that case, the originating SMTP system MUST either reject the message as invalid or add in order to have the receiving SMTP server recognize the "end of data" condition. メールデータは1つのピリオドだけを持つ行、つまり、一連の"." によって終了する(セクション4.5.2を見よ)。これはメールデータの終わりの しるしである。この終了の並びのうち、最初のはまた、そのデータ(メッ セージテキスト)の最終行のおわりか、もしデータがないなら、DATAコマンド 自身のおわりのである。追加のを加えてはならず(MUST NOT)、そ うするとメッセージに空行が追加されることになるだろう。このルールの唯一 の例外は、もし、で終わっていない最終「行」のある始めのSMTPの送り 手へとメッセージボディが渡された場合に起きる;その場合、始めのSMTPシス テムはメッセージを無効として拒否するか、「データのおわり」の条件として 受信したSMTPサーバが理解できるためにを追加するかのいずれかをしな ければならない(MUST)。 The custom of accepting lines ending only in , 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 "." (bare line feeds, without carriage returns) MUST NOT be treated as equivalent to . as the end of mail data indication. いくつかのUNIXシステムでの適合しないふるまいへの譲歩として、だけで 終わる行を受けいれる習慣は、その解決よりも多くの相互運用性の問題を引き おこし、堅牢性の向上という名目であっても、SMTPサーバシステムはそうして はならない(MUST NOT)。特に、"."のシーケンス(キャリッジリターン なしのはだかのラインフィード)はメールデータの終了のしるしとして .と同等に扱ってはならない(MUST NOT)。 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. メールデータが終わりであるというしるしを受信することは、たくわえられた メールトランザクション情報を処理することをサーバに要求する。このプロセ スではreverse-pathバッファ、forward-pathバッファ、メールデータバッファ が使われ、このコマンドが終了するとこれらのバッファはクリアされる。もし 処理が成功したら、受け手はOKの応答を返さなければならない(MUST)。もし処 理が失敗したら、受け手は失敗の応答を返さなければならない(MUST)。SMTPモ デルでは、この点において部分的な失敗を認めない;配送のためにサーバがメッ セージを受信してポジティブな応答を返すか、受けとられずに失敗の応答を返 すかのいずれかである。データ終わりのしるしに対してポジティブな終了コー ドを送ったとき、受信者はそのメッセージについて完全に責任を負うことにな る(セクション6.1を見よ)。その後に診断されたエラーは、セクション4.4で議 論したように、メールメッセージで報告されなければならない(MUST)。 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 Klensin Standards Track [Page 33] RFC 2821 Simple Mail Transfer Protocol April 2001 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サーバがリレーないし最終配送のいずれかのためにメッセージを受信した とき、メールデータの頭にトレースレコード(交換可能で「タイムスタンプ行」や 「Received」行とも呼ばれる)を挿入する。トレースレコードはメッセージを 受けとった(そしてタイムスタンプを挿入した)ホストの識別子、メッセージを 受けとった日時を示す。リレーされたメッセージは複数のタイムスタンプ行を 持つ。これらの行の構文を含む構成は、セクション4.4に詳説する。 Additional discussion about the operation of the DATA command appears in section 3.3. DATAコマンドの運用に関するさらなる議論は、セクション3.3にある。 Syntax: "DATA" CRLF 4.1.1.5 RESET (RSET) 4.1.1.5 リセット (RSET) This command specifies that the current mail transaction will be aborted. Any stored sender, recipients, and mail data MUST be discarded, and all buffers and state tables cleared. The receiver MUST send a "250 OK" reply to a RSET command with no arguments. A reset command may be issued by the client at any time. It is effectively equivalent to a NOOP (i.e., if has no effect) if issued immediately after EHLO, before EHLO is issued in the session, after an end-of-data indicator has been sent and acknowledged, or immediately before a QUIT. An SMTP server MUST NOT close the connection as the result of receiving a RSET; that action is reserved for QUIT (see section 4.1.1.10). このコマンドは、現在のメールトランザクションが中止されることを示す。た くわえられた送り手、受け手、メールデータは捨てられなければならず(MUST)、 すべてのバッファと状態テーブルはクリアされねばならない(MUST)。受け手は、 引数のないRSETコマンドに対して"250 OK"を返さなければならない(MUST)。 resetコマンドはクライアントによって、いつ発行されてもよい。これは、 EHLOの直後に発行されたり、セッション中EHLOが発行される前だったり、デー タの終わりのしるしが送られて応答が出たあと、QUITの直前になされた場合、 NOOP(つまり、なにも影響しない)と事実上同等である。SMTPサーバはRSETを受 けとった結果としてコネクションを閉じてはならない(MUST NOT);そのアクショ ンはQUITに予約されている(セクション4.1.1.10を見よ)。 Since EHLO implies some additional processing and response by the server, RSET will normally be more efficient than reissuing that command, even though the formal semantics are the same. EHLOはいくつかの追加の処理とサーバによる応答が実装されているため、正式 な意味論上は同じであっても、RSETは普通、そのコマンドを再度発行するより も有効である。 There are circumstances, contrary to the intent of this specification, in which an SMTP server may receive an indication that the underlying TCP connection has been closed or reset. To preserve the robustness of the mail system, SMTP servers SHOULD be prepared for this condition and SHOULD treat it as if a QUIT had been received before the connection disappeared. この標準の意図に反し、SMTPサーバが、根底にあるTCPコネクションが閉じた り、リセットされたりしたシグナルを受けとるかもしれない状況がある。 メールシステムの堅牢性を維持するため、SMTPサーバはこの状況に備えるべき であり(SHOULD)、それをコネクションが失なわれる前にQUITを受けとったもの として扱うべきである(SHOULD)。 Syntax: "RSET" CRLF 4.1.1.6 VERIFY (VRFY) 4.1.1.6 確認 (VRFY) This command asks the receiver to confirm that the argument identifies a user or mailbox. If it is a user name, information is returned as specified in section 3.5. このコマンドは、受け手に引数がユーザないしメールボックスの正体を識別す ることを確認する。もしユーザ名なら、セクション3.5の規定のように情報が 返る。 This command has no effect on the reverse-path buffer, the forward- path buffer, or the mail data buffer. このコマンドはreverse-pathバッファ、forward-pathバッファ、メールデータ バッファに影響を与えない。 Klensin Standards Track [Page 34] RFC 2821 Simple Mail Transfer Protocol April 2001 Syntax: "VRFY" SP String CRLF 4.1.1.7 EXPAND (EXPN) 4.1.1.7 展開 (EXPN) This command asks the receiver to confirm that the argument identifies a mailing list, and if so, to return the membership of that list. If the command is successful, a reply is returned containing information as described in section 3.5. This reply will have multiple lines except in the trivial case of a one-member list. このコマンドで引数がメーリングリストであることの識別を受け手に確認させ、 もしそうならばそのリストのメンバーを返す。もしコマンドが成功したら、応 答はセクション3.5に書いた情報を含んだものが返る。この応答は、メンバー が一人のリストという些細な場合を除き、複数行である。 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. このコマンドはreverse-pathバッファ、forward-pathバッファ、メールデータ バッファに影響を与えず、いかなる時に発行されてもよい。 Syntax: "EXPN" SP String CRLF 4.1.1.8 HELP (HELP) 4.1.1.8 ヘルプ (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. このコマンドにより、サーバからクライアントへ有用な情報が送られる。その コマンドは引数をとるかもしれず(MAY)(例えば、コマンド名)、応答としてよ り具体的な情報が返される。 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. このコマンドはreverse-pathバッファ、forward-pathバッファ、メールデータ バッファに影響を与えず、いかなる時に発行されてもよい。 SMTP servers SHOULD support HELP without arguments and MAY support it with arguments. Syntax: "HELP" [ SP String ] CRLF 4.1.1.9 NOOP (NOOP) This command does not affect any parameters or previously entered commands. It specifies no action other than that the receiver send an OK reply. このコマンドは、パラメータやその前に入力されたコマンドにまったく影響し ない。これは、受け手がOKの応答を送る以外、何のアクションもしないと決め られている。 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. このコマンドはreverse-pathバッファ、forward-pathバッファ、メールデータ バッファに影響を与えず、いかなる時に発行されてもよい。パラメータの文字 列が指定されたなら、サーバはそれを無視すべきである(SHOULD)。 Syntax: "NOOP" [ SP String ] CRLF Klensin Standards Track [Page 35] RFC 2821 Simple Mail Transfer Protocol April 2001 4.1.1.10 QUIT (QUIT) This command specifies that the receiver MUST send an OK reply, and then close the transmission channel. このコマンドでは、受け手はOKの応答を送り、その後転送チャンネルを閉じる と決められている。 The receiver MUST NOT intentionally close the transmission channel until it receives and replies to a QUIT command (even if there was an error). The sender MUST NOT intentionally close the transmission channel until it sends a QUIT command and SHOULD wait until it receives the reply (even if there was an error response to a previous command). If the connection is closed prematurely due to violations of the above or system or network failure, the server MUST cancel any pending transaction, but not undo any previously completed transaction, and generally MUST act as if the command or transaction in progress had received a temporary error (i.e., a 4yz response). 受け手は、それを受けとり、QUITコマンドへの応答をするまで(もしエラーが あったとしても)転送チャンネルをわざと閉じてはならない(MUST NOT)。送り 手はQUITコマンドを送るまでわざと転送チャンネルを閉じてはならず(MUST NOT)、それへの応答を受けとるまで待つべきである(SHOULD)(もし、それ以前 のコマンドにエラーの応答があったとしても)。もしコネクションが上記への 違反、システムないしネットワークの失敗により時期を早めて閉じたならば、 サーバは途中のトランザクションをキャンセルしなければならず(MUST)、一般 にコマンドや進行中のトランザクションはテンポラリエラー(つまり4yz応答) を受けとったかのようにふるまわねばならない(MUST)。 The QUIT command may be issued at any time. QUITコマンドはいつでも発行してよい。 Syntax: "QUIT" CRLF 4.1.2 Command Argument Syntax 4.1.2 コマンド引数の構文 The syntax of the argument fields of the above commands (using the syntax specified in [8] where applicable) is given below. Some of the productions given below are used only in conjunction with source routes as described in appendix C. Terminals not defined in this document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in the "core" syntax [8 (section 6)] or in the message format syntax [32]. 上記コマンドの引数フィールドの構文([8]で規定される構文の利用は許容され る)を以下に示す。下記のうち、いくつかのものはAppendix Cに記したソース ルーティングに関するものである。ALPHA, 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) 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 Klensin Standards Track [Page 36] RFC 2821 Simple Mail Transfer Protocol April 2001 sub-domain = Let-dig [Ldh-str] address-literal = "[" IPv4-address-literal / IPv6-address-literal / General-address-literal "]" ; See section 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 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-partの定義は、最大限相互運用性を持たせるために比較的寛 大であり、メールを受信するつもりのホストはLocal-partがquoted-stringフォー ムを要求(ないし利用)したり、Local-partが大文字小文字を気にしたりするメー ルボックスを定義するのを避けるべきである(SHOULD)。Local-partを生成、比 較する必要がある場合(例えば特定のメールボックス名)、すべてのquotedフォー ムは同等に扱われなければならず(MUST)、送信システムは、転送時にはquote ができるだけ少なくなるようなフォームを利用するべきである(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のコントロール文字(10進で0〜31と127)をSMTPで利用することを要求 するメールボックスを定義してはならない(MUST NOT)。これらの文字は、MAIL やRCPT、その他メールボックス名を要求するコマンド中使ってはならない (MUST NOT)。 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. バックスラッシュ "\" は引用文字であり、次の文字が文字通りに(その普通の 解釈のかわりに)使われることを示すことに注意。例えば、"Joe\,Smith" はフィ ールドの4番目の文字にコンマを含む、単一の9文字のユーザフィールドを示す。 To promote interoperability and consistent with long-standing guidance about conservative use of the DNS in naming and applications (e.g., see section 2.3.1 of the base DNS document, RFC1035 [22]), characters outside the set of alphas, digits, and hyphen MUST NOT appear in domain name labels for SMTP clients or servers. In particular, the underscore character is not permitted. SMTP servers Klensin Standards Track [Page 37] RFC 2821 Simple Mail Transfer Protocol April 2001 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の利 用についての長年のガイダンスと一貫させるため(セクション2.3.1と基礎とな るDNSの文書、RFC1035[22]を見よ)、アルファベット、数字、ハイフン以外の 文字はSMTPクライアントやサーバのドメインネームラベルに現れてはならない (MUST NOT)。特に、アンダスコア文字(_)が許されていない。不正な文字コー ドを持つコマンドを受信し、それ以外に拒否する理由がないSMTPサーバは、 501応答でそのコマンドを拒否する。 4.1.3 Address Literals 4.1.3 アドレスリテラル Sometimes a host is not known to the domain name system and communication (and, in particular, communication to report and repair the error) is blocked. To bypass this barrier a special literal form of the address is allowed as an alternative to a domain name. For IPv4 addresses, this form uses four small decimal integers separated by dots and enclosed by brackets such as [123.255.37.2], which indicates an (IPv4) Internet Address in sequence-of-octets form. For IPv6 and other forms of addressing that might eventually be standardized, the form consists of a standardized "tag" that identifies the address syntax, a colon, and the address itself, in a format specified as part of the IPv6 standards [17]. ときどき、DNSがホストを知らずに通信(そして特に、報告とエラー修正の通信) が妨げられることがある。ドメイン名の代わりにアドレスの特殊なリテラルで このバリアを避けることが許されている。IPv4アドレスについては、この形式 では、[123.255.37.2]のようにドットで区切られ、角カッコでくくられた4つ の小さな十進数を使うが、これはオクテットの並びのフォームによる(IPv4の) インターネットアドレスを示す。IPv6や他のいつかは標準化されるかもしれな いアドレス形式では、IPv6標準[17]の一部として規定される形式のアドレス構 文、コロン、アドレスそのものを識別する、標準化された「タグ」からなる。 Specifically: IPv4-address-literal = Snum 3("." Snum) IPv6-address-literal = "IPv6:" IPv6-addr General-address-literal = Standardized-tag ":" 1*dcontent Standardized-tag = Ldh-str ; MUST be specified in a standards-track RFC ; and registered with IANA Snum = 1*3DIGIT ; representing a decimal integer ; value in the range 0 through 255 Let-dig = ALPHA / DIGIT Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp IPv6-hex = 1*4HEXDIG IPv6-full = IPv6-hex 7(":" IPv6-hex) IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":" IPv6-hex)] ; The "::" represents at least 2 16-bit groups of zeros ; No more than 6 groups in addition to the "::" may be ; present IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::" [IPv6-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 Klensin Standards Track [Page 38] RFC 2821 Simple Mail Transfer Protocol April 2001 4.1.4 Order of Commands 4.1.4 コマンドの順序 There are restrictions on the order in which these commands may be used. これらのコマンドが使われてよい場合に、その順序に制限がある。 A session that will contain mail transactions MUST first be initialized by the use of the EHLO command. An SMTP server SHOULD accept commands for non-mail transactions (e.g., VRFY or EXPN) without this initialization. メールトランザクションを含むセッションは最初、EHLOコマンドを利用して初 期化しなければならない(MUST)。SMTPサーバは、この初期化なしでメールトラ ンザクションでないコマンド(VRFYやEXPNなど)を受け入れるべきである (SHOULD)。 An EHLO command MAY be issued by a client later in the session. If it is issued after the session begins, the SMTP server MUST clear all buffers and reset the state exactly as if a RSET command had been issued. In other words, the sequence of RSET followed immediately by EHLO is redundant, but not harmful other than in the performance cost of executing unnecessary commands. クライアントは、EHLOコマンドをセッション中のより後で発行することができ る。もしセッション開始後にそれが発行されたならばSMTPサーバは、あたか もRSETコマンドが発行されたかのように、すべてのバッファをクリアし、確実 に状態をリセットしなければならない。いいかえれば、RSETにすぐ続いてEHLO というのは冗長だが、不必要なコマンドを実行するパフォーマンス上のコスト 以外には有害ということはない。 If the EHLO command is not acceptable to the SMTP server, 501, 500, or 502 failure replies MUST be returned as appropriate. The SMTP server MUST stay in the same state after transmitting these replies that it was in before the EHLO was received. もしEHLOコマンドがSMTPサーバに受けいれられないなら、501, 500, 502いず れかのエラー応答が適切に返されねばならない(MUST)。これらの応答を返した 後、SMTPサーバはEHLOを受けとる前と同じ状態になけらばならない(MUST)。 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名ではなく)であることを保証し なければならない(MUST)。もしそれが不可能なら(例えばクライアントのアド レスが動的に割りあてられ、クライアントが自明な名前を持たない)、ドメイ ン名とクライアントを識別する助けになるだろう追加の情報を、アドレスリテ ラルで代用するべきである(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アドレスに対応することを確認してよい(MAY)。 しかしながら、サーバは確認に失敗したという理由でメッセージの受け入れを 拒否してはならない(MUST NOT):確認に失敗したという情報は、ログとトレース だけのためとする。 The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time during a session, or without previously initializing a session. SMTP servers SHOULD process these normally (that is, not return a 503 code) even if no EHLO command has yet been received; clients SHOULD open a session with EHLO before sending these commands. NOOP, HELP, EXPN, VRFY, RSETコマンドはセッション中、またセッションの初 期化に先立っていつでも利用できる。SMTPサーバは、EHLOコマンドを受けとっ ていなくとも普通はこれを処理すべきである(SHOULD)(つまり、503コードでは なく);クライアントは、これらのコマンドを送る前にEHLOでセッションを開 くべきである(SHOULD)。 If these rules are followed, the example in RFC 821 that shows "550 access denied to you" in response to an EXPN command is incorrect unless an EHLO command precedes the EXPN or the denial of access is based on the client's IP address or other authentication or authorization-determining mechanisms. もしこれらのルールに従うならば、EHLOコマンドがEXPNに先行するか、クライ アントのIPアドレスに基づいてアクセス拒否されたか、その他認証ないし認証 解決メカニズムによらない限り、EXPNコマンドへの応答で"550 access denied to you"となるRFC 821の例は正しくない。 Klensin Standards Track [Page 39] RFC 2821 Simple Mail Transfer Protocol April 2001 The MAIL command (or the obsolete SEND, SOML, or SAML commands) begins a mail transaction. Once started, a mail transaction consists of a transaction beginning command, one or more RCPT commands, and a DATA command, in that order. A mail transaction may be aborted by the RSET (or a new EHLO) command. There may be zero or more transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be sent if a mail transaction is already open, i.e., it should be sent only if no mail transaction had been started in the session, or it the previous one successfully concluded with a successful DATA command, or if the previous one was aborted with a RSET. MAILコマンド(あるいは時代送れのSEND, SOML, SAMLコマンド)はメールトラン ザクションを開始する。一旦開始すると、メールトランザクションはトランザ クション開始コマンド、1つないし複数のRCPTコマンド、1つのDATAコマンドが この順番で現れる。メールトランザクションはRSET(あるいは新しいEHLO)コマ ンドで中止される。0以上のトランザクションが1つのセッションに存在する。 もしメールトランザクションが既に開いているならばMAIL(SEND, SOML,SAML) が送られてはならない(MUST NOT)。すなわち、このセッションでメールトラン ザクションが開始していないか、先行するトランザクションがDATAコマンドの 成功で終了したか、RSETで中止されたかの場合のみ、それは送られる。 If the transaction beginning command argument is not acceptable, a 501 failure reply MUST be returned and the SMTP server MUST stay in the same state. If the commands in a transaction are out of order to the degree that they cannot be processed by the server, a 503 failure reply MUST be returned and the SMTP server MUST stay in the same state. もしトランザクションを開始するコマンドの引数が受け入れ可能なものでない ならば、501の失敗応答が返されねばならず(MUST)、SMTPサーバは同じ状態に 留まれなければならない(MUST)。もしトランザクション中のコマンドにサー バによって処理不能な度合の異常があれば、503の失敗応答が返されねばなら ず(MUST)、SMTPサーバは同じ状態に留まれなければならない(MUST)。 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コマンドでなければならない(MUST)。 QUITコマンドはセッション中、いつでも使えるわけではないが、セッション開 始コマンドが送られたり受理されたりしない時であってもクライアントSMTPに よってコネクションを閉じる要求として使われるべき(SHOULD)である。 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サーバは"500 Command not recognized"を返すこ とが期待される。拡張されたSMTPサーバは、EHLOコマンドへの応答にこれらの 私的なコマンドに関連する機能の名前をリストアップしてよい(MAY)。 Commands sent or accepted by SMTP systems that do not start with "X" MUST conform to the requirements of section 2.2.2. "X"で始まらない、SMTPシステムによって送られたり受諾されたコマンドは、 セクション2.2.2の要求事項に従わねばならない(MUST)。 4.2 SMTP Replies 4.2 SMTP応答 Replies to SMTP commands serve to ensure the synchronization of requests and actions in the process of mail transfer and to guarantee that the SMTP client always knows the state of the SMTP server. Every command MUST generate exactly one reply. SMTPコマンドへの応答は、メール転送のプロセスでの要求とアクションとが同 期していることを確認し、またSMTPクライアントが常にSMTPサーバの状態を知 ることを保証する。すべてのコマンドは正確に、1つの応答を生成しなければ ならない(MUST)。 The details of the command-reply sequence are described in section 4.3. コマンド-応答のシークエンスの詳細はセクション4.3に詳説する。 An SMTP reply consists of a three digit number (transmitted as three numeric characters) followed by some text unless specified otherwise in this document. The number is for use by automata to determine Klensin Standards Track [Page 40] RFC 2821 Simple Mail Transfer Protocol April 2001 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, , one line of text, and , or a multiline reply (as defined in section 4.2.1). Since, in violation of this specification, the text is sometimes not sent, clients which do not receive it SHOULD be prepared to process the code alone (with or without a trailing space character). Only the EHLO, EXPN, and HELP commands are expected to result in multiline replies in normal circumstances, however, multiline replies are allowed for any command. SMTP応答は、本文書で異なるよう明記されている場合以外、3つの数字(3つの 数字のキャラクターとして転送される)と、それに続くいくつかのテキストか らなる。その数字は次に入る状態が何なのか決定するオートマトンにより使わ れるためである;テキストは人間のユーザのためである。3つの数字はエンコー ドされた十分な情報を持つ。SMTPクライアントがテキストを調べる必要なく、 適切にそれを捨てるかユーザへ渡すかしてよい。例外はこの文書の別のどこか で注意したものである。特に、220, 221, 251,421, 551応答は機械によってパー スし、解釈されねばならないメッセージテキストと関連する。一般的な場合と して、テキストは受信者とコンテキストに依存するかもしれず、よってそれぞ れの応答コードにいろいろなテキストがありそうだ。応答コードの理論に関す る議論はセクション4.2.1にある。形式上、応答はシークエンスで定義される: 3つの数字のコード、スペース、1行のテキスト、、あるいは複数行の応 答である(セクション4.2.1に定義されている)。この規定に反するが、テキス トが時として送られないため、それを受信しないテキストはコードだけでも処 理する準備をすべきである(SHOULD)(後ろにスペースの有無にかかわらず)。 EHLO, EXPN, HELPコマンドだけが普通の状況で複数行応答になると期待される が、しかしながらどのコマンドに対しても複数行応答は許される。 In ABNF, server responses are: ABNFで、サーバの応答は: Greeting = "220 " Domain [ SP text ] CRLF Reply-line = Reply-code [ SP text ] CRLF where "Greeting" appears only in the 220 response that announces that the server is opening its part of the connection. "Greeting"は、220のコネクションの一部をサーバが開くアナウンスの応答に のみあらわれる。 An SMTP server SHOULD send only the reply codes listed in this document. An SMTP server SHOULD use the text shown in the examples whenever appropriate. SMTPサーバは、この文書にあげた応答コードだけを送るべきである(SHOULD)。 SMTPサーバは、ふさわしいときはいつでも例示したテキストを用いるべきであ る(SHOULD)。 An SMTP client MUST determine its actions only by the reply code, not by the text (except for the "change of address" 251 and 551 and, if necessary, 220, 221, and 421 replies); in the general case, any text, including no text at all (although senders SHOULD NOT send bare codes), MUST be acceptable. The space (blank) following the reply code is considered part of the text. Whenever possible, a receiver- SMTP SHOULD test the first digit (severity indication) of the reply code. SMTPクライアントはテキストではなく応答コードによってのみアクションを決 めなければならない(MUST)(251と551の"change of address"と、もし必要なら 220, 221, 421応答の場合を除く);一般的な場合、いかなるテキストや、まっ たくテキストを含まないもの(送り手は裸のコードを送るべきではない(SHOULD NOT)が)も受容しなければならない(MUST)。スペース(ブランク)に続いて応答 コードが来るのは、テキストの一部と考えられる。可能な時はいつでも、受信者 は応答コードの最初の数字(重大な指示)を検査すべきである(SHOULD)。 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. 以下に現れるコードのリストは、永久と解釈してはならない(MUST NOT)。 新しいコードの追加はしばしば起きるべきことではなく、重大な動きであるか ら、応答のテキスト部分に情報を補足するのが好まれ、新しいコードは新しい 標準ないし標準トラックの規定で追加されるかもしれない。その結果、送り側 のSMTPはこの文書で規定されていないコードを扱う準備をしなければならず (MUST)最初の数字だけを解釈することでそうしなければならない(MUST)。 Klensin Standards Track [Page 41] RFC 2821 Simple Mail Transfer Protocol April 2001 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桁の数字はそれぞれ特別な意味を持っている。最初の数字は応答が良 いか、悪いか、不完全かを示す。あかぬけないSMTPクライアントや、予期しな いコードを受けとったSMTPクライアントは、この最初の数字を確認することで 次のアクションを(予定通り続行するか、やり直すか、削除するか、など)決め ることができる。どんな種類のエラーが起きたのかの概略(メールシステムエ ラー、コマンド構文エラーなど)を知りたいSMTPクライアントは、2つ目の数字 を確かめるかもしれない。3番目の数字と、存在するかもしれない補足の情報 は、最も細かい情報のために予約されている。 There are five values for the first digit of the reply code: 応答コードの最初の数字は5種類ある: 1yz Positive Preliminary reply 1yz ポジティブな準備への応答 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. コマンドは受付られたが、要求されたアクションはこの応答の情報の確認を待っ ている。SMTPクライアントは、アクションを続けるか中止するかを決める別の コマンドを送るべきである。注意:拡張されていないSMTPはこのタイプの応答 を許すコマンドを持っておらず、よって続けるか中止するかのコマンドも持っ ていない。 2yz Positive Completion reply 2yz ポジティブな完成した応答 The requested action has been successfully completed. A new request may be initiated. 要求されたアクションは成功で終了した。新しい要求を始めてよい。 3yz Positive Intermediate reply 3yz ポジティブで途中の応答 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). コマンドは受付られたが、要求されたアクションはさらなる情報を受信するの を待っている。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 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.) コマンドは受け入れられず、要求されたアクションは起こらない。しかしなが ら、エラーの状況は一時的であり、そのアクションは再び要求されても良い。 送り手は、(もしあるなら)コマンドシークエンスの最初に戻るべきである。2 つの異なるサイト(受信側と送信側のSMTPエージェント)が解釈について同意し なければならないとき、「一時的」の持つ意味は難しい。このカテゴリーに属 するそれぞれの応答は異なる時間の値を持っているかもしれないが、SMTPクラ イアントは再度行うことが推奨される。応答を4yzか5yz(以下を見よ)いずれの カテゴリーにあてはめるかを決定するルールは、もしコマンドや送り手か受け 手の特性(つまり、同じくコマンドが繰り返され、受け手が新しい実装を用意 しない)をまったく変更せずに成功する可能性があるならば、4yzが応答される。 Klensin Standards Track [Page 42] RFC 2821 Simple Mail Transfer Protocol April 2001 5yz Permanent Negative Completion reply The command was not accepted and the requested action did not occur. The SMTP client is discouraged from repeating the exact request (in the same sequence). Even some "permanent" error conditions can be corrected, so the human user may want to direct the SMTP client to reinitiate the command sequence by direct action at some point in the future (e.g., after the spelling has been changed, or the user has altered the account status). 5yz 永続的なネガティブの完成した応答 コマンドは受け入れられず、要求されたアクションは起こらない。SMTPクライ アントはまったく同じ要求を(同じシークエンスで)繰り返すことをあきらめる。 いくつかの「永続的な」エラー状況でさえ修正され得るので、人間のユーザは SMTPクライアントに、将来、ある点での直接のアクションによってそのコマン ドシークエンスを再度初期化させても良い(すなわち、つづりが変更された後 やユーザがアカウントの状態を変更した後)。 The second digit encodes responses in specific categories: 2つめの数字は、特定のカテゴリー中の応答をエンコードする。 x0z Syntax: These replies refer to syntax errors, syntactically correct commands that do not fit any functional category, and unimplemented or superfluous commands. x0z 構文:これらの応答は構文エラー、いかなる機能上のカテゴリーにも適合 しない構文上正しいコマンド、実装されていなかったり余計なコマンドを表す。 x1z Information: These are replies to requests for information, such as status or help. x1z 情報:これらは、ステータスやヘルプのような情報の要求に対する応答 である。 x2z Connections: These are replies referring to the transmission channel. x2z 接続:これらは、転送チャンネルに関連する応答である。 x3z Unspecified. x3z 未定。 x4z Unspecified. x4z 未定。 x5z Mail system: These replies indicate the status of the receiver mail system vis-a-vis the requested transfer or other mail system action. x5z メールシステム:これらの応答は要求された転送で向かいあった受信側の メールシステムや、別のメールシステムのアクションの状態を表す。 The third digit gives a finer gradation of meaning in each category specified by the second digit. The list of replies illustrates this. Each reply text is recommended rather than mandatory, and may even change according to the command with which it is associated. On the other hand, the reply codes must strictly follow the specifications in this section. Receiver implementations should not invent new codes for slightly different situations from the ones described here, but rather adapt codes already defined. 3番目の数字は、2つ目の数字で決められたそれぞれのカテゴリー中、意味のよ り細かい段階をあらわす。応答のリストはこれを説明する。それぞれの応答テ キストは必須というよりは推奨であり、それに関連するコマンドによって変更 してもよい。他方、応答コードは、このセクションの仕様に厳密に従わなけれ ばならない。受信側の実装は、ここの以下に示すのと少しだけ違う状況に新し いコードを発明すべきでなく、むしろ既に定義されたコードを適用させるべき である。 For example, a command such as NOOP, whose successful execution does not offer the SMTP client any new information, will return a 250 reply. The reply is 502 when the command requests an unimplemented non-site-specific action. A refinement of that is the 504 reply for a command that is implemented, but that requests an unimplemented parameter. 例えばNOOPのような、成功したときSMTPクライアントに何ら新しい情報を提供 しないコマンドは250応答を返すだろう。コマンドがサイト特有のアクション ではない、実装されていない要求の時応答は502である。その改良点としては、 実装されているが、要求されたパラメータについて実装されていないコマンド への504応答である。 Klensin Standards Track [Page 43] RFC 2821 Simple Mail Transfer Protocol April 2001 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. 応答テキストは1行よりも長いかもしれない;この場合、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 , optionally some text, and . As noted above, servers SHOULD send the if subsequent text is not sent, but clients MUST be prepared for it to be omitted. 複数行応答のフォーマットは、最後を除く各行に必要であり、応答コードで始 まり、すぐ続けてハイフン "-" (マイナスとしても知られる)、つづけてテキ ストである。最終行は応答コードで始まり、すぐ続けて、オプションでい くぶんかのテキスト、そしてである。上で注意したように、それに続く テキストが送られないならばサーバはを送るべき(SHOULD)だが、クライア ントはそれを削除する準備をしなければならない(MUST)。 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 or 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クライアントは単に応答コードで始まりない しが続く行を探し、すべてのそれ以前の行を無視する必要がある。 いくつかの場合、応答「テキスト」にクライアントにとって重要なデータがあ る。クライアントは、現在のコンテキストからこういった場合を識別できるか もしれない。 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) 500 構文エラー、コマンドが解釈不能 (これは、コマンドラインが流すぎるようなエラーを含む) 501 Syntax error in parameters or arguments 501 パラメータや引数の構文エラー 502 Command not implemented (see section 4.2.4) 502 コマンドは実装されていない (セクション 4.2.4を見よ) 503 Bad sequence of commands 503 コマンドの並びが悪い 504 Command parameter not implemented 504 コマンドパラメータが実装されていない 211 System status, or system help reply 211 システムの状態、またはシステムヘルプの応答 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) 214 ヘルプメッセージ (受け手の使い方や特別な標準ではないコマンドの意味の情報;この応答は 人間のユーザにとってのみ有用である) 220 Service ready 220 サービスの準備ができた 221 Service closing transmission channel 221 サービスは転送チャンネルを閉じる 421 Service not available, closing transmission channel (This may be a reply to any command if the service knows it must shut down) 421 サービスが利用可能でなく、転送チャンネルを閉じる (サービスとしてシャットダウンしなければならないと知っているコマンドへの応 答かもしれない) Klensin Standards Track [Page 44] RFC 2821 Simple Mail Transfer Protocol April 2001 250 Requested mail action okay, completed 250 要求されたメールアクションはOKであり、完結した。 251 User not local; will forward to (See section 3.4) 251 ユーザはローカルではない; へと転送されるだろう (セクション3.4を見よ) 252 Cannot VRFY user, but will accept message and attempt delivery (See section 3.5.3) 252 ユーザの確認(VRFY)ができないが、メッセージを受信して配送の試みはす るだろう(セクション3.5.3を見よ)。 450 Requested mail action not taken: mailbox unavailable (e.g., mailbox busy) 450 要求されたメールアクションは受けいれない:メールボックスが利用不可 能である(例えば、メールボックスがビジー) 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) 550 要求されたアクションは受けいれない:メールボックスが利用不可能であ る(例えば、メールボックスが見つからない、アクセスできない、ポリシー上 の理由でコマンドが拒否された) 451 Requested action aborted: error in processing 451 要求されたアクションは中止された:処理中のエラー 551 User not local; please try (See section 3.4) 551 ユーザはローカルでない;を試してほしい (セクション3.4を見よ) 452 Requested action not taken: insufficient system storage 450 要求されたアクションは受けいれない:システムのストレージがたりない 552 Requested mail action aborted: exceeded storage allocation 552 要求されたメールアクションは中止された:ストレージの割りあてが上回っ た 553 Requested action not taken: mailbox name not allowed (e.g., mailbox syntax incorrect) 553 要求されたアクションは受け入れられない:メールボックス名は許可され ない(例えばメールボックスの構文が正しくない) 354 Start mail input; end with . 354 メール入力の開始;.で終わり 554 Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here") 554 トランザクションの失敗(あるいは、コネクション開始時の応答の場合、 「ここには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 Service ready 221 Service closing transmission channel 250 Requested mail action okay, completed 251 User not local; will forward to (See section 3.4) 252 Cannot VRFY user, but will accept message and attempt delivery (See section 3.5.3) 354 Start mail input; end with . 421 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 Klensin Standards Track [Page 45] RFC 2821 Simple Mail Transfer Protocol April 2001 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 (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") 211 システムの状態、またはシステムヘルプの応答 214 ヘルプメッセージ (受け手の使い方や特別な標準ではないコマンドの意味の情報;この応答は 人間のユーザにとってのみ有用である) 220 サービスの準備ができた 221 サービスは転送チャンネルを閉じる 250 要求されたメールアクションはOKであり、完結した。 251 ユーザはローカルではない; へと転送されるだろう (セクション3.4を見よ) 252 ユーザの確認(VRFY)ができないが、メッセージを受信して配送の試みはす るだろう(セクション3.5.3を見よ)。 354 メール入力の開始;.で終わり 421 サービスが利用可能でなく、転送チャンネルを閉じる (サービスとしてシャットダウンしなければならないと知っているコマンドへの応 答かもしれない) 450 要求されたメールアクションは受けいれない:メールボックスが利用不能 (例えばメールボックスがビシー) 451 要求されたアクションは中止された:処理中のエラー 452 要求されたアクションは中止された:システムのストレージが足りない 500 構文エラー、コマンドが解釈不能 501 パラメータや引数の構文エラー 502 コマンドは実装されていない (セクション 4.2.4を見よ) 503 コマンドの並びが悪い 504 コマンドパラメータが実装されていない 550 要求されたアクションは受けいれない:メールボックスが利用不可能であ る(例えば、メールボックスが見つからない、アクセスできない、ポリシー上 の理由でコマンドが拒否された) 551 ユーザはローカルでない;を試してほしい 552 要求されたメールアクションは中止された:ストレージの割りあてが上回っ た 553 要求されたアクションは受け入れられない:メールボックス名は許可され ない(例えば、メールボックスの構文が不正) 554 トランザクションの失敗(あるいは、コネクション開始時の応答の場合、 「ここには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)という問題が持ちあがっている。コマンドが実際にSMTPサー バに解釈されたが、実装されていない時502が使われるべきである(SHOULD)。 もしコマンドが解釈できないならば、コード500が返されるべきである (SHOULD)。拡張されたSMTPシステムはEHLOの応答に、502(あるいは500)応答を 返す可能性のあるものをリストしてはならない(MUST NOT)。 4.2.5 Reply Codes After DATA and the Subsequent . 4.2.5 DATAの後で.に続く応答コード When an SMTP server returns a positive completion status (2yz code) after the DATA command is completed with ., it accepts responsibility for: DATAコマンドが.で完結し、SMTPサーバがポジティブで完結した 状態(2yzコード)を返したとき、以下のいずれかをする責任を負う: - delivering the message (if the recipient mailbox exists), or メッセージを配送する(もし受け手のメールボックスが存在するなら)または、 - if attempts to deliver the message fail due to transient conditions, retrying delivery some reasonable number of times at intervals as specified in section 4.5.4. もしメッセージを配送する試みが、一時的な状況により失敗したならば、セク ション4.5.4に規定される間隔で適切な回数配送をリトライする。 - 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 transient error completion status (4yz) code after the DATA command is completed with ., it MUST NOT make any subsequent attempt to deliver that message. The SMTP Klensin Standards Track [Page 46] RFC 2821 Simple Mail Transfer Protocol April 2001 client retains responsibility for delivery of that message and may either return it to the user or requeue it for a subsequent attempt (see section 4.5.4.1). DATAコマンドが.で完結した後にSMTPサーバが一時的なエラーの 完結状態(4yz)を返したとき、サーバはそのメッセージを配送する試みを後に してはならない(MUST NOT)。そのSMTPクライアントはまだそのメッセージを配 送する責任を維持しており、それをユーザに返すか、後の試みのために再び キューに入れるかしてよい(セクション4.5.4.1を見よ)。 The user who originated the message SHOULD be able to interpret the return of a transient failure status (by mail message or otherwise) as a non-delivery indication, just as a permanent failure would be interpreted. I.e., if the client SMTP successfully handles these conditions, the user will not receive such a reply. メッセージを作成したユーザは、配送できないという指摘として返ってくる一 時的失敗状態(メールメッセージないしその他)を、ちょうど永続的失敗を解釈 するように解釈できるべきである(SHOULD)。例えば、もしクライアントSMTPが これらの状況を扱うのに成功すれば、ユーザはそのような応答を受けとらない だろう。 When an SMTP server returns a permanent error status (5yz) code after the DATA command is completely with ., it MUST NOT make any subsequent attempt to deliver the message. As with temporary error status codes, the SMTP client retains responsibility for the message, but SHOULD not again attempt delivery to the same server without user review and intervention of the message. DATAコマンドが.で完結した後にSMTPサーバが永続的なエラーの 状態(5yz)を返したとき、サーバはそのメッセージを配送する試みを後にして はならない(MUST NOT)。一時的なエラー状態コードと同じく、そのSMTPクライ アントはまだそのメッセージを配送する責任を維持しているが、ユーザによる 再調査やメッセージへの介入なしに同じサーバへ配送する試みを再びするべき ではない(SHOULD NOT)。 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. 送り手と受け手の間のコミュニケーションは交互の対話であり、送り手によっ て制御される。よって、送り手はコマンドを発行し、受け手は応答を返答する。 サービス拡張で別の取り決めがなされない限り、送り手は、さらなるコマンド を送る前にこれへの応答を待たなければならない(MUST)。 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つの重要な応答として接続の挨拶(greeting)がある。普通、コネクションが 完成したとき、受け手は220 "Service ready"応答を送るだろう。送り手は、 コマンドを送る前に挨拶メッセージを待つべきである(SHOULD)。 Note: all the greeting-type replies have the official name (the fully-qualified primary domain name) of the server host as the first word following the reply code. Sometimes the host will have no meaningful name. See 4.1.3 for a discussion of alternatives in these situations. 注意:あらゆる挨拶型の応答には、応答コードに続く最初の単語として、サー バホストの公式な名前(主要なFQDN)が存在する。時々ホストは意味のある名前 を持たないことがある。このような場合、代わりの議論として4.1.3を見よ。 For example, 220 ISIF.USC.EDU Service ready or 220 mail.foo.com SuperSMTP v 6.1.2 Service ready or 220 [10.0.0.1] Clueless host service ready Klensin Standards Track [Page 47] RFC 2821 Simple Mail Transfer Protocol April 2001 The table below lists alternative success and failure replies for each command. These SHOULD be strictly adhered to: a receiver may substitute text in the replies, but the meaning and action implied by the code numbers and by the specific command reply sequence cannot be altered. 下記の表には、それぞれのコマンドへの成功と失敗の応答を代わるがわる並べ てある。これらは厳密に遵守されるべきである(SHOULD):受け手は応答のテキ ストを置換してよいが、コード番号と特定のコマンドの応答シークェンスが示 す意味とアクションは変更できない。 4.3.2 Command-Reply Sequences 4.3.2 コマンド-応答シークェンス Each command is listed with its usual possible replies. The prefixes used before the possible replies are "I" for intermediate, "S" for success, and "E" for error. Since some servers may generate other replies under special circumstances, and to allow for future extension, SMTP clients SHOULD, when possible, interpret only the first digit of the reply and MUST be prepared to deal with unrecognized reply codes by interpreting the first digit only. それぞれのコマンドはたいていの可能な応答と共にリストされている。可能な 応答の前に置かれたプレフィックスは、"I"が途中、"S"が成功、"E"がエラー である。いくつかのサーバは特殊な環境では異なる応答を生成するかもしれず、 また将来拡張されるかもしれないので、SMTPクライアントは、可能な時には応 答の最初の数字だけを解釈すべきであり(SHOULD)、また最初の数字だけを解釈 することで、理解できない応答コードを扱う準備をしておかなければならない (MUST)。 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. セクション2.2に記した拡張されたメカニズムが使われていない限り、SMTPサー バはSMTPクライアントに3つの数字でなかったり、2〜5の間の数字で始まらな かったりする応答コードを転送してはならない(MUST NOT)。 These sequencing rules and, in principle, the codes themselves, can be extended or modified by SMTP extensions offered by the server and accepted (requested) by the client. 原則として、これらのシークェンスのルールとコードそのものは、サーバによっ て提案されてクライアントによって受け入れられた(要求された)SMTP拡張によ り、拡張されたり変更されたりする。 In addition to the codes listed below, any SMTP command can return any of the following codes if the corresponding unusual circumstances are encountered: 以下に列挙したコードに加え、それに関連する普通ではない状況に出逢ったなら、 SMTPコマンドは以下に続くコードいずれでも返すことができる: 500 For the "command line too long" case or if the command name was not recognized. Note that producing a "command not recognized" error in response to the required subset of these commands is a violation of this specification. 500 コマンドラインが長すぎる場合、コマンド名が理解できなかった場合のた め。これらのコマンドの要求されたサブセットに対する応答として「コマンド が理解できませんでした」エラーを生成するのはこの標準に反することに注意。 501 Syntax error in command or arguments. In order to provide for future extensions, commands that are specified in this document as not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 message if arguments are supplied in the absence of EHLO- advertised extensions. 501 コマンドないし引数に構文エラーがある。将来の拡張を提供するため、 本文書中に規定された引数をとらないコマンド(DATA, RSET, QUIT)は、もし EHLOで広報された拡張にないのに引数が与えられたら、501メッセージを返す べきである(SHOULD)。 421 Service shutting down and closing transmission channel 421 サービスがシャットダウンし、転送チャンネルを閉じる Specific sequences are: 規定のシークェンスは以下の通りである: CONNECTION ESTABLISHMENT コネクションの確立 S: 220 E: 554 Klensin Standards Track [Page 48] RFC 2821 Simple Mail Transfer Protocol April 2001 EHLO or HELO S: 250 E: 504, 550 MAIL S: 250 E: 552, 451, 452, 550, 553, 503 RCPT S: 250, 251 (but see section 3.4 for discussion of 251 and 551) E: 550, 551, 552, 553, 450, 451, 452, 503, 550 DATA I: 354 -> data -> S: 250 E: 552, 554, 451, 452 E: 451, 554, 503 RSET S: 250 VRFY S: 250, 251, 252 E: 550, 551, 553, 502, 504 EXPN S: 250, 252 E: 550, 500, 502, 504 HELP S: 211, 214 E: 502, 504 NOOP S: 250 QUIT S: 221 4.4 Trace Information 経路の情報 When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content, as discussed in section 4.1.1.4. SMTPサーバが配送やさらなる処理のためにメッセージを受けとった時、セクショ ン4.1.1.4で議論したようにメッセージコンテントの最初に経路情報("タイム スタンプ"ないし"Received")を入れなければならない(MUST)。 This line MUST be structured as follows: この行は、以下の構造でなければならない(MUST): - 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. SMTP環境で与えられなければならない(MUST)FROMフィールドは、(1)EHLOコマ ンドに現れた送り側ホストの名前、(2)TCPコネクションから決定された送り側 のIPアドレスを含むアドレスリテラル の双方を含むべきである(SHOULD)。 - The ID field MAY contain an "@" as suggested in RFC 822, but this is not required. RFC822で示唆されるようにIDフィールドは"@"を含んでもよい(MAY)が、必要で はない。 Klensin Standards Track [Page 49] RFC 2821 Simple Mail Transfer Protocol April 2001 - The FOR field MAY contain a list of 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フィールドはエントリのリ ストを含んでもよい(MAY)。これはいくつかのセキュリティ上の問題を引きお こすかもしれず、よって普通は好ましくない;セクション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:行を変更してはならない(MUST NOT)。SMTPサーバはメッセージの 頭にReceived行をつけなければならない(MUST);サーバは存在している行の順 番を変えたり、別の場所にReceived行を挿入したりしてはならない(MUST NOT)。 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 a time zone name is used, it SHOULD be included in a comment. インターネットが大きくなったので、Receivedフィールドの比較可能性は、特 に遅いリレーで問題を発見するのに重要である。Receivedフィールドを作成す るSMTPサーバは、日時にいかなる型のタイムゾーン名よりも、明確なオフセッ ト(例えば -0800のような)を使うべきである(SHOULD)。可能な時は、(オフセッ ト付き)ローカルタイムはUT(UTC)より好まれる。この形成により、ローカルの 環境について規定されたより少しだけ多くの情報を与える。もしUTが必要なら ば、受信者は値を変換するのに簡単な算数が必要になるだけである。UTを使う と、サーバのタイムゾーンの位置に関する情報が失なわれる。もしもタイムゾー ン名が使われるなら、それはコメント内にあるべきである(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 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サーバがメッセージの"最終の配送"をする時、サーバはメールデー タの最初にreturn-path行を挿入する。return-pathの使用は必要である;メー ルシステムはそれをサポートしなければならない(MUST)。return-path行は MAILコマンドのの情報を保存している。ここで、最終の配送と は、メッセージがSMTP環境に残されることを意味する。普通、これは宛て先の ユーザないし関連するメールドロップに配送されたことを意味するが、しかし 時には、それはさらに処理され、別のメールシステムへと転送される。 It is possible for the mailbox in the return path to be different from the actual sender's mailbox, for example, if error responses are to be delivered to a special error handling mailbox rather than to the message sender. When mailing lists are involved, this arrangement is common and useful as a means of directing errors to the list maintainer rather than the message originator. 例えば、もしエラーの応答がメッセージの送り手よりむしろ、エラーを扱うた めの特殊なメールボックスに配送されるべきならば、実際の送り手のメールボッ クスと異なるメールボックスをreturn-pathにするのも可能である。メーリン グリストが関連している時、この処置は一般的であり、またメッセージの作成 者よりむしろリストマネージャへエラーを向ける意味として有用である。 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]. 上記のテキストは、最終的なメールデータはreturn-pathの行で始まり、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, any further (forwarding, gateway, or relay) systems MAY remove the return path and rebuild the MAIL command as needed to ensure that exactly one such line appears in a delivered message. メッセージが配送のために受けとたれた後で転送やその他の動作が起こるかも しれないため、最終の配送をすべきかどうか決定するのが時としてSMTPサーバ にとって難しい。その結果、より遠くへ(転送、ゲートウェイ、リレー)のシス テムは、return-pathを削除し、配送されたメッセージに現れた厳密に1つの行 を確かめる必要からMAILコマンドを再構築してもよい(MAY)。 Klensin Standards Track [Page 50] RFC 2821 Simple Mail Transfer Protocol April 2001 A message-originating SMTP system SHOULD NOT send a message that already contains a Return-path header. SMTP servers performing a relay function MUST NOT inspect the message data, and especially not to the extent needed to determine if Return-path headers are present. SMTP servers making final delivery MAY remove Return-path headers before adding their own. メッセージを始めに送ったSMTPシステムは、既にReturn-pathヘッダを持つメッ セージを送るべきではない(SHOULD NOT)。リレー機能を持つSMTPサーバはメッ セージデータを検査してはならず(MUST NOT)、特にReturn-pathヘッダが存在 するかどうか決定することを必要とするような拡張をしてはならない。 最終配送をするSMTPサーバは、以前からそれに付いていたReturn-pathを、そ れが付加する前に取り除いてよい(MAY)。 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-pathの第一の目的は、配送不能や他のメールシステムに関する失敗を 示すメッセージが送られる先のアドレスを指定することである。これを明確に するために、メッセージが配送される時、ちょうど1つのreturn-pathが存在す べきである(SHOULD)。SMTPでない配送系でRFC 822の構文を使うシステムは、 配送のエンベロープに関連づいた、エラーレポート(例えば配送不能メッセー ジ)が送られるべき明確なアドレスを示すべきである(SHOULD)。 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-pathヘッダ(あるいは、MAILコマンドからのエンベロー プのリバースパスアドレス)の使い方がエラーメッセージの宛て先であること に反するように見えるRFC 822のテキストは、インターネットに適用できない。 リバースパスアドレス(Return-pathにコピーされる)は、配送エラーメッセー ジを含むあらゆるメールの宛て先として使われなければならない(MUST)。 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から別シス テムへのゲートウェイではreturn-pathヘッダを挿入すべきである(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へのゲートウェイは、メッセージに存在するreturn-pathヘッ ダを削除し、SMTPエンベロープへその情報をコピーするか、SMTPエンベロープ のMAILコマンドへのリバースパス引数を作るために、別の配送系のエンベロー プに存在する情報と一緒にするかすべきである(SHOULD)。 The server must give special treatment to cases in which the processing following the end of mail data indication is only partially successful. This could happen if, after accepting several recipients and the mail data, the SMTP server finds that the mail data could be successfully delivered to some, but not all, of the recipients. In such cases, the response to the DATA command MUST be an OK reply. However, the SMTP server MUST compose and send an "undeliverable mail" notification message to the originator of the message. 続くメールデータの終わりの印が部分的にのみ成功したときの処理の場合、 サーバは特別な扱いをしなければならない。いくつかの受信者とメールデータ を受けつけた後、メールデータが受信者の、全てではなくいくつかには正しく 配送できないことがSMTPサーバに分かったような場合に置き得る。そのような 場合、DATAコマンドへの応答はOKの応答でなければならない(MUST)。しかしな がら、SMTPサーバは「配送不能」のお知らせメッセージを作り、そのメッセー ジの作成者に送らなければならない(MUST)。 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 Klensin Standards Track [Page 51] RFC 2821 Simple Mail Transfer Protocol April 2001 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. 失敗したすべての受信者を並べた1つのお知らせか、別個のお知らせメッセー ジが、それぞれの失敗した受信者ごとに送られなければならない(MUST)。 送り手の経済的な理由から、可能なら後者が好まれる。すべての配送不能メー ルのお知らせメッセージはMAILコマンド(時代送れのSEND, SOML, SAMLコマン ドを用いて処理された結果だったとしても)を持ちいて送信され、セクション 3.7で議論したようにnullのreturn-pathを用いる。 The time stamp line and the return path line are formally defined as follows: タイムスタンプ行とreturn-path行は、形式上以下のように定義される: Return-path-line = "Return-Path:" FWS Reverse-path Time-stamp-line = "Received:" FWS Stamp Stamp = From-domain By-domain Opt-info ";" FWS date-time ; 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. "date-time"は[32]に定義されている。 しかし、"obs-"形式、特に2桁の数字の年はSMTPでは禁止されており、使用し てはならない(MUST NOT)。 From-domain = "FROM" FWS Extended-Domain CFWS By-domain = "BY" FWS Extended-Domain 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コネクションからのサーバ由来の情報であり、クライアントのEHLOのもの ではない。 Opt-info = [Via] [With] [ID] [For] Via = "VIA" FWS Link CFWS With = "WITH" FWS Protocol CFWS ID = "ID" FWS String / msg-id CFWS For = "FOR" FWS 1*( Path / Mailbox ) 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 ; servers SHOULD NOT use unregistered names. リンクへの追加の標準名はIANAで登録されている。"Via"は本来、インターネ ット以外の転送での値である。SMTPサーバは登録されていない名前を使うべき ではない(SHOULD NOT)。 Protocol = "ESMTP" / "SMTP" / Attdl-Protocol Attdl-Protocol = Atom ; Additional standard names for protocols are registered with the Klensin Standards Track [Page 52] RFC 2821 Simple Mail Transfer Protocol April 2001 ; Internet Assigned Numbers Authority (IANA). SMTP servers ; SHOULD NOT use unregistered names. プロトコルへの追加の標準名は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を動くようにするため、全ての受信者には以下の最小の実装が必要である。 この標準に従うためには、以下のコマンドをサポートしなければならない (MUST)。 EHLO HELO MAIL RCPT DATA RSET NOOP QUIT VRFY Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox "postmaster" as a case- insensitive local name. This postmaster address is not strictly necessary if the server always returns 554 on connection opening (as described in section 3.1). The requirement to accept mail for postmaster implies that RCPT commands which specify a mailbox for postmaster at any of the domains for which the SMTP server provides mail service, as well as the special case of "RCPT TO:" (with no domain specification), MUST be supported. メールリレーや配送をサポートするSMTPサーバを含むシステムは、大文字小文 字関係なくローカルの名前で"postmaster"というメールボックスを予約するこ とをサポートしなければならない(MUST)。もし、(セクション3.1で書いたよう に)接続すると常にサーバが554を返すなら、このpostmasterアドレスは厳密に は必要ではない。postmasterへのメールでは、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 "." ends the mail text and cannot be sent by the user. In general, users are not aware of such "forbidden" sequences. To allow all user composed text to be transmitted transparently, the following procedures are used: データの透過性のための条件がないならば、"."という文字のシー クェンスはメールテキストを終らせ、ユーザは送ることができない。 一般に、ユーザはそのような「禁じられた」シークェンスに気付かない。ユー ザが作ったテキストすべてを透過的に転送できるようにするため、以下の手続 きが使われる: Klensin Standards Track [Page 53] RFC 2821 Simple Mail Transfer Protocol April 2001 - 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クライアントは行の最初の文字をチェッ クする。もしそれがピリオドなら、行の最初に1つの追加のピリオドを挿入す る。 - 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サーバが受信したとき、サーバは行をチェックする。 もし行が1つのピリオドで構成されていたなら、それはメールの終わりのしる しとして扱う。もし最初の文字がピリオドでかつ別の文字がその行にあるなら、 最初の文字を削除する。 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 (octets) data stream, the 7-bit ASCII codes are transmitted right justified in the octets, with the high order bits cleared to zero. See 3.7 for special treatment of these conditions in SMTP systems serving a relay function. メールデータは128のASCII文字のいずれを含んでもよい。スペース、バーチカ ルとホライゾンタルタブ、その他のコントロールコードを含むすべての文字が 受信者のメールボックスへと配送されることになる。もし転送チャンネルが8 ビットバイト(オクテット)のデータストリームを提供するならば、7ビットの ASCIIコードは最高位のビットを0にクリアしてオクテットにおさめて転送され る。リレー機能を提供する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以外の文字セットを使うホス ト、文字列よりもレコードとしてデータを蓄積するホスト、メールボックスの 内部で特殊な文字のシークェンスをデリミタとして使っているホストでこれは 必要になるかもしれない。もしそのような変形が必要なら、特に、もしサーバ がメールをリレーするならばそれは可逆でなければならない(MUST)。 4.5.3 Sizes and Timeouts 4.5.3 サイズとタイムアウト 4.5.3.1 Size limits and minimums 4.5.3.1 サイズの上限と下限 There are several objects that have required minimum/maximum sizes. Every implementation MUST be able to receive objects of at least these sizes. Objects larger than these sizes SHOULD be avoided when possible. However, some Internet mail constructs such as encoded X.400 addresses [16] will often require larger objects: clients MAY attempt to transmit these, but MUST be prepared for a server to reject them if they cannot be handled by it. To the maximum extent possible, implementation techniques which impose no limits on the length of these objects should be used. 最小/最大のサイズを要求するいくつかのものがある。それぞれの実装では、 少なくともこれらのサイズのものを受信できなければならない(MUST)。可能な らこれらのサイズより大きいものは避けるべきである(SHOULD)。 しかしながら、エンコードされたX.400アドレスのようにいくつかのインター ネットメールの構造物は、しばしばより大きなものを要求する:クライアント はこれらを送信しようとしてよい(MAY)が、もしサーバによって扱えないなら サーバに拒否される準備をしておかなければならない(MUST)。可能な限り最大 に拡張したら、これらのものの長さは無制限となる実装技術を使うべきである。 local-part The maximum total length of a user name or other local-part is 64 characters. ユーザ名やその他local-partの全体の長さの最大値は64文字である。 domain The maximum total length of a domain name or number is 255 characters. ドメイン名や番号の全体の長さの最大値は255文字である。 Klensin Standards Track [Page 54] RFC 2821 Simple Mail Transfer Protocol April 2001 path The maximum total length of a reverse-path or forward-path is 256 characters (including the punctuation and element separators). reverse-pathやforward-pathの全体の長さの最大値は256文字である(句読点や 要素のセパレータを含む)。 command line The maximum total length of a command line including the command word and the is 512 characters. SMTP extensions may be used to increase this limit. コマンドの単語とを含むコマンドラインの全体の長さの最大値は512文 字である。SMTPの拡張でこの制限を増やしてもよい。 reply line The maximum total length of a reply line including the reply code and the is 512 characters. More information may be conveyed through multiple-line replies. 応答コードとを含む応答の行の全体の長さの最大値は512文字である。 より多くの情報は、複数行応答で送っても良い。 text line The maximum total length of a text line including the is 1000 characters (not counting the leading dot duplicated for transparency). This number may be increased by the use of SMTP Service Extensions. を含むテキストの行の全体の長さの最大値は1000文字である(透過性の ために追加した最初のピリオドは数えない)。SMTPの拡張でこの制限を増やし てもよい。 message content The maximum total length of a message content (including any message headers as well as the message body) MUST BE at least 64K octets. Since the introduction of Internet standards for multimedia mail [12], message lengths on the Internet have grown dramatically, and message size restrictions should be avoided if at all possible. SMTP server systems that must impose restrictions SHOULD implement the "SIZE" service extension [18], and SMTP client systems that will send large messages SHOULD utilize it when possible. メッセージコンテント(メッセージボディ同様メッセージヘッダを含む)の合計 の最大長は少なくとも64Kオクテットでなければならない(MUST)。マルチメディ アメール[12]のためのインターネット標準の導入によりインターネットにおけ るメッセージの長さは劇的に増え、可能ならメッセージサイズの制限は避けら れるべきである。制限を強いるSMTPサーバシステムはサービス拡張"SIZE"を実 装すべき(SHOULD)であり、大きなメッセージを送ろうとするSMTPクライアント システムは可能ならそれを利用すべき(SHOULD)である。 recipients buffer The minimum total number of recipients that must be buffered is 100 recipients. Rejection of messages (for excessive recipients) with fewer than 100 RCPT commands is a violation of this specification. The general principle that relaying SMTP servers MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation tests on message headers suggests that rejecting a message based on the total number of recipients shown in header fields is to be discouraged. A server which imposes a limit on the number of recipients MUST behave in an orderly fashion, such as to reject additional addresses over its limit rather than silently discarding addresses previously accepted. A client that needs to deliver a message containing over 100 RCPT commands SHOULD be prepared to transmit in 100-recipient "chunks" if the server declines to accept more than 100 recipients in a single message. バッファに置かれなければならない受信者の総数の最小値は100である。100の RCPTよりも少ない受信者数で(受信者過多で)メッセージを拒否するのは、この 標準に反している。メッセージヘッダを試験する検証をリレーするSMTPサーバ はしてはならず(MUST NOT)、配送するSMTPサーバはすべきではない(SHOULD NOT)という一般原理は、ヘッダフィールドにある受信者の総数基づいてメッセー ジを拒否することができないことを示唆する。受信者の数に制限を課すサーバ は、前に受け入れられたアドレスを黙って捨てるよりも制限を超えた過剰なア ドレスを拒否するような、規則的な方法でふるまわなければならない(MUST)。 100を超えるRCPTコマンドを持つメッセージを配送する必要があるクライアン トは、もしサーバが1つのメッセージに100を超える受信者を受け入れるのを拒 否したならば、100の受信者ごとに「ぶつ切り」にして転送する準備をするべ きである(SHOULD)。 Errors due to exceeding these limits may be reported by using the reply codes. Some examples of reply codes are: これらの制限を超えたことによるエラーは、応答コードを用いて報告されるか もしれない。いくつかの応答コードの例は以下の通りである: Klensin Standards Track [Page 55] RFC 2821 Simple Mail Transfer Protocol April 2001 500 Line too long. or 501 Path too long or 452 Too many recipients (see below) or 552 Too much mail data. RFC 821 [30] incorrectly listed the error where an SMTP server exhausts its implementation limit on the number of RCPT commands ("too many recipients") as having reply code 552. The correct reply code for this condition is 452. Clients SHOULD treat a 552 code in this case as a temporary, rather than permanent, failure so the logic below works. RFC 821[30]ではSMTPサーバがRCPTコマンドの数実装の制限を使いはたすエラー (多すぎる受信者)を応答コード552を持つものとして、間違って並べている。 この状況に対する正しい応答コードは452である。クライアントは、以下のロ ジックが働くようこの場合の552コードを永続的というより一時的な失敗とし て扱うべきである(SHOULD)。 When a conforming SMTP server encounters this condition, it has at least 100 successful RCPT commands in its recipients buffer. If the server is able to accept the message, then at least these 100 addresses will be removed from the SMTP client's queue. When the client attempts retransmission of those addresses which received 452 responses, at least 100 of these will be able to fit in the SMTP server's recipients buffer. Each retransmission attempt which is able to deliver anything will be able to dispose of at least 100 of these recipients. 適合したSMTPサーバがこの状況に出逢ったとき、少なくとも100の成功した RCPTコマンドを、サーバの受信者バッファに入れる。もしサーバがメッセージ を受け入れることができるなら、この少なくとも100のアドレスはSMTPクライ アントのキューから消される。クライアントが452応答を得たこれらのアドレ スの再転送を試みたとき、これらの少なくとも100はSMTPサーバの受信者バッ ファに適合する。それぞれの、どんなものでも送れる再転送の試みは少なくと もこれらの100の受信者を処理できる。 If an SMTP server has an implementation limit on the number of RCPT commands and this limit is exhausted, it MUST use a response code of 452 (but the client SHOULD also be prepared for a 552, as noted above). If the server has a configured site-policy limitation on the number of RCPT commands, it MAY instead use a 5XX response code. This would be most appropriate if the policy limitation was intended to apply if the total recipient count for a particular message body were enforced even if that message body was sent in multiple mail transactions. もしSMTPサーバがRCPTコマンドの数に制限のある実装をしていてかつその制限 を使いはたしたならば、サーバは452の応答コードを使わなければならない (MUST)(しかしクライアントは上で注意したように552についても準備しておく べきである(SHOULD))。もしサーバがRCPTコマンドの数にサイトポリシー上の 制限を設定しているならば、サーバは5XXの応答コードを用いてもよい(MAY)。 メッセージボディが複数のメールトランザクションで送られた場合さえ、もし 特定のメッセージボディについて受信者の総数を数えられるなら、これはポリ シーによる制限を適用することを意図しているなら最も適切であろう。 4.5.3.2 Timeouts 4.5.3.2 タイムアウト An SMTP client MUST provide a timeout mechanism. It MUST use per- command timeouts rather than somehow trying to time the entire mail transaction. Timeouts SHOULD be easily reconfigurable, preferably without recompiling the SMTP code. To implement this, a timer is set 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クライアントはタイムアウトのメカニズムを提供しなければならない (MUST)。クライアントはメールトランザクション全体の時間に関して何かをす るよりむしろ、コマンドごとにタイムアウトを用いなければならない(MUST)。 タイムアウトは、なるべくならSMTPのコードをコンパイルし直すことなく、簡 単に設定し直せるべきである(SHOULD)。これを実装するために、それぞれの SMTPコマンドとそれぞれのデータ転送バッファに対してタイマーがセットされ る。後者は、全体にわたるタイムアウトは本質的にメッセージのサイズに比例 することを意味する。 Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows: 多忙なメールリレーホストでの広域の経験に基づき、コマンドごとの最小のタ イムアウト値は以下の通りであるべきである(SHOULD): Klensin Standards Track [Page 56] RFC 2821 Simple Mail Transfer Protocol April 2001 Initial 220 Message: 5 minutes An SMTP client process needs to distinguish between a failed TCP connection and a delay in receiving the initial 220 greeting message. Many SMTP servers accept a TCP connection but delay delivery of the 220 message until their system load permits more mail to be processed. 初期化の220メッセージ:5分 SMTPクライアントのプロセスでは、TCPコネクションの失敗と220の挨拶メッセー ジの初期化の受信の遅れとを区別する必要がある。多くのSMTPサーバはTCPコ ネクションを受け入れるが、そのシステムの負荷がより多くのメールを処理で きるまで、220メッセージを送るのを遅らせる。 MAIL Command: 5 minutes MAILコマンド:5分 RCPT Command: 5 minutes A longer timeout is required if processing of mailing lists and aliases is not deferred until after the message was accepted. RCPTコマンド:5分 もしメーリングリストと別名の処理が、メッセージを受信するまで違わないな らば、、より長いタイムアウトが必要とされる。 DATA Initiation: 2 minutes This is while awaiting the "354 Start Input" reply to a DATA command. DATA初期化:2分 これはDATAコマンドに対する"354 Start Input"応答を待つ間である。 Data Block: 3 minutes This is while awaiting the completion of each TCP SEND call transmitting a chunk of data. DATAブロック:3分 これはデータのぶつ切りを転送するそれぞれのTCP SENDコールの完了を待つ間 である。 DATA Termination: 10 minutes. This is while awaiting the "250 OK" reply. When the receiver gets the final period terminating the message data, it typically performs processing to deliver the message to a user mailbox. A spurious timeout at this point would be very wasteful and would typically result in delivery of multiple copies of the message, since it has been successfully sent and the server has accepted responsibility for delivery. See section 6.1 for additional discussion. DATAの終わり: 10分 これは"250 OK"応答を待つ間である。受信者がメッセージデータが終了する最 後のピリオドを受信したとき、通常はメッセージをユーザのメールボックスへ と配信する処理を行う。この時点における偽のタイムアウトは極めて無駄であ り、送信が成功してサーバが配送の責任を受け入れているので、概してメッセー ジの複数のコピーが配送される結果となるだろう。さらなる議論はセクション 6.1を見よ。 An SMTP server SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender. SMTPサーバは、送り手からの次のコマンドを待つ間として、少なくとも5分の タイムアウトを持つべきである(SHOULD)。 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 and the number and size of mailing lists supported by the host. We describe several optimizations that have proved helpful, particularly for mailers supporting high traffic levels. ホストでのSMTPの実装における一般的な構造では、ユーザのメールボックス、 1つないしそれ以上の輸送中のキューに入ったメッセージのための場所、1つな いしそれ以上のメール送受信のためのデーモンプロセスからなる。正確な構造 は、ホストにおけるユーザの必要とすることと、そのホストによってサポート されるメーリングリストの数と規模に依存して変わる。我々は、特に高トラ フィックレベルをサポートするメーラにとって助けになることがわかっている いくつかの最適化について書く。 Any queuing strategy MUST include timeouts on all activities on a per-command basis. A queuing strategy MUST NOT send error messages in response to error messages under any circumstances. キューする戦略では、コマンドごとを基調としたすべての活動のタイムアウト を含まなければならない(MUST)。キューする戦略では、いかなる状況であれエ ラーメッセージの応答にエラーメッセージを送ってはならない(MUST NOT)。 Klensin Standards Track [Page 57] RFC 2821 Simple Mail Transfer Protocol April 2001 4.5.4.1 Sending Strategy 4.5.4.1 送信の戦略 The general model for an SMTP client is one or more processes that periodically attempt to transmit outgoing mail. In a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender. A mail queue entry will include not only the message itself but also the envelope information. SMTPクライアントの一般的モデルは、1つないし複数の、周期的に出て行くメー ルを転送する試みの処理である。典型的なシステムでは、メッセージを作成し たプログラムは、即座に転送できないメールはキューされ、送り手によって周 期的に再試行されなければならない(MUST)ので、新しく出て行くメールに注意 して即座に送信要求するいくつかの方法を持っている。メールキューエントリ はメッセージそのものだけでなく、エンベロープ情報も含むだろう。 The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery. 送り手は1度の試行が失敗した後、特定のあて先への再試行を遅延しなければ ならない(MUST)。一般に、再試行の間隔は少なくとも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日は必要である。再試行アルゴリズムのパラメータ は設定可能でなければならない(MUST)。 A client SHOULD keep a list of hosts it cannot reach and corresponding connection timeouts, rather than just retrying queued mail items. クライアントは、キューされたメールを単に再送するよりむしろ、到達不能で 対応するコネクションがタイムアウトしたホストのリストを保持すべきである (SHOULD)。 Experience suggests that failures are typically transient (the target system or its connection has crashed), favoring a policy of two connection attempts in the first hour the message is in the queue, and then backing off to one every two or three hours. 経験によれば、失敗は一般に一時的(対象のシステムかその接続がクラッシュ している)であり、好ましいポリシーはメッセージがキューに存在する最初の1 時間に2回の接続を試し、そののち2時間ないし3時間ごとに追い出す。 The SMTP client can shorten the queuing delay in cooperation with the SMTP server. For example, if mail is received from a particular address, it is likely that mail queued for that host can now be sent. Application of this principle may, in many cases, eliminate the requirement for an explicit "send queues now" function such as ETRN [9]. SMTPクライアントはSMTPサーバと協力してキューの遅延を短かくすることがで きる。例えば、特定のアドレスからメールが受信されたなら、そのホストへの キューに入ったメールは、今送ることができそうである。多くの場合、この原 理の応用はETRN[9]のような、明白な「今キューを送る」機能への要求を取り 除くかもしれない。 The strategy may be further modified as a result of multiple addresses per host (see below) to optimize delivery time vs. resource usage. この戦略はさらに、配送時間対資源の利用での最適化のため、ホストごと(以 下を見よ)の複数のアドレスの結果で変更されるかもしれない。 An SMTP client may have a large queue of messages for each unavailable destination host. If all of these messages were retried in every retry cycle, there would be excessive Internet overhead and the sending system would be blocked for a long period. Note that an SMTP client can generally determine that a delivery attempt has failed only after a timeout of several minutes and even a one-minute Klensin Standards Track [Page 58] RFC 2821 Simple Mail Transfer Protocol April 2001 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クライアントは、利用不能な宛て先ホストそれぞれのためのメッセージの 大きなキューを持つかもしれない。これらのメッセージのすべてが再試行サイ クル毎に再試行されるならば、過剰なインターネットへのオーバーヘッドであ り、送信システムは長時間、ブロックされるだろう。一般に、もし再試行が、 同じホストへとキューされたメッセージを12回、100回でさえ繰り返されるな らば、数分のタイムアウトと、コネクションごとの1分のタイムアウトさえ非 常に大きな遅延となり、その後にSMTPクライアントは配送の試みが失敗したこ とを決定することに注意。 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が発行されたならば、異なる応答がサーバから返 されるかもしれない。よりはっきりしているのは、MAILコマンドへの5yz応答 はキャッシュしてはならない(MUST NOT)。 When a mail message is to be delivered to multiple recipients, and the SMTP server to which a copy of the message is to be sent is the same for multiple recipients, then only one copy of the message SHOULD be transmitted. That is, the SMTP client SHOULD use the command sequence: MAIL, RCPT, RCPT,... RCPT, DATA instead of the sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. However, if there are very many addresses, a limit on the number of RCPT commands per MAIL command MAY be imposed. Implementation of this efficiency feature is strongly encouraged. メールメッセージが複数の受信者へと配送され、そのメッセージのコピーが送られ ることになるSMTPサーバが同じく複数の受信者に向けられているとき、そのメッ セージのコピーが1つだけ、送出されるべきである(SHOULD)。つまり、SMTPク ライアントは、MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA の代わりに MAIL, RCPT, RCPT,... RCPT, DATA のコマンドシークェンスを用いるべきである (SHOULD)。しかしながら、もし非常に多くのアドレスがあった場合には、MAIL コマンドごとのRCPTコマンドの数の制限が課されてもよい(MAY)。この効率性 に関する特徴の実装は、強く推奨される。 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クライアントはメー ルが出ていくときのトランザクションを複数同時にサポートしてもよい(MAY)。 しかしながら、全ての資源をメールに使ってしまうことからホストを守るのに 適切な制限が課されてもよい。 4.5.4.2 Receiving Strategy 4.5.4.2 受信の戦略 The SMTP server SHOULD attempt to keep a pending listen on the SMTP port at all times. This requires the support of multiple incoming TCP connections for SMTP. Some limit MAY be imposed but servers that cannot handle more than one SMTP transaction at a time are not in conformance with the intent of this specification. SMTPサーバは常にSMTPポートをリスンしつづける試みをすべきである(SHOULD)。 これにより、SMTPのために複数のTCPコネクションが複数入ってくることをサ ポートすることが必要とされる。いくつかの制限が課されるかもしれない (MAY)が、一時に複数のSMTPトランザクションを扱えないサーバはこの仕様の 意図に適合しない。 As discussed above, when the SMTP server receives mail from a particular host address, it could notify the SMTP client to retry any mail pending for that host address. 上で議論したように、SMTPサーバが特定のホストアドレスからメールを受けとっ たとき、そのホストアドレスへの保留していたメールを再試行するようSMTPクラ イアントへ知らせることができる。 4.5.5 Messages with a null reverse-path 4.5.5 ヌルのreverse-pathを持つメッセージ 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, 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 Klensin Standards Track [Page 59] RFC 2821 Simple Mail Transfer Protocol April 2001 delivery of such a notification message fails, that usually indicates a problem with the mail system of the host to which the notification message is addressed. For this reason, at some hosts the MTA is set up to forward such failed notification messages to someone who is able to fix problems with the mail system, e.g., via the postmaster alias.) 現存する、あるいは提案されている標準によって、ヌルのreverse-pathを持っ て送られることが要求されるいくつかの型のお知らせメッセージがあり、それ はすなわち、セクション3.7で議論した配送不能のお知らせ、別種の配送状態 のお知らせ(DSNs)[24]、メッセージの性質のお知らせ(MDNs)[10]である。 これらすべての種類のメッセージは以前のメッセージについてのお知らせであ り、以前のメールメッセージのreverse-pathへと送られる。 (もしもそのようなお知らせメッセージの配送が失敗すると、それはたいてい お知らせメッセージの送り先のホストのメールシステムに関する問題を示す。 この理由から、いくつかのホストではMTAはそのような失敗のお知らせメッセー ジを、メールシステムの問題を修正できる人、例えば別名であるpostmasterを 経由して、へと転送するように作られている。) All other types of messages (i.e., any message which is not required by a standards-track RFC to have a null reverse-path) SHOULD be sent with with a valid, non-null reverse-path. 全ての他の型のメッセージは(つまり、標準化段階にあるRFCでヌルの reverse-pathを持つことが要求されていないメッセージは)、有効な、ヌルで ないreverse-pathを持つべきである(SHOULD)。 Implementors of automated email processors should be careful to make sure that the various kinds of messages with null reverse-path are handled correctly, in particular such systems SHOULD NOT reply to messages with null reverse-path. 自動化されたemailの処理装置を作る人は、ヌルのreverse-pathを持ついろい ろな種類のメッセージを正しく扱えるよう、注意深く手段を講じるべきであり、 特にそのようなシステムはヌルの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に書いた)、DNS lookupがドメイン名の解決 のため、なされなければならない(MUST)[22]。名前としてはFQDNが期待される: 部分名やローカルの別名からFQDNを推測するための機構はこの標準の範囲外で あり、長年問題となってきたことから、一般には推奨されない。lookupは最初 に名前に関連するMXレコードの場所を探そうとする。もし代わりにCNAMEレコー ドが見つかったら、見つかった名前をそれが最初の名前であるかのように処理 する。もしMXレコードが見つからないがA RRが見つかったなら、A RRを、暗黙 にそのホストを指すpreference値が0のMX RRと関連しているかのように扱う。 もしも1つないし複数のMX RRが与えられた名前に対して見付かったならば、そ れらがMX RRで使われる場所を見つけた場合を除きSMTPシステムはその名前に 関連づけられたA RRを用いてはならない(MUST NOT);上記の暗黙のMXルールは、 MXレコードが存在しない場合に限って適用される。もしMXレコードが存在する がいずれも利用できないならば、その状況はエラーとして報告されなければな らない(MUST)。 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. lookupが成功したとき、複数のMXレコードやマルチホームや両方といった理由 から、マッピングは単一のアドレスよりむしろ代わりの配送アドレスのリスト として得られるかもしれない。信用できるメールトランザクションを提供する ため、SMTPクライアントは配送の試みが成功するまで、リスト中の関連するそ れぞれのアドレスをこの順番で試さ(再試行し)なければならない(MUST)。しか しながら、試行できる代わりのアドレス数に設定できる限界もあるかもしれな い。このような場合、SMTPクライアントは少なくとも2つのアドレスを試すべ きである(SHOULD)。 Two types of information is used to rank the host addresses: multiple MX records, and multihomed hosts. ホストアドレスをランク付けるのに2つの型の情報が使われる:複数のMXレコー ドとマルチホームホストである。 Klensin Standards Track [Page 60] RFC 2821 Simple Mail Transfer Protocol April 2001 Multiple MX records contain a preference indication that MUST be used in sorting (see below). Lower numbers are more preferred than higher ones. If there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by recognition of an easily-reached address), then the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization. 複数のMXレコードは順位付けに使われなければならない(MUST)優先度 (preference)の印を持つ(以下を見よ)。小さい数字は、大きいものより優先さ れる。もしも同じ優先度を持つ複数の宛て先があり、かつどれかが好まれる明 確な理由(例えば、容易に到達できるアドレスであると理解された)がないなら ば、送り手のSMTPは特定の組織に複数あるメールエクスチェンジャ全体に負荷 を分散するために、それらから無作為に選ばなければならない(MUST)。 The destination host (perhaps taken from the preferred MX record) may be multihomed, in which case the domain name resolver will return a list of alternative IP addresses. It is the responsibility of the domain name resolver interface to have ordered this list by decreasing preference if necessary, and SMTP MUST try them in the order presented. 宛て先ホスト(おそらく優先されたMXレコードをとる)は、ドメイン名のリゾル バが代わりのIPアドレスのリストを返す場合マルチホームされているかもしれ ない。ドメイン名のリゾルバのインターフェイスは、必要なら減少する優先度 によりこのリストを並べる責任を持ち、SMTPは現存する順番に試さなければな らない(MUST)。 Although the capability to try multiple alternative addresses is required, specific installations may want to limit or disable the use of alternative addresses. The question of whether a sender should attempt retries using the different addresses of a multihomed host has been controversial. The main argument for using the multiple addresses is that it maximizes the probability of timely delivery, and indeed sometimes the probability of any delivery; the counter- argument is that it may result in unnecessary resource use. Note that resource use is also strongly determined by the sending strategy discussed in section 4.5.4.1. 複数の代わりのアドレスを試す能力が要求されているにもかかわらず、限定さ れた設定では代わりのアドレスを利用することを制限したり不可能にしたりし たいかもしれない。送り手がマルチホームホストの異なるアドレスを用いて再 試行するべきかどうかという問いは、意見のわかれるところである。複数アド レスを用いる主要な議論は、タイムリーな配送や、実際時にはいかなる配送の 可能性をも最大化する;反対の議論は、必要ではない資源を利用する結果にな るかもしれない。資源の利用はセクション4.5.4.1での送信戦略の議論でも強 く決定されている点に注意。 If an SMTP server receives a message with a destination for which it is a designated Mail eXchanger, it MAY relay the message (potentially after having rewritten the MAIL FROM and/or RCPT TO addresses), make final delivery of the message, or hand it off using some mechanism outside the SMTP-provided transport environment. Of course, neither of the latter require that the list of MX records be examined further. もしもSMTPサーバが指定されたメールエクスチェンジャ宛てへのメッセージを 受信したならば、サーバはメッセージをリレーするか(もしかするとMAIL FROM と/あるいはRCPT TOアドレスを書換えた後かもしれない)、メッセージの最終 配送をするか、SMTPが提供されている配送環境の外へと何らかの機構を用いて 送り出すかして良い。もちろん、後者の要求ではMXレコードのリストを確認す ることはもはやなされない。 If it determines that it should relay the message without rewriting the address, it MUST sort the MX records to determine candidates for delivery. The records are first ordered by preference, with the lowest-numbered records being most preferred. The relay host MUST then inspect the list for any of the names or addresses by which it might be known in mail transactions. If a matching record is found, all records at that preference level and higher-numbered ones MUST be discarded from consideration. If there are no records left at that point, it is an error condition, and the message MUST be returned as undeliverable. If records do remain, they SHOULD be tried, best preference first, as described above. もし、それがアドレスを書換えることなくメッセージをリレーすることを決定 したならば、それは配送に向けての候補を決定するためにMXレコードを並べな ければならない(MUST)。そのレコードは、一番小さな数字のレコードが最も優 先されるよう、まず優先度に応じて並べられる。リレーホストはメールトラン ザクションで知られているかもしれない名前やアドレスのリストを調査しなけ ればならない。もし一致するレコードが見付かれば、熟慮により同じかより大 きな優先度の値を持つすべてのレコードが捨てられなければならない(MUST)。 もしもその時点でレコードが残っていないならばエラーの状況であり、メッセー ジは配送不能で送り返されなければならない(MUST)。もしレコードが残ってい るならば、それらは上に記したように、最善の優先度のものが最初に試される べきである(SHOULD)。 Klensin Standards Track [Page 61] RFC 2821 Simple Mail Transfer Protocol April 2001 ---- 訳について この訳は、美森勇気 が個人的な目的で行いました。利用 は自由ですが、一切の保証はしません。