[要約] RFC 9091は、公開サフィックスドメイン用のDMARC拡張に関する実験的な提案であり、ドメインベースのメッセージ認証、報告、および適合性を強化することを目的としています。この拡張は、メール送信者の認証を改善し、フィッシングやスパムを減少させるために利用されます。
Internet Engineering Task Force (IETF) S. Kitterman
Request for Comments: 9091 fTLD Registry Services
Category: Experimental T. Wicinski, Ed.
ISSN: 2070-1721 July 2021
Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains
パブリックサフィックスドメインの実験的なドメインベースのメッセージ認証、報告、および適合（DMARC）拡張
Abstract
概要
Domain-based Message Authentication, Reporting, and Conformance (DMARC), defined in RFC 7489, permits a domain-controlling organization to express domain-level policies and preferences for message validation, disposition, and reporting, which a mail-receiving organization can use to improve mail handling.
RFC 7489で定義されているドメインベースのメッセージ認証、報告、および適合性（DMARC）は、ドメイン制御組織がメッセージ検証、処分、および報告のためのドメインレベルのポリシーと設定を表現し、メール受信組織が使用できるようにすることができます。メール処理を改善するため。
DMARC distinguishes the portion of a name that is a Public Suffix Domain (PSD), below which Organizational Domain names are created. The basic DMARC capability allows Organizational Domains to specify policies that apply to their subdomains, but it does not give that capability to PSDs. This document describes an extension to DMARC to fully enable DMARC functionality for PSDs.
DMARCは、Publicサフィックスドメイン（PSD）である名前の部分を区別し、その下に組織ドメイン名が作成されます。基本的なDMARC機能により、組織ドメインはそれらのサブドメインに適用されるポリシーを指定することを可能にしますが、PSDへのその機能を与えません。このドキュメントでは、PSDのDMARC機能を完全に有効にするためのDMARCへの拡張機能について説明します。
Some implementations of DMARC consider a PSD to be ineligible for DMARC enforcement. This specification addresses that case.
DMARCの実装によっては、DMARC執行の対象となるためのPSDを検討してください。この規格はその場合に対応しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
この文書はインターネット標準のトラック仕様ではありません。検査、実験的実施、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットコミュニティの実験的プロトコルを定義しています。この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9091.
この文書の現在のステータス、任意のエラータ、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9091で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Example
1.2. Discussion
2. Terminology and Definitions
2.1. Conventions Used in This Document
2.2. Public Suffix Domain (PSD)
2.3. Organizational Domain
2.4. Longest PSD
2.5. Public Suffix Operator (PSO)
2.6. PSO-Controlled Domain Names
2.7. Non-existent Domains
3. PSD DMARC Updates to DMARC Requirements
3.1. General Updates
3.2. Changes in Section 6.3 ("General Record Format")
3.3. Changes in Section 6.4 ("Formal Definition")
3.4. Changes in Section 6.5 ("Domain Owner Actions")
3.5. Changes in Section 6.6.1 ("Extract Author Domain")
3.6. Changes in Section 6.6.3 ("Policy Discovery")
3.7. Changes in Section 7 ("DMARC Feedback")
4. Privacy Considerations
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. PSD DMARC Privacy Concern Mitigation Experiment
Appendix B. DMARC PSD Registry Examples
B.1. DMARC PSD DNS Query Service
B.2. DMARC PSD Registry
B.3. DMARC PSD PSL Extension
Appendix C. Implementations
C.1. Authheaders Module
C.2. Zdkimfilter Module
Acknowledgements
Authors' Addresses
DMARC [RFC7489] provides a mechanism for publishing organizational policy information to email receivers. DMARC allows policy to be specified for both individual domains and for Organizational Domains and their subdomains within a single organization.
DMARC [RFC7489]は、組織ポリシー情報を電子メール受信機に公開するためのメカニズムを提供します。DMARCは、個々のドメインと組織のドメインと単一の組織内のサブドメインの両方にポリシーを指定できます。
To determine the Organizational Domain for a message under evaluation, and thus where to look for a policy statement, DMARC makes use of a public suffix list. The process for doing this can be found in Section 3.2 of the DMARC specification [RFC7489]. Currently, the most common public suffix list being used is the one maintained by the Mozilla Foundation and made public at <https://publicsuffix.org>.
評価中のメッセージの組織ドメインを決定するために、したがってPolicyステートメントを探すために、DMARCはパブリックサフィックスリストを使用します。これを行うためのプロセスはDMARC仕様[RFC7489]のセクション3.2にあります。現在、使用されている最も一般的なパブリックサフィックスリストは、Mozilla Foundationによって維持され、<https://publicsuffix.org>で公開されています。
In the basic DMARC model, Public Suffix Domains (PSDs) are not Organizational Domains and are thus not subject to DMARC processing. In DMARC, domains fall into one of three categories: Organizational Domains, subdomains of Organizational Domains, or PSDs. A PSD can only publish DMARC policy for itself and not for any subdomains under it. In some cases, this limitation allows for the abuse of non-existent organizational-level domains and hampers identification of domain abuse in email.
基本的なDMARCモデルでは、パブリックサフィックスドメイン（PSD）は組織ドメインではなく、したがってDMARC処理の対象となりません。DMARCでは、ドメインは、組織ドメイン、組織ドメインのサブドメイン、またはPSDSの3つのカテゴリのうちの1つに分類されます。PSDは、その下のサブドメインに対してはDMARCポリシーを公開することしかできません。場合によっては、この制限により、存在しない組織レベルドメインの乱用と電子メールでのドメイン乱用の識別が可能になります。
This document specifies experimental updates to the DMARC specification [RFC7489] in an attempt to mitigate this abuse.
このドキュメントは、この乱用を軽減しようとしたDMARC仕様[RFC7489]への実験的更新を指定します。
As an example, imagine a Top-Level Domain (TLD), ".example", that has public subdomains for government and commercial use (".gov.example" and ".com.example"). The maintainer of a list of such a PSD structure would include entries for both of these subdomains, thereby indicating that they are PSDs, below which Organizational Domains can be registered. Suppose further that there exists a legitimate domain called "tax.gov.example", registered within ".gov.example".
一例として、政府および商業用の公開サブドメイン（「.gov.example」および「.com.example」）を持つ最上位ドメイン（TLD）、「.example」を想像してみてください。そのようなPSD構造のリストのメンテナは、これらのサブドメインの両方に対するエントリを含み、それによってそれらがPSDであることを示し、その下では組織ドメインを登録することができる。「.gov.example」に登録されている「tax.gov.example」と呼ばれる正当なドメインが存在するとします。
By exploiting the typically unauthenticated nature of email, there are regular malicious campaigns to impersonate this organization that use similar-looking ("cousin") domains such as "t4x.gov.example". Such domains are not registered.
電子メールの認証されていない性質を悪用することで、「t4x.gov.example」などの同様の（ "COUSIN"）ドメインを使用するこの組織を偽装するための通常の悪意のあるキャンペーンがあります。そのようなドメインは登録されていません。
Within the ".gov.example" public suffix, use of DMARC has been mandated, so "gov.example" publishes the following DMARC DNS record:
「.gov.example」パブリックサフィックスの内容では、DMARCの使用が義務付けられているため、 "gov.example"は次のDMARC DNSレコードを発行しています。
_dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject;"
"rua=mailto:dmc@dmarc.svc.gov.example" )
This DMARC record provides policy and a reporting destination for mail sent from @gov.example. Similarly, "tax.gov.example" will have a DMARC record that specifies policy for mail sent from addresses @tax.gov.example. However, due to DMARC's current method of discovering and applying policy at the Organizational Domain level, the non-existent Organizational Domain of @t4x.gov.example does not and cannot fall under a DMARC policy.
このDMARCレコードは、@ gov.exampleから送信されたメールのためのポリシーとレポート先を提供します。同様に、 "tax.gov.example"はaddresses @ tax.gov.exampleから送信されたメールのポリシーを指定するDMARCレコードを持ちます。ただし、DMARCの現在のポリシーの発見と適用方式の組織ドメインレベルでは、存在しない組織ドメインは、DMARCポリシーの下ではなく、存在しません。
Defensively registering all variants of "tax" is not a scalable strategy. The intent of this specification, therefore, is to enhance the DMARC discovery method by enabling an agent receiving such a message to be able to determine that a relevant policy is present at "gov.example", which is precluded by the current DMARC specification.
「税」のすべての変形を防御的に登録することは、スケーラブルな戦略ではありません。したがって、本明細書の意図は、このようなメッセージを受信しているエージェントが、現在のDMARC仕様によって排除されている「Gov.example」に存在すると判断することができるエージェントを決定することを可能にすることでDMARC発見方法を強化することである。
This document provides a simple extension to [RFC7489] to allow operators of Public Suffix Domains (PSDs) to:
このドキュメントでは、[RFC7489]に簡単な拡張機能を提供して、パブリックサフィックスドメイン（PSD）の演算子を使用できるようにします。
* Express policy at the level of the PSD that covers all Organizational Domains that do not explicitly publish DMARC records
* DMARCレコードを明示的に公開しないすべての組織ドメインをカバーするPSDのレベルでポリシーを表現する
* Extend the DMARC policy query functionality to detect and process such a policy
* このようなポリシーを検出して処理するために、DMARCポリシークエリ機能を拡張します。
* Describe receiver feedback for such policies
* そのようなポリシーの受信機のフィードバックを説明してください
* Provide controls to mitigate potential privacy considerations associated with this extension
* この拡張に関連した潜在的なプライバシーに関する考慮事項を軽減するためのコントロールを提供する
This document also provides a new DMARC tag to indicate requested handling policy for non-existent subdomains. This is provided specifically to support phased deployment of PSD DMARC but is expected to be useful more generally. Undesired rejection risks for mail purporting to be from domains that do not exist are substantially lower than for those that do, so the operational risk of requesting harsh policy treatment (e.g., reject) is lower.
このドキュメントでは、存在しないサブドメインに対して要求された処理ポリシーを示すための新しいDMARCタグも提供します。これはPSD DMARCのフェーズドアップ展開をサポートするために特に提供されていますが、一般的に有用であると予想されます。存在しないドメインから存在しない納付の望まれない拒絶リスクは、それが行うものよりも実質的に低いので、過酷な政策治療を要求する操作上のリスク（拒否）はより低い。
As an additional benefit, the PSD DMARC extension clarifies existing requirements. Based on the requirements of [RFC7489], DMARC should function above the organizational level for exact domain matches (i.e., if a DMARC record were published for "example", then mail from example@example should be subject to DMARC processing). Testing has revealed that this is not consistently applied in different implementations.
追加の利点として、PSD DMARCエクステンションは既存の要件を明確にします。[RFC7489]の要件に基づいて、DMARCは正確なドメインの一致のための組織レベルを上回るべきである（すなわち、DMARCレコードが「例」の場合はDMARCレコードが公開されている場合、例@の例からのメールはDMARC処理の対象とする）。テストは、これが異なる実装で一貫して適用されていないことを明らかにしました。
There are two types of Public Suffix Operators (PSOs) for which this extension would be useful and appropriate:
この拡張機能が有用で適切なパブリックサフィックス事業者（PSOS）には、2種類あります。
Branded PSDs (e.g., ".google"): These domains are effectively Organizational Domains as discussed in [RFC7489]. They control all subdomains of the tree. These are effectively private domains but listed in the current public suffix list. They are treated as public for DMARC purposes. They require the same protections as DMARC Organizational Domains but are currently unable to benefit from DMARC.
ブランドのPSD（例えば、「.Google」）：これらのドメインは[RFC7489]で説明したように効果的に組織的なドメインです。彼らは木のすべてのサブドメインを制御します。これらは事実上プライベートドメインですが、現在のパブリックサフィックスリストにリストされています。それらはDMARCの目的のために公開されています。それらはDMARC組織ドメインと同じ保護を必要としますが、現在DMARCから恩恵を受けていません。
Multi-organization PSDs that require DMARC usage (e.g., ".bank"): Because existing Organizational Domains using this PSD have their own DMARC policy, the applicability of this extension is for non-existent domains. The extension allows the brand protection benefits of DMARC to extend to the entire PSD, including cousin domains of registered organizations.
DMARCの使用を必要とするマルチ組織PSD（例えば、「.bank」）：このPSDを使用する既存の組織ドメインには独自のDMARCポリシーがあるため、この拡張の適用性は存在しないドメイン用です。拡張機能により、DMARCのブランド保護の利点は、登録機関のいとこドメインを含むPSD全体に拡大することができます。
Due to the design of DMARC and the nature of the Internet email architecture [RFC5598], there are interoperability issues associated with DMARC deployment. These are discussed in "Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows" [RFC7960]. These issues are not typically applicable to PSDs since they (e.g., the ".gov.example" used above) do not typically send mail.
DMARCの設計とインターネット電子メールアーキテクチャの性質[RFC5598]の設計により、DMARC展開に関連した相互運用性の問題があります。これらは、「ドメインベースのメッセージ認証、報告、報告、および適合性（DMARC）および間接的な電子フローの間の相互運用性の問題」で説明しています[RFC7960]。これらの問題は通常PSDSには適用されません（例えば、上で使用されている ".gov.example）は通常メールを送信しません。
This section defines terms used in the rest of the document.
このセクションでは、残りの文書で使用されている用語を定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The global Internet Domain Name System (DNS) is documented in numerous RFCs. It defines a tree of names starting with root, ".", immediately below which are Top-Level Domain names such as ".com" and ".us". The domain name structure consists of a tree of names, each of which is made of a sequence of words ("labels") separated by period characters. The root of the tree is simply called ".". The Internet community at large, through processes and policies external to this work, selects points in this tree at which to register domain names "owned" by independent organizations. Real-world examples are ".com", ".org", ".us", and ".gov.uk". Names at which such registrations occur are called "Public Suffix Domains (PSDs)", and a registration consists of a label selected by the registrant to which a desirable PSD is appended. For example, "ietf.org" is a registered domain name, and ".org" is its PSD.
グローバルインターネットドメインネームシステム（DNS）は、多数のRFCに文書化されています。これは、ルート、 "。"で始まる名前のツリーを定義します。そのすぐ下には、 ".com"や ".us"などの最上位のドメイン名です。ドメイン名構造は、名前のツリーで構成されており、それぞれがピリオド文字で区切られた一連の単語（「ラベル」）で構成されています。ツリーのルートは単に ""と呼ばれます。インターネットコミュニティは、この作業の外部にあるプロセスとポリシーを介して、このツリー内のポイントを独立した組織で「所有」に登録するポイントを選択します。実世界の例は「.com」、「.org」、「.us」、および「.gov.uk」です。そのような登録が行われる名前は、「パブリックサフィックスドメイン（PSDS）」と呼ばれ、登録は望ましいPSDが追加されている登録者によって選択されたラベルで構成されています。たとえば、 "ietf.org"は登録ドメイン名であり、 ".org"はそのPSDです。
The term "Organizational Domain" is defined in Section 3.2 of [RFC7489].
「組織ドメイン」という用語は[RFC7489]のセクション3.2で定義されています。
The longest PSD is the Organizational Domain with one label removed. It names the immediate parent node of the Organizational Domain in the DNS namespace tree.
最長PSDは、1つのラベルが削除された組織ドメインです。DNSネームスペースツリーの組織ドメインの即時の親ノードに名前を付けます。
A Public Suffix Operator is an organization that manages operations within a PSD, particularly the DNS records published for names at and under that domain name.
パブリックサフィックス演算子は、PSD内の操作、特にそのドメイン名の下およびその下の名前で公開されているDNSレコードを管理する組織です。
PSO-Controlled Domain Names are names in the DNS that are managed by a PSO and are not available for use as Organizational Domains. PSO-Controlled Domain Names may have one (e.g., ".com") or more (e.g., ".co.uk") name components, depending on PSD policy.
PSO制御ドメイン名は、PSOによって管理されているDNS内の名前であり、組織ドメインとして使用できません。PSO制御ドメイン名は、PSDポリシーに応じて、1つ（例えば、「.com」）またはそれ以上の（例えば、「.co.uk」）という名前の構成要素を有することができる。
For DMARC purposes, a non-existent domain is a domain for which there is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This is a broader definition than that in [RFC8020].
DMARCの目的のために、存在しないドメインは、AAAA、およびMXレコードに対してNXDOMAINまたはNODATA応答があるドメインです。これは[RFC8020]よりも広い定義です。
To participate in this experiment, implementations should interpret [RFC7489] as described in the following subsections.
この実験に参加するには、以下のサブセクションで説明されているように、実装は[RFC7489]を解釈する必要があります。
References to "Domain Owners" also apply to PSOs.
「ドメイン所有者」への参照もPSOSに適用されます。
The following paragraph is added to this section. A new tag is added after "fo":
このセクションには次の段落が追加されています。「fo」の後に新しいタグが追加されました。
| np: Requested Mail Receiver policy for non-existent subdomains
| (plain-text; OPTIONAL). Indicates the policy to be enacted by
| the Receiver at the request of the Domain Owner. It applies
| only to non-existent subdomains of the domain queried and not
| to either existing subdomains or the domain itself. Its syntax
| is identical to that of the "p" tag defined below. If the "np"
| tag is absent, the policy specified by the "sp" tag (if the
| "sp" tag is present) or the policy specified by the "p" tag (if
| the "sp" tag is absent) MUST be applied for non-existent
| subdomains. Note that "np" will be ignored for DMARC records
| published on subdomains of Organizational Domains and PSDs due
| to the effect of the DMARC policy discovery mechanism described
| in Section 6.6.3 of [RFC7489].
The following tag definitions from DMARC are updated:
DMARCからの次のタグ定義が更新されます。
p: The sentence 'Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" tag' is updated to read 'Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" or "np" tags.'
P：文のポリシーは、「SP」のポリシーを使用してサブドメインポリシーが明示的に説明されていない限り、ドメインの照会およびサブドメインに適用され、サブドメインポリシーが明示的に説明されていない限り、サブドメインのポリシーがドメインに適用され、サブドメインに適用されます。「SP」または「NP」のタグ。
sp: The sentence 'If absent, the policy specified by the "p" tag MUST be applied for subdomains' is updated to read 'If both the "sp" tag is absent and the "np" tag is either absent or not applicable, the policy specified by the "p" tag MUST be applied for subdomains.'
sp：文が存在しない場合は、「P」タグで指定されたポリシーをサブドメインに適用する必要があります。「sp」タグの両方が存在しない場合は「読み取り」が更新され、「NP」タグが存在しないか適用されない場合"p"タグで指定されたポリシーはサブドメインに適用されなければなりません。
The ABNF [RFC5234] for DMARC is updated to include a new definition, "dmarc-nprequest":
DMARCのABNF [RFC5234]は、新しい定義「DMARC-NPRequest」を含むように更新されます。
dmarc-nprequest = "np" *WSP "=" *WSP
( "none" / "quarantine" / "reject" )
The "dmarc-record" definition is also updated to include the following:
"dmarc-record"定義も次のものを含めるように更新されます。
dmarc-record = dmarc-version dmarc-sep
[dmarc-request]
[dmarc-sep dmarc-srequest]
[dmarc-sep dmarc-auri]
[dmarc-sep dmarc-furi]
[dmarc-sep dmarc-adkim]
[dmarc-sep dmarc-aspf]
[dmarc-sep dmarc-ainterval]
[dmarc-sep dmarc-fo]
[dmarc-sep dmarc-rfmt]
[dmarc-sep dmarc-percent]
[dmarc-sep]
[dmarc-sep dmarc-nprequest]
; components other than dmarc-version and
; dmarc-request may appear in any order
In addition to the DMARC Domain Owner actions, PSOs that require use of DMARC and participate in PSD DMARC ought to make that information available to receivers. This document is an experimental mechanism for doing so; see the description in Appendix B.
DMARCドメインの所有者の行動に加えて、DMARCの使用を必要とし、PSD DMARCに参加するPSOSは、その情報を受信者に利用できるようにするために選択されます。この文書はそうするための実験的なメカニズムです。付録Bの説明を参照してください。
Experience with DMARC has shown that some implementations short-circuit messages, bypassing DMARC policy application, when the domain name extracted by the receiver (from the RFC5322.From domain) is on the public suffix list used by the receiver. This negates the capability being created by this specification. Therefore, the following paragraph is appended to Section 6.6.1 of the DMARC specification [RFC7489]:
DMARCの経験は、（RFC5322.fromドメインから）受信者によって抽出されたドメイン名が受信者によって使用されるパブリックサフィックスリストにあるときに、DMARCポリシーアプリケーションを迂回するいくつかの実装の短絡メッセージを示しています。これは、この仕様によって作成されている機能を否定します。したがって、DMARC仕様書の6.6.1項には、次の段落が追加されています[RFC7489]：
| Note that domain names that appear on a public suffix list are not | exempt from DMARC policy application and reporting.
| ..パブリックサフィックスリストに表示されるドメイン名はそうではないことに注意してください。DMARCポリシーアプリケーションとレポートの除外。
A new step is added between steps 3 and 4:
ステップ3と4の間に新しいステップが追加されます。
| 3A. If the set is now empty and the longest PSD ([RFC9091],
| Section 2.4) of the Organizational Domain is one that the
| receiver has determined is acceptable for PSD DMARC (based on
| the data in one of the DMARC PSD Registry Examples described in
| Appendix B of [RFC9091]), the Mail Receiver MUST query the DNS
| for a DMARC TXT record at the DNS domain matching the longest
| PSD in place of the RFC5322.From domain in the message (if
| different). A possibly empty set of records is returned.
As an example, for a message with the Organizational Domain of "example.compute.cloudcompany.com.example", the query for PSD DMARC would use "compute.cloudcompany.com.example" as the longest PSD. The receiver would check to see if that PSD is listed in the DMARC PSD Registry, and if so, perform the policy lookup at "_dmarc.compute.cloudcompany.com.example".
例として、 "example.compute.cloudcompany.com.example"の組織ドメインを持つメッセージの場合、PSD DMARCのクエリは "compute.cloudcompany.com.example"を最も長いPSDとして使用します。受信者は、PSDがDMARC PSDレジストリにリストされているかどうかを確認し、そうであれば、「_dmarc.compute.cloudcompany.com.example」でポリシー検索を実行します。
Note: Because the PSD policy query comes after the Organizational Domain policy query, PSD policy is not used for Organizational Domains that have published a DMARC policy. Specifically, this is not a mechanism to provide feedback addresses (RUA/RUF) when an Organizational Domain has declined to do so.
注：PSDポリシークエリは、組織ドメインポリシークエリの後に、PSDポリシーはDMARCポリシーを公開した組織ドメインには使用されません。具体的には、組織ドメインがそうすることを断ったときにフィードバックアドレス（RUA / RUF）を提供するメカニズムではありません。
The following paragraph is added to this section:
次の段落がこのセクションに追加されます。
| Operational note for PSD DMARC: For PSOs, feedback for non-
| existent domains is desirable and useful, just as it is for org-
| level DMARC operators. See Section 4 of [RFC9091] for discussion
| of privacy considerations for PSD DMARC.
These privacy considerations are developed based on the requirements of [RFC6973]. Additionally, the privacy considerations of [RFC7489] apply to the mechanisms described by this document. To participate in this experiment, implementations should be aware of the privacy considerations described in this section. If this experiment is successful, this section should be incorporated into the "Privacy Considerations" section as "Feedback Leakage".
これらのプライバシーに関する考慮事項は[RFC6973]の要件に基づいて開発されています。さらに、[RFC7489]のプライバシーに関する考慮事項は、この文書によって説明されているメカニズムに適用されます。この実験に参加するには、実装はこのセクションで説明されているプライバシーの考慮事項を認識する必要があります。この実験が成功した場合、このセクションは「フィードバックリーク」として「プライバシーに関する考慮事項」のセクションに組み込む必要があります。
Providing feedback reporting to PSOs can, in some cases, cause information to leak out of an organization to the PSO. This leakage could potentially be utilized as part of a program of pervasive surveillance (see [RFC7624]). There are roughly three cases to consider:
PSOにフィードバック報告を提供することは、場合によっては、情報をPSOに組織から漏洩させることができます。この漏洩は、浸透監視プログラムの一部として潜在的に利用される可能性があります（[RFC7624]参照）。考慮すべき3つのケースがあります。
Single Organization PSDs (e.g., ".google"): RUA and RUF reports based on PSD DMARC have the potential to contain information about emails related to entities managed by the organization. Since both the PSO and the Organizational Domain Owners are common, there is no additional privacy risk for either normal or non-existent domain reporting due to PSD DMARC.
単一組織PSDS（例えば、「.Google」）：PSD DMARCに基づくRUAおよびRUFレポートには、組織によって管理されているエンティティに関するEメールに関する情報が含まれている可能性があります。PSOと組織ドメインの両方の所有者が一般的であるため、PSD DMARCによる通常のドメイン報告または存在しないドメイン報告のどちらかのプライバシーリスクはありません。
Multi-organization PSDs that require DMARC usage (e.g., ".bank"): Reports based on PSD DMARC will only be generated for domains that do not publish a DMARC policy at the organizational or host level. For domains that do publish the required DMARC policy records, the feedback reporting addresses (RUA and RUF) of the organization (or hosts) will be used. The only direct risk of feedback leakage for these PSDs are for Organizational Domains that are out of compliance with PSD policy. Data on non-existent cousin domains would be sent to the PSO.
DMARCの使用を必要とするマルチ組織PSD（例えば、「.bank」）：PSD DMARCに基づくレポートは、組織またはホストレベルでDMARCポリシーを公開しないドメインに対してのみ生成されます。必要なDMARCポリシーレコードを公開するドメインの場合、組織（またはホスト）のフィードバック報告アドレス（RUAとRUF）が使用されます。これらのPSDのフィードバック漏洩の唯一の直接リスクは、PSDポリシーに準拠していない組織ドメイン用です。存在しないいわゆるいとこドメインに関するデータがPSOに送信されます。
Multi-organization PSDs (e.g., ".com") that do not mandate DMARC usage: Privacy risks for Organizational Domains that have not deployed DMARC within such PSDs are significant. For non-DMARC Organizational Domains, all DMARC feedback will be directed to the PSO. PSD DMARC is opt out (by publishing a DMARC record at the Organizational Domain level) instead of opt in, which would be the more desirable characteristic. This means that any non-DMARC Organizational Domain would have its Feedback Reports redirected to the PSO. The content of such reports, particularly for existing domains, is privacy sensitive.
DMARCの使用法を義務付けないマルチ組織PSD（例えば、「.com」）：そのようなPSD内でDMARCを展開していない組織ドメインのプライバシーリスクは重要です。非DMARCの組織ドメインの場合、すべてのDMARCフィードバックはPSOに向けられます。PSD DMARCは（Opt Inの代わりにDMARCレコードを公開することによって）オプトアウトします。これは、より望ましい特性です。これは、DMARC以外の組織ドメインでは、フィードバックレポートがPSOにリダイレクトされていることを意味します。そのような報告の内容、特に既存のドメインのための、プライバシーに敏感です。
PSOs will receive feedback on non-existent domains, which may be similar to existing Organizational Domains. Feedback related to such cousin domains have a small risk of carrying information related to an actual Organizational Domain. To minimize this potential concern, PSD DMARC feedback MUST be limited to Aggregate Reports. Feedback Reports carry more detailed information and present a greater risk.
PSOSは存在しないドメインに関するフィードバックを受け取ります。これは既存の組織ドメインに似ている可能性があります。このようないとこドメインに関連するフィードバックは、実際の組織ドメインに関連する情報を伝える危険性が小さい。この潜在的な問題を最小限に抑えるために、PSD DMARCフィードバックは集約レポートに制限されなければなりません。フィードバックレポートはより詳細な情報を運び、より大きなリスクを提示します。
Due to the inherent privacy and security risks associated with PSD DMARC for Organizational Domains in multi-organization PSDs that do not participate in DMARC, any feedback reporting related to multi-organizational PSDs MUST be limited to non-existent domains except in cases where the reporter knows that PSO requires use of DMARC (by checking the DMARC PSD Registry).
DMARCに参加していないマルチ組織PSDの組織ドメインのPSD DMARCに関連する固有のプライバシーおよびセキュリティリスクのために、DMARCに参加しないフィードバック報告は、レポーターが存在しない場合を除き、存在しないドメインに限定されている必要があります。PSOがDMARCの使用を必要とすることを知っている（DMARC PSDレジストリをチェックすることによって）。
This document does not change the security considerations of [RFC7489] and [RFC7960].
この文書では、[RFC7489]と[RFC7960]のセキュリティ上の考慮事項は変更されません。
The risks of the issues identified in Section 12.3 of [RFC7489] ("DNS Security") are amplified by PSD DMARC. In particular, consequences of DNS cache poisoning (or name chaining) are increased because a successful attack would potentially have a much wider scope (see [RFC3833] for details).
[RFC7489]のセクション12.3（ "DNSセキュリティ"）で識別された問題のリスクは、PSD DMARCによって増幅されます。特に、攻撃に成功した攻撃により、DNSキャッシュ中毒（または名前連鎖）の結果が増加します（詳細については[RFC3833]を参照）。
The risks of the issues identified in Section 12.5 of [RFC7489] ("External Reporting Addresses") are amplified by PSD DMARC. By design, PSD DMARC causes unrequested reporting of feedback to entities external to the Organizational Domain. This is discussed in more detail in Section 4.
[RFC7489]のセクション12.5（「外部報告アドレス」）で特定されている問題のリスクは、PSD DMARCによって増幅されます。設計により、PSD DMARCは組織ドメインの外部のエンティティへのフィードバックの不明確な報告を引き起こします。これについては、セクション4でより詳細に説明されています。
IANA has added a new tag to the "DMARC Tag Registry" in the "Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters" registry. The "Status" column is defined in Section 11.4 of [RFC7489].
IANAは、「ドメインベースのメッセージ認証、報告、および適合性（DMARC）パラメータ」レジストリの「DMARCタグレジストリ」に新しいタグを追加しました。「ステータス」列は[RFC7489]のセクション11.4で定義されています。
The new entry is as follows:
新しいエントリは次のとおりです。
+==========+===========+=========+=============================+
| Tag Name | Reference | Status | Description |
+==========+===========+=========+=============================+
| np | RFC 9091 | current | Requested handling policy |
| | | | for non-existent subdomains |
+----------+-----------+---------+-----------------------------+
Table 1
表1
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.
[RFC7489] Kucherawy、M.、ED。E. Zwicky、ED。、「ドメインベースのメッセージ認証、報告、報告、および適合（DMARC）」、RFC 7489、DOI 10.17487 / RFC7489、2015年3月、<https：//www.rfc-editor.org/info/RFC7489>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[PSD-DMARC] "Public Suffix Domain DMARC", <https://psddmarc.org/>.
[PSD-DMARC] "Publicサフィックスドメインdmarc"、<https://psddmarc.org/>。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August 2004, <https://www.rfc-editor.org/info/rfc3833>.
[RFC3833] Atkins、D.およびR.Austein、「ドメインネームシステムの脅威分析（DNS）」、RFC 3833、DOI 10.17487 / RFC3833、2004年8月、<https：//www.rfc-editor.org/info/ RFC3833>。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <https://www.rfc-editor.org/info/rfc5598>.
[RFC5598] Crocker、D.、「インターネットメールアーキテクチャ」、RFC 5598、DOI 10.17487 / RFC 5598、2009年7月、<https：//www.rfc-editor.org/info/rfc5598>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973]クーパー、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M.、R. Smith、「インターネットプロトコルのプライバシーに関する考察」、RFC 6973、DOI2017487 / RFC6973、2013年7月、<https：//www.rfc-editor.org/info/rfc6973>。
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, <https://www.rfc-editor.org/info/rfc7624>.
[RFC7624] Barnes、R.、Schneier、B、Jennings、C.、Hardie、T.、Trammell、B.、Huitema、C.、D.Borkmann、「浸透監視の顔の機密性：脅威モデル2015年8月、<https：//www.rfc-editor.org/info/rfc7624>。
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen, T., Ed., Zwicky, E., Ed., and K. Andersen, Ed., "Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows", RFC 7960, DOI 10.17487/RFC7960, September 2016, <https://www.rfc-editor.org/info/rfc7960>.
[RFC7960] Martin、F.、Ed。、Lear、E.、Ed。、Draegen、T.、Ed。、Zwicky、E.、Ed。、およびK.Andersen、「ドメインベースの間の相互運用性の問題」。メッセージ認証、報告、適合性（DMARC）および適合性（DMARC）および間接的な電子メールフロー、RFC 7960、DOI 10.17487 / RFC7960、2016年9月、<https：//www.rfc-editor.org/info/rfc7960>。
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, November 2016, <https://www.rfc-editor.org/info/rfc8020>.
[RFC8020] Bortzmeyer、S.およびS.Huque、 "NXDomain：本当にありません"、RFC 8020、DOI 10.17487 / RFC8020、2017年11月、<https://www.rfc-editor.org/info/rfc8020>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
The experiment being performed has three different questions that are looking to be addressed in this document.
実行されている実験には、この文書で対処されようとしている3つの異なる質問があります。
* Section 3.2 modifies policy discovery to add an additional DNS lookup. To determine if this lookup is useful, PSDs will add additional DMARC records in place and will analyze the DMARC reports. Success will be determined if a consensus of PSDs that publish DMARC records are able to collect useful data.
* セクション3.2は、Policy Discoveryを変更して追加のDNSルックアップを追加します。このルックアップが役立つかどうかを判断するには、PSDは追加のDMARCレコードを追加してDMARCレポートを分析します。DMARCレコードを公開するPSDのコンセンサスが有用なデータを収集できるかどうかを成功させる。
* Section 3.2 adds the "np" tag for non-existent subdomains (DNS NXDOMAIN). PSOs wishing to test this will add this flag to their DMARC record and will analyze DMARC reports for deployment. Success will be determined if organizations find explicitly blocking non-existent subdomains desirable and that doing so provides added value.
* セクション3.2は、存在しないサブドメイン（DNS NXDomain）の「NP」タグを追加します。これをテストしたいPSOSは、このフラグをDMARCレコードに追加し、展開のためにDMARCレポートを分析します。組織が明示的に存在しないサブドメインを明示的にブロックすることが望ましいか、そのようにして追加値を提供する組織が決定されます。
* Section 4 discusses three cases where providing feedback could cause information to leak out of an organization. This experiment will analyze the Feedback Reports generated for each case to determine if there is information leakage.
* セクション4では、フィードバックを提供することができる3つのケースが、組織から情報を漏らす可能性があります。この実験では、情報漏洩があるかどうかを判断するために、各場合について生成されたフィードバックレポートを分析します。
To facilitate experimentation around mitigation of data leakage, samples of the DNS-based and IANA-like registries are available at [PSD-DMARC].
データ漏洩の緩和に関する実験を容易にするために、DNSベースおよびIANAのようなレジストリのサンプルは[PSD-DMARC]で入手可能です。
A sample stand-alone DNS query service is available at [PSD-DMARC]. It was developed based on the contents suggested for an IANA registry in an earlier draft version of this document. Usage of the service is described at [PSD-DMARC].
サンプルスタンドアロンDNSクエリサービスは[PSD-DMARC]で入手できます。このドキュメントの以前のドラフト版でIANAレジストリを提案した内容に基づいて開発されました。サービスの使用は[PSD-DMARC]で説明されています。
[PSD-DMARC] provides an IANA-like DMARC Public Suffix Domain (PSD) Registry as a stand-alone DNS query service. It follows the contents and structure described below. There is a Comma-Separated Value (CSV) version of the listed PSDs that is suitable for use in build updates for PSD DMARC-capable software.
[PSD-DMARC]は、スタンドアロンDNSクエリサービスとしてIANAのようなDMARCパブリックサフィックスドメイン（PSD）レジストリを提供します。以下に説明する内容および構成に従う。PSD DMARC対応ソフトウェアのビルドアップデートでの使用に適したリストされているPSDのコンマ区切り値（CSV）バージョンがあります。
PSDs that are deploying DMARC and are participating in PSD DMARC must register their public suffix domain in this new registry. The requirement has to be documented in a manner that satisfies the terms of Expert Review, per [RFC8126]. The Designated Expert needs to confirm that provided documentation adequately describes PSD policy to require Domain Owners to use DMARC or that all Domain Owners are part of a single organization with the PSO.
DMARCを展開しているPSDとPSD DMARCに参加しているPSDは、この新しいレジストリにそれらのパブリックサフィックスドメインを登録する必要があります。[RFC8126]ごとに、エキスパートレビューの条件を満たす方法で、要件を文書化する必要があります。指定されたエキスパートは、ドメインの所有者がDMARCを使用するようにPSDポリシーを適切に説明することを確認する必要があるか、またはすべてのドメイン所有者がPSOを使用して単一の組織の一部であることを確認する必要があります。
The authoritative registry can be found here: <https://psddmarc.org>
[PSD-DMARC] provides a file formatted like the Public Suffix List (PSL) in order to facilitate identification of PSD DMARC participants. Contents are functionally identical to the IANA-like registry but presented in a different format.
[PSD-DMARC] PSD DMARC参加者の識別を容易にするために、パブリックサフィックスリスト（PSL）のようなフォーマットされたファイルを提供します。内容はIANAのようなレジストリと機能的に同じですが、異なる形式で表示されています。
When using this approach, the input domain of the extension lookup is supposed to be the output domain of the regular PSL lookup, i.e., the Organizational Domain. This alternative data approach is potentially useful since DMARC implementations already need to be able to parse the data format, so it should be easier to implement.
このアプローチを使用する場合、拡張ルックアップの入力ドメインは、通常のPSLルックアップ、すなわち組織ドメインの出力ドメインであると考えられている。この代替データアプローチは、DMARC実装がすでにデータフォーマットを解析できるようにするため、実装が簡単であるため、この代替データアプローチは潜在的に役立ちます。
There are two known implementations of PSD DMARC available for testing.
テストに利用可能なPSD DMARCの2つの既知の実装があります。
The authheaders Python module and command line tool is available for download or installation from Pypi (Python Packaging Index).
AuthHeaders Pythonモジュールとコマンドラインツールは、PYPI（Python Packaging Index）からのダウンロードまたはインストールに利用できます。
It supports both use of the DNS-based query service and download of the CSV registry file from [PSD-DMARC].
DNSベースのクエリサービスの使用とCSVレジストリファイルのダウンロードの両方を[PSD-DMARC]からサポートしています。
The zdkimfilter module is a separately available add-on to Courier-MTA.
zdkimfilterモジュールは、Courier-MTAへの別々に入手可能なアドオンです。
Mostly used for DomainKeys Identified Mail (DKIM) signing, it can be configured to also verify, apply DMARC policies, and send Aggregate Reports. For PSD DMARC, it uses the PSL extension list approach, which is available from [PSD-DMARC].
DomainKeys Inventified Mail（DKIM）署名にはほとんど使用され、DMARCポリシーも検証、適用、および集約レポートを送信するように設定できます。PSD DMARCの場合は、[PSD-DMARC]から入手可能なPSL拡張リストアプローチを使用します。
Acknowledgements
謝辞
Thanks to the following individuals for their contributions (both public and private) to improving this document: Kurt Andersen, Seth Blank, Dave Crocker, Heather Diaz, Tim Draegen, Zeke Hendrickson, Andrew Kennedy, John Levine, Dr. Ian Levy, Craig Schwartz, Alessandro Vesely, and Tim Wicinski.
この文書を改善するために、次の個人のおかげで、この文書を改善するために、Kurt Andersen、Seth Blick、Dave Crocker、Heather Diaz、Tim Draegen、Zeke Hendrickson、Andrew Kennedy、John Levine、Craig Schwartz、Alessandro、Tim Wicinski。
A special mention to Dave Crocker for coming up with the name.
名前を思い付くためのDave Crockerへの特別な言及。
Authors' Addresses
著者の住所
Scott Kitterman fTLD Registry Services Suite 400 600 13th Street, NW Washington, DC 20005 United States of America
Scott Kitterman FTLDレジストリサービススイート400 600 13th Street、NWワシントンDC 20005アメリカ合衆国
Phone: +1 301 325-5475
Email: scott@kitterman.com
Tim Wicinski (editor) Elkins, WV 26241 United States of America
Tim Wicinski（編集）Elkins、WV 26241アメリカ合衆国
Email: tjw.ietf@gmail.com