RFC 7505 - A "Null MX" No Service Resource Record for Domains That Accept No Mail 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7505
タイトル : RFC 7505 - メールを受け入れないドメインの「Null MX」サービスリソースレコードなし
翻訳編集 : 自動生成

[要約] RFC 7505は、メールを受け付けないドメインに対して使用される「Null MX」サービスリソースレコードについての規格です。目的は、メールを受け付けないドメインを明示的に示すことで、誤ったメール送信を防止することです。

Internet Engineering Task Force (IETF)                         J. Levine
Request for Comments: 7505                          Taughannock Networks
Category: Standards Track                                      M. Delany
ISSN: 2070-1721                                               Apple Inc.
                                                               June 2015

A "Null MX" No Service Resource Record for Domains That Accept No Mail

メールを受け入れないドメインの「Null MX」サービスリソースレコードなし

Abstract

概要

Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies.

インターネットメールは、最初にMXレコードを探し、次にフォールバックとしてA / AAAAレコードを探すことにより、DNSを介して受信サーバーのアドレスを決定します。残念ながら、これは、そのアドレスがメールを受け付けない場合でも、A / AAAAレコードがメールサーバーアドレスであると解釈されることを意味します。非サービスMX RRは非公式に「null MX」と呼ばれ、ドメインがメールを受け入れないことを通知する既存のメカニズムを公式化します。メールサーバーを用意する必要はありません。これにより、運用効率が大幅に向上します。

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/rfc7505.

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

著作権表示

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   2
   3.  MX Resource Records Specifying Null MX  . . . . . . . . . . .   3
   4.  Effects of Null MX  . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  SMTP Server Benefits  . . . . . . . . . . . . . . . . . .   3
     4.2.  Sending Mail from Domains That Publish Null MX  . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1. Introduction

1. はじめに

This document defines the No Service MX, informally called "null MX", as a simple mechanism by which a domain can indicate that it does not accept email.

このドキュメントでは、非サービスMX（非公式に「null MX」と呼ばれる）を、ドメインが電子メールを受け入れないことを示すことができる単純なメカニズムとして定義しています。

SMTP clients have a prescribed sequence for identifying a server that accepts email for a domain. Section 5 of [RFC5321] covers this in detail; in essence, the SMTP client first looks up a DNS MX RR, and, if that is not found, it falls back to looking up a DNS A or AAAA RR. Hence, this overloads a DNS record (that has a different primary mission) with an email service semantic.

SMTPクライアントには、ドメインの電子メールを受け入れるサーバーを識別するための所定のシーケンスがあります。 [RFC5321]のセクション5では、これについて詳しく説明しています。基本的に、SMTPクライアントは最初にDNS MX RRを検索し、それが見つからない場合は、フォールバックしてDNS AまたはAAAA RRを検索します。したがって、これはDNSレコード（プライマリミッションが異なる）に電子メールサービスセマンティックスをオーバーロードします。

If a domain has no MX records, senders will attempt to deliver mail to the hosts at the addresses in the domain's A or AAAA records. If there are no SMTP listeners at the A/AAAA addresses, message delivery will be attempted repeatedly for a long period, typically a week, before the sending Mail Transfer Agent (MTA) gives up. This will delay notification to the sender in the case of misdirected mail and will consume resources at the sender.

ドメインにMXレコードがない場合、送信者はドメインのAまたはAAAAレコードのアドレスにあるホストにメールを配信しようとします。 A / AAAAアドレスにSMTPリスナーがない場合、送信メール転送エージェント（MTA）が中止する前に、メッセージの配信が長期間（通常は1週間）繰り返し試行されます。これにより、メールが誤って送信された場合に送信者への通知が遅れ、送信者のリソースが消費されます。

This document defines a null MX that will cause all mail delivery attempts to a domain to fail immediately, without requiring domains to create SMTP listeners dedicated to preventing delivery attempts.

このドキュメントは、ドメインへのすべてのメール配信の試行を即座に失敗させるnull MXを定義しています。ドメインが配信の試行を防ぐための専用のSMTPリスナーを作成する必要はありません。

2. Conventions Used in This Document

2. このドキュメントで使用される規則

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 [RFC2119].

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

The terms "RFC5321.MailFrom" and "RFC5322.From" are used as defined in [RFC5598].

「RFC5321.MailFrom」および「RFC5322.From」という用語は、[RFC5598]で定義されているとおりに使用されます。

3. MX Resource Records Specifying Null MX

3. Null MXを指定するMXリソースレコード

To indicate that a domain does not accept email, it advertises a single MX RR (see Section 3.3.9 of [RFC1035]) with an RDATA section consisting of preference number 0 and a zero-length label, written in master files as ".", as the exchange domain, to denote that there exists no mail exchanger for a domain. Since "." is not a valid host name, a null MX record cannot be confused with an ordinary MX record. The use of "." as a pseudo-hostname meaning no service available is modeled on the SRV RR [RFC2782] where it has a similar meaning.

ドメインがメールを受け入れないことを示すために、マスターファイルに「」として記述された、プリファレンス番号0と長さゼロのラベルで構成されるRDATAセクションを持つ単一のMX RR（[RFC1035]のセクション3.3.9を参照）をアドバタイズします。 "、交換ドメインとして、ドメインのメールエクスチェンジャーが存在しないことを示します。「。」以来は有効なホスト名ではありません。nullMXレコードを通常のMXレコードと混同することはできません。の用法 "。"使用可能なサービスがないことを意味する疑似ホスト名としてSRV RR [RFC2782]でモデル化されており、同様の意味を持っています。

A domain that advertises a null MX MUST NOT advertise any other MX RR.

null MXをアドバタイズするドメインは、他のMX RRをアドバタイズしてはいけません。

4. Effects of Null MX

4. Null MXの影響

The null MX record has a variety of efficiency and usability benefits.

null MXレコードには、さまざまな効率と使いやすさの利点があります。

4.1. SMTP Server Benefits

4.1. SMTPサーバーの利点

Mail often has an incorrect address due to user error, where the address was mistranscribed or misunderstood, for example, to alice@www.example.com, alice@example.org, or alice@examp1e.com rather than alice@example.com. Null MX allows a mail system to report the delivery failure when the user sends the message, rather than hours or days later.

ユーザーエラーが原因でメールのアドレスが間違っていることがよくあります。たとえば、alice @ example.comではなく、alice @ www.example.com、alice @ example.org、alice @ examp1e.comにアドレスが誤って転記または誤解されています。。 Null MXを使用すると、メールシステムは、ユーザーがメッセージを送信するときに、数時間または数日後ではなく、配信の失敗を報告できます。

Senders of abusive mail often use forged undeliverable return addresses. Null MX allows Delivery Status Notifications (DSNs) and other attempted responses to such mail to be disposed of efficiently.

不正なメールの送信者は、偽造された配信不能な返信アドレスを使用することがよくあります。 Null MXを使用すると、Delivery Status Notifications（DSN）およびそのようなメールに対して試行されたその他の応答を効率的に破棄できます。

The ability to detect domains that do not accept email offers resource savings to an SMTP client. It will discover on the first sending attempt that an address is not deliverable, avoiding queuing and retries.

電子メールを受け入れないドメインを検出する機能により、SMTPクライアントのリソースを節約できます。最初の送信試行時に、アドレスが配信不能であることを発見し、キューイングと再試行を回避します。

When a submission or SMTP relay server rejects an envelope recipient due to a domain's null MX record, it SHOULD use a 556 reply code [RFC7504] (Requested action not taken: domain does not accept mail) and a 5.1.10 enhanced status code (Permanent failure: Recipient address has null MX).

送信またはSMTPリレーサーバーがドメインのnull MXレコードのためにエンベロープ受信者を拒否する場合、556応答コード[RFC7504]（要求されたアクションは実行されません：ドメインはメールを受け入れません）と5.1.10拡張ステータスコード（永続的なエラー：受信者のアドレスにnullのMXがあります）。

A receiving SMTP server that chooses to reject email during the SMTP conversation that presents an undeliverable RFC5321.MailFrom or RFC5322.From domain can be more confident that for other messages a subsequent attempt to send a DSN or other response will reach a recipient SMTP server.

配信不能なRFC5321.MailFromまたはRFC5322.Fromドメインを提示するSMTP会話中に電子メールを拒否することを選択する受信SMTPサーバーは、他のメッセージについて、DSNまたは他の応答を送信する後続の試みが受信者のSMTPサーバーに到達することをより確信できます。

SMTP servers that reject mail because a RFC5321.MailFrom or RFC5322.From domain has a null MX record SHOULD use a 550 reply code (Requested action not taken: mailbox unavailable) and a 5.7.27 enhanced status code (Permanent failure: Sender address has null MX).

RFC5321.MailFromまたはRFC5322.FromドメインにnullのMXレコードがあるためにメールを拒否するSMTPサーバーは、550応答コード（要求されたアクションは実行されません：メールボックスを利用できません）と5.7.27拡張ステータスコード（永続的なエラー：送信者アドレスがnull MX）。

4.2. Sending Mail from Domains That Publish Null MX

4.2. Null MXを公開するドメインからのメールの送信

Null MX is primarily intended for domains that do not send or receive any mail, but have mail sent to them anyway due to mistakes or malice. Many receiving systems reject mail that has an invalid return address. Return addresses are needed to allow the sender to handle message delivery errors. An invalid return address often signals that the message is spam. Hence, mail systems SHOULD NOT publish a null MX record for domains that they use in RFC5321.MailFrom or RFC5322.From addresses. If a system nonetheless does so, it risks having its mail rejected.

Null MXは主に、メールを送受信しないが、間違いや悪意のためにメールが送信されているドメインを対象としています。多くの受信システムは、無効な返信アドレスを持つメールを拒否します。返信アドレスは、送信者がメッセージ配信エラーを処理できるようにするために必要です。無効な返信アドレスは、メッセージがスパムであることを示すことがよくあります。したがって、メールシステムは、RFC5321.MailFromまたはRFC5322.Fromアドレスで使用するドメインのnull MXレコードを公開してはなりません（SHOULD NOT）。それでもシステムがそうする場合、メールが拒否されるリスクがあります。

Operators of domains that do not send mail can publish Sender Policy Framework (SPF) "-all" policies [RFC7208] to make an explicit declaration that the domains send no mail.

メールを送信しないドメインのオペレーターは、Sender Policy Framework（SPF）の "-all"ポリシー[RFC7208]を公開して、ドメインがメールを送信しないことを明示的に宣言できます。

Null MX is not intended to be a replacement for the null reverse-path described in Section 4.5.5 of RFC 5321 and does not change the meaning or use of a null reverse-path.

Null MXは、RFC 5321のセクション4.5.5で説明されているnullリバースパスの代わりになるものではなく、nullリバースパスの意味や使用方法を変更するものではありません。

5. Security Considerations

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

Within the DNS, a null MX RR is an ordinary MX record and presents no new security issues. If desired, it can be secured in the same manner as any other DNS record using DNSSEC.

DNS内では、null MX RRは通常のMXレコードであり、新しいセキュリティ問題はありません。必要に応じて、DNSSECを使用して他のDNSレコードと同じ方法で保護できます。

6. IANA Considerations

6. IANAに関する考慮事項

IANA has added the following entries to the "Enumerated Status Codes" subregistry of the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry".

IANAは、「Simple Mail Transfer Protocol（SMTP）Enhanced Status Codes Registry」の「Enumerated Status Codes」サブレジストリに次のエントリを追加しました。

Code: X.1.10 Sample Text: Recipient address has null MX Associated basic status code: 556 Description: This status code is returned when the associated address is marked as invalid using a null MX. Reference: This document Submitter: Authors of this document Change controller: IESG

コード：X.1.10サンプルテキスト：受信者のアドレスにnullのMXが関連付けられています基本的なステータスコード：556説明：このステータスコードは、関連付けられたアドレスがnullのMXを使用して無効としてマークされている場合に返されます。参照：このドキュメント投稿者：このドキュメントの作成者変更管理者：IESG

Code: X.7.27 Sample Text: Sender address has null MX Associated basic status code: 550 Description: This status code is returned when the associated sender address has a null MX, and the SMTP receiver is configured to reject mail from such sender (e.g., because it could not return a DSN). Reference: This document Submitter: Authors of this document Change controller: IESG

コード：X.7.27サンプルテキスト：送信者アドレスにnullのMXが関連付けられています基本的なステータスコード：550説明：このステータスコードは、関連付けられた送信者アドレスにnullのMXがあり、SMTP受信者がそのような送信者からのメールを拒否するように構成されている場合に返されます（例：、DSNを返すことができなかったため）。参照：このドキュメント投稿者：このドキュメントの作成者変更管理者：IESG

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.

[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。

[RFC2119] 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>.

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

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

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

[RFC7504] Klensin, J., "SMTP 521 and 556 Reply Codes", RFC 7504, DOI 10.17487/RFC7504, June 2015, <http://www.rfc-editor.org/info/rfc7504>.

[RFC7504] Klensin、J。、「SMTP 521 and 556 Reply Codes」、RFC 7504、DOI 10.17487 / RFC7504、2015年6月、<http://www.rfc-editor.org/info/rfc7504>。

7.2. Informative References

7.2. 参考引用

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.

[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、DOI 10.17487 / RFC2782、2000年2月、<http：// www.rfc-editor.org/info/rfc2782>。

[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>.

[RFC5598] Crocker、D。、「インターネットメールアーキテクチャ」、RFC 5598、DOI 10.17487 / RFC5598、2009年7月、<http://www.rfc-editor.org/info/rfc5598>。

[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <http://www.rfc-editor.org/info/rfc7208>.

[RFC7208]キッターマンS.、「電子メールでのドメインの使用を承認するための送信者ポリシーフレームワーク（SPF）、バージョン1」、RFC 7208、DOI 10.17487 / RFC7208、2014年4月、<http://www.rfc-editor.org / info / rfc7208>。

Acknowledgements

謝辞

We thank Dave Crocker for his diligent and lengthy shepherding of this document, and members of the APPSAWG working group for their constructive suggestions.

このドキュメントの勤勉で長いシェファーディングを提供してくれたDave Crockerと、建設的な提案をしてくれたAPPSAWGワーキンググループのメンバーに感謝します。

Authors' Addresses

著者のアドレス

John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886 United States

John Levine Taughannock Networks私書箱727 Trumansburg、NY 14886アメリカ合衆国

   Phone: +1 831 480 2300
   Email: standards@taugh.com
   URI:   http://jl.ly

Mark Delany Apple Inc. 1 Infinite Loop Cupertino, CA 95014 United States

Mark Delany Apple Inc. 1 Infinite Loop Cupertino、CA 95014アメリカ合衆国

   Email: mx0dot@yahoo.com