RFC 7504 - SMTP 521 and 556 Reply Codes 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7504
タイトル : RFC 7504 - SMTP 521および556応答コード
翻訳編集 : 自動生成

[要約] RFC 7504は、SMTPプロトコルにおける521および556の応答コードに関するガイドラインを提供しています。このRFCの目的は、これらの新しい応答コードを導入し、SMTPサーバーのエラーハンドリングと通信の信頼性を向上させることです。

Internet Engineering Task Force (IETF)                        J. Klensin
Request for Comments: 7504                                     June 2015
Updates: 1846, 5321
Category: Standards Track
ISSN: 2070-1721

SMTP 521 and 556 Reply Codes

SMTP 521および556応答コード

Abstract

概要

This memo defines two Simple Mail Transfer Protocol (SMTP) reply codes, 521 and 556. The 521 code was originally described in an Experimental RFC in 1995 and is in wide use, but has not previously been formally incorporated into SMTP. The 556 code was created to support the new tests and actions specified in RFC 7505. These codes are used to indicate that an Internet host does not accept incoming mail at all. This specification is not applicable when the host sometimes accepts mail but may reject particular messages, or even all messages, under specific circumstances.

このメモは、2つのSimple Mail Transfer Protocol（SMTP）応答コード521および556を定義しています。521コードは、もともと1995年の実験的RFCで記述され、広く使用されていますが、以前は正式にSMTPに組み込まれていません。 556コードは、RFC 7505で指定された新しいテストとアクションをサポートするために作成されました。これらのコードは、インターネットホストが受信メールをまったく受け入れないことを示すために使用されます。ホストがメールを受け入れることがあるが、特定の状況で特定のメッセージまたはすべてのメッセージを拒否する場合は、この仕様は適用されません。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7504.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7504で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The 521 Reply Code  . . . . . . . . . . . . . . . . . . . . .   4
   4.  The 556 Reply Code  . . . . . . . . . . . . . . . . . . . . .   4
   5.  Small Details to Avoid Loose Ends . . . . . . . . . . . . . .   5
     5.1.  Specific Changes to RFC 5321  . . . . . . . . . . . . . .   5
     5.2.  The RFC 1846 Experiment . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1. Introduction

1. はじめに

The SMTP specification [2] (referred to, along with its various updates, as "SMTP" below) contains a list and discussion of reply codes. This document updates that list with a new code, 521, for use in response to an initial connection. In that context, it specifically denotes a system that does not receive mail or otherwise handle SMTP mail or inquiry transactions. That code differs from the use of reply code 554, recommended by RFC 5321, because the latter code can be used in a larger variety of situations, including mail that is not accepted for, or from, particular sources, destinations, or addresses. It also introduces a second reply code, 556, for use when an SMTP client encounters a domain in a forward-pointing address that it can determine (e.g., from the DNS "null MX" convention [5]) does not support receipt of mail and has to report that condition to a host that delivered the message to it for further processing.

SMTP仕様[2]（以下の「SMTP」と呼ばれるさまざまな更新と共に参照）には、応答コードのリストと説明が含まれています。このドキュメントは、初期接続に応答して使用するために、新しいコード521でそのリストを更新します。そのコンテキストでは、メールを受信しない、またはSMTPメールや照会トランザクションを処理しないシステムを具体的に示します。このコードは、RFC 5321で推奨されている応答コード554の使用とは異なります。後者のコードは、特定の送信元、宛先、アドレスから、または特定の送信元、宛先、アドレスに受け入れられないメールなど、さまざまな状況で使用できるためです。また、SMTPクライアントが（DNSの「null MX」規則[5]などから）フォワードポインティングアドレスでドメインに遭遇し、メールの受信をサポートしていない場合に使用する2番目の応答コード556も導入します。さらにその処理を行うためにメッセージを配信したホストにその状態を報告する必要があります。

This specification updates RFC 5321 to add the new codes. The 521 code was first formally proposed in the Experimental RFC 1846 [4]; this document updates that specification to standardize the code and provide more specific treatment of it.

この仕様は、新しいコードを追加するためにRFC 5321を更新します。 521コードは、最初に実験的RFC 1846 [4]で正式に提案されました。このドキュメントは、その仕様を更新してコードを標準化し、より具体的な処理を提供します。

1.1. Terminology

1.1. 用語

The reader of this document is expected to have reasonable familiarity with the SMTP specification in RFC 5321, particularly its discussion of reply codes and their use and theory.

このドキュメントの読者は、RFC 5321のSMTP仕様、特に応答コードとその使用法および理論についての議論に精通していることが求められます。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [1]で説明されているように解釈されます。

2. Background

2. バックグラウンド

Many Internet hosts are not in a position -- whether technically, operationally, or administratively -- to offer mail service. If an SMTP client (sender) attempts to open a mail connection to a system that does not have an SMTP server, the connection attempt will time out. SMTP requires that timeouts result in the client queuing the message and retrying it for an extended period. That behavior will result in wasted resources and long delays in getting an error message back to its originator.

多くのインターネットホストは、技術的、運用上、または管理上、メールサービスを提供する立場にありません。 SMTPクライアント（送信者）が、SMTPサーバーのないシステムへのメール接続を開こうとすると、接続の試行はタイムアウトします。 SMTPでは、タイムアウトの結果、クライアントがメッセージをキューに入れ、長期間再試行する必要があります。その動作により、リソースが無駄になり、エラーメッセージがその発信者に返されるまでに長い遅延が発生します。

One alternative is to run a dummy SMTP server on hosts that do not receive mail under any circumstances and have that dummy server return a fatal error reply code in response to any connection-opening attempt. Another is to determine, from a separate source such as a DNS record, that the host does not receive mail. This document specifies reply codes to be used for those purposes.

1つの代替策は、どのような状況でもメールを受信しないホスト上でダミーのSMTPサーバーを実行し、そのダミーサーバーが接続を開こうとすると、致命的なエラー応答コードを返すようにすることです。もう1つは、DNSレコードなどの別のソースから、ホストがメールを受信しないことを確認することです。このドキュメントでは、これらの目的で使用される返信コードを指定します。

3. The 521 Reply Code

3. 521応答コード

This specification adds the 521 reply code to the repertoire specified in SMTP, reserving it for use at connection-opening time to indicate that the host does not accept mail under any circumstances. It SHOULD be used for dummy SMTP servers whose sole purpose is to notify systems that attempt to open mail connections that the host never accepts mail. It MAY be used in other situations where the intent is to indicate that the host never accepts mail. It SHOULD NOT be used for situations in which the server rejects mail from particular hosts or addresses or in which mail for a particular destination host is not accepted. As discussed in SMTP, reply code 554 is more appropriate for most of those conditions; an additional case, in which the determination that mail is not accepted is determined outside the mail system, is covered in the next section (Section 4).

この仕様は、SMTPで指定されたレパートリーに521応答コードを追加し、接続開始時に使用できるように予約して、ホストがいかなる状況でもメールを受け入れないことを示します。ホストがメールを受け取らないことをメール接続を開こうとするシステムに通知することを唯一の目的とするダミーのSMTPサーバーに使用する必要があります。ホストがメールを決して受け入れないことを意図する他の状況で使用されるかもしれません。サーバーが特定のホストまたはアドレスからのメールを拒否する場合、または特定の宛先ホストへのメールが受け付けられない場合は、使用しないでください。 SMTPで説明したように、応答コード554はこれらの条件のほとんどに適しています。メールが受け入れられないとの決定がメールシステムの外部で決定される追加のケースについては、次のセクション（セクション4）で説明します。

"Server does not accept mail" (or a variant such as "Host", "Domain", or a related term) is an acceptable message to accompany a 521 code used for this purpose.

「サーバーはメールを受け付けません」（または「ホスト」、「ドメイン」、または関連用語などの変形）は、この目的で使用される521コードに伴う許容メッセージです。

Once the 521 reply code is returned instead of the usual 220, the SMTP session proceeds normally. If the SMTP client attempts to send additional commands other than QUIT, the server MAY either continue sending 521 reply codes or simply close the connection. If the purpose of running a dummy SMTP server that returns a 521 code is to conserve resources, the latter will usually be preferable.

通常の220ではなく521の応答コードが返されると、SMTPセッションは正常に続行されます。 SMTPクライアントがQUIT以外の追加のコマンドを送信しようとした場合、サーバーは521応答コードの送信を続行するか、単に接続を閉じます。 521コードを返すダミーのSMTPサーバーを実行する目的がリソースの節約である場合、通常は後者が推奨されます。

4. The 556 Reply Code

4. 556応答コード

This specification adds the 556 reply code to the repertoire specified in SMTP. When an intermediate SMTP system (typically a relay) that would normally attempt to open a mail connection to a host referred to in a forward-pointing address can determine that the host does not accept mail connections, and do so without attempting to open a connection to that target host, it is appropriate for it to return a reply with a 556 code to the system that sent it the message for outbound transmission. Interpretation of a special DNS record, found when a lookup is performed in conjunction with a RCPT command [5], is one such method (and the only standardized one at the time this specification was written).

この仕様は、SMTPで指定されたレパートリーに556応答コードを追加します。通常は前方参照アドレスで参照されるホストへのメール接続を開こうとする中間SMTPシステム（通常はリレー）が、ホストがメール接続を受け入れないと判断でき、接続を開かずにそうする場合そのターゲットホストに、送信コードを送信したシステムに556コードを含む応答を返すのが適切です。ルックアップがRCPTコマンド[5]と組み合わせて実行されたときに検出される特別なDNSレコードの解釈は、そのような方法の1つです（この仕様が書かれた時点で唯一の標準化された方法です）。

When an SMTP server returns a 556 reply code after receiving a command (such as RCPT, which contains a forward-pointing address) because it has information (such as discussed above) that the mail will not be accepted, the SMTP client is expected to handle the response like any other permanent negative completion reply to the command. This is consistent with the SMTP specification.

SMTPサーバーがコマンド（RCPTなど、前方参照アドレスを含む）を受信した後に556応答コードを返す場合、メールが受け入れられないという（上記で説明したような）情報が含まれているため、SMTPクライアントはコマンドに対する他の永続的な否定完了応答と同様に応答を処理します。これはSMTP仕様と一致しています。

5. Small Details to Avoid Loose Ends

5. ルーズエンドを回避するための小さな詳細

5.1. Specific Changes to RFC 5321

5.1. RFC 5321への特定の変更

This document adds the 521 code, with message "Host does not accept mail", and the 556 code, with message "Domain does not accept mail", to the function group and numerical lists (Sections 4.2.2 and 4.2.3, respectively) of RFC 5321. It also adds the 521 code to the "CONNECTION ESTABLISHMENT" portion of Section 4.3.2 ("Command-Reply Sequences"), preceding the 554 code, and the 556 code to the "RCPT" portion of that same section.

このドキュメントでは、「ホストはメールを受け付けません」というメッセージが含まれる521コードと、「ドメインがメールを受け付けません」というメッセージが含まれる556コードを関数グループと数値リストに追加します（それぞれセクション4.2.2と4.2.3））はRFC 5321のコードです。また、554コードの前に、セクション4.3.2（「コマンド応答シーケンス」）の「CONNECTION ESTABLISHMENT」部分に521コードを追加し、同じコードの「RCPT」部分に556コードを追加します。セクション。

5.2. The RFC 1846 Experiment

5.2. RFC 1846実験

By formalizing reply code 521, this specification ends the experiment proposed in RFC 1846. That document also discusses general strategies for hosts that do not accept mail directly. That discussion is out of scope for the present document.

応答コード521を形式化することにより、この仕様はRFC 1846で提案された実験を終了します。このドキュメントでは、メールを直接受け付けないホストの一般的な戦略についても説明しています。その議論は本文書の範囲外です。

6. IANA Considerations

6. IANAに関する考慮事項

This document updates RFC 5321 to add descriptions and text for two reply codes, but there is no registry for those codes. IANA has updated the "Enumerated Status Codes" subregistry of the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry" [3] to include these codes, specifically:

このドキュメントでは、RFC 5321を更新して2つの応答コードの説明とテキストを追加していますが、これらのコードのレジストリはありません。 IANAは、「Simple Mail Transfer Protocol（SMTP）Enhanced Status Codes Registry」[3]の「Enumerated Status Codes」サブレジストリを更新して、これらのコードを具体的に含めました。

o Added 521 to the list of codes associated with the enhanced code entry for X.3.2, which now references this document.

o このドキュメントを参照するX.3.2の拡張コードエントリに関連するコードのリストに521を追加しました。

o Added this document to the references associated with the enhanced code entry for X.1.10 and reply code 556. Note that, if a use for 556 arises that is not associated with null MX [5], it may be necessary to add an additional enhanced code, but such action is outside the scope of this document.

o このドキュメントを、X.1.10および応答コード556の拡張コードエントリに関連する参照に追加しました。nullMX [5]に関連付けられていない556の使用が発生した場合、追加の拡張コードを追加する必要がある場合があります。コードですが、そのようなアクションはこのドキュメントの範囲外です。

7. Security Considerations

7. セキュリティに関する考慮事項

Not running any SMTP server, or running an SMTP server that simply emits fixed strings in response to incoming connections, should provide significantly fewer opportunities for security problems than running a complete SMTP implementation. See the Security Considerations section of RFC 7505 [5] for a discussion of security issues with that approach. Use of the specific codes provided here provides more information to the client than a generic or arbitrarily chosen 5yz code but should have no other effect on security.

SMTPサーバーを実行していない場合、または着信接続に応答して固定文字列を送信するだけのSMTPサーバーを実行している場合は、完全なSMTP実装を実行するよりもセキュリティ上の問題が発生する可能性が大幅に少なくなります。そのアプローチでのセキュリティ問題の議論については、RFC 7505 [5]のセキュリティに関する考慮事項のセクションを参照してください。ここで提供されている特定のコードを使用すると、一般的なまたは任意に選択された5yzコードよりも多くの情報がクライアントに提供されますが、セキュリティに他の影響はありません。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[1] Bradner、S.、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。

[2] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.

[2] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<http://www.rfc-editor.org/info/rfc5321>。

[3] IANA, "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry", <http://www.iana.org/assignments/smtp-enhanced-status-codes>.

[3] IANA、「Simple Mail Transfer Protocol（SMTP）Enhanced Status Codes Registry」、<http://www.iana.org/assignments/smtp-enhanced-status-codes>。

8.2. Informative References

8.2. 参考引用

[4] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, DOI 10.17487/RFC1846, September 1995, <http://www.rfc-editor.org/info/rfc1846>.

[4] Durand、A.およびF. Dupont、「SMTP 521 Reply Code」、RFC 1846、DOI 10.17487 / RFC1846、1995年9月、<http://www.rfc-editor.org/info/rfc1846>。

[5] Levine, J. and M. Delany, "A "Null MX" No Service Resource Record for Domains That Accept No Mail", RFC 7505, DOI 10.17487/RFC7505, June 2015, <http://www.rfc-editor.org/info/rfc7505>.

[5] Levine、J.およびM. Delany、「A "Null MX" No Service Resource Records that Domains Accept Accept Mails」、RFC 7505、DOI 10.17487 / RFC7505、2015年6月、<http://www.rfc-editor.org / info / rfc7505>。

Acknowledgments

謝辞

Alain Durand and Francis Dupont proposed the 521 code in RFC 1846 [4]. They also participated in an extended conversation and provided many useful comments that led to this document. The document also contains, with their permission, some text copied from that early specification.

Alain DurandとFrancis DupontはRFC 1846で521コードを提案しました[4]。彼らはまた、長い会話に参加し、このドキュメントにつながる多くの有用なコメントを提供しました。ドキュメントには、許可を得て、その初期の仕様からコピーされたテキストも含まれています。

Discussion of the "null MX" approach and proposal [5] inspired the creation of this specification. Specific comments and suggestions from John Levine (co-author of that document) were also helpful.

「null MX」アプローチと提案[5]の議論は、この仕様の作成に影響を与えました。 John Levine（そのドキュメントの共著者）からの具体的なコメントと提案も役に立ちました。

Martin Duerst and Tom Petch identified significant issues in the initial draft of the current form of the document.

Martin DuerstとTom Petchは、現在の形式のドキュメントの最初のドラフトで重要な問題を特定しました。

Dilyan Palauzov did a careful reading and identified an editorial error.

Dilyan Palauzovは注意深く読み、編集上の誤りを特定しました。

Ned Freed, Tony Hansen, and Rolf Sonneveld suggested textual improvements that were incorporated. Tony Hansen also acted as document shepherd and made several contributions in conjunction with that role.

Ned Freed、Tony Hansen、およびRolf Sonneveldは、組み込まれたテキストの改善を提案しました。トニーハンセンはドキュメントシェパードとしても行動し、その役割に関連していくつかの貢献をしました。

Author's Address

著者のアドレス

John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 United States

John C Klensin 1770 Massachusetts Ave、Ste 322 Cambridge、MA 02140 United States

   Phone: +1 617 245 1457
   Email: john-ietf@jck.com