[要約] RFC 8904は、DNSホワイトリスト（DNSWL）を使用した電子メール認証方法の拡張に関する文書です。このRFCの目的は、信頼できる送信者からのメールを識別し、スパムやフィッシング攻撃を減らすために、DNSを利用した認証メカニズムを提供することにあります。利用場面としては、メールサーバーが受信メールの信頼性を評価する際にDNSWLを参照することが挙げられます。関連するRFCには、SPF（Sender Policy Framework）、DKIM（DomainKeys Identified Mail）、DMARC（Domain-based Message Authentication, Reporting, and Conformance）などがあり、これらはすべて電子メールの認証とセキュリティを強化するために相互に補完的に機能します。
Independent Submission A. Vesely
Request for Comments: 8904 September 2020
Category: Informational
ISSN: 2070-1721
DNS Whitelist (DNSWL) Email Authentication Method Extension
DNSホワイトリスト（DNSWL）Eメール認証方法
Abstract
概要
This document describes an email authentication method compliant with RFC 8601. The method consists of looking up the sender's IP address in a DNS whitelist. This document provides information in case the method is seen in the field, suggests a useful practice, and registers the relevant keywords.
この文書では、RFC 8601に準拠した電子メール認証方法について説明します。この方法は、DNSホワイトリスト内の送信者のIPアドレスを調べることからなる。このドキュメントでは、メソッドがフィールドに表示されている場合には、便利な慣習を提案し、関連キーワードを登録します。
This document does not consider blacklists.
この文書はブラックリストを考慮していません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係にRFCシリーズへの貢献です。RFCエディタは、この文書を裁量で公開することを選択し、実装または展開のためのその値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補者ではありません。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/rfc8904.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8904で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。
Table of Contents
目次
1. Introduction
2. Method Details
3. TXT Record Contents
4. IANA Considerations
4.1. Email Authentication Methods
4.2. Email Authentication Property Type
4.3. Email Authentication Result Names
5. Security Considerations
5.1. Over-Quota Signaling
5.2. Security of DNSSEC Validation
5.3. Inherited Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. Example
Appendix B. Known Implementation
Appendix C. Future Possibilities of the 'dns' ptype
Author's Address
One of the many checks that mail servers carry out is to query DNS whitelists (DNSWLs). That method is fully discussed in [RFC5782]. The DNS [RFC1034] lookup is based on the connecting client's IP address, IPv4 or IPv6, and returns zero or more A records. The latter are IPv4 IP addresses in the range 127.0.0.0/8. Depending on the query, TXT records with varying content can also be retrieved. Query examples are given in Appendix A.
メールサーバーが実行する多くのチェックは、DNSホワイトリスト（DNSWL）を照会することです。その方法は[RFC5782]で完全に説明されています。DNS [RFC1034]ルックアップは、接続クライアントのIPアドレス、IPv4またはIPv6に基づいており、0個以上のレコードを返します。後者は、127.0.0.0 / 8の範囲のIPv4 IPアドレスです。クエリによっては、さまざまなコンテンツを持つTXTレコードも取得できます。クエリ例は付録Aに記載されています。
Since the IP address is known as soon as the connection is accepted, this check can occur very early in an SMTP transaction. Its result can be used to counterweight policies that typically occur at early stages too, such as the Sender Policy Framework (SPF) (the last paragraph of Appendix D.3 of [RFC7208] is also illustrated in Appendix A). In addition, the result of a DNSWL lookup can be used at later stages; for example, a delivery agent can use it to learn the trustworthiness of a mail relay in order to estimate the spamminess of an email message. The latter possibility needs a place to collect query results for downstream use, which is precisely what the Authentication-Results header field aims to provide.
接続が受け入れられるとすぐにIPアドレスが知られているので、このチェックはSMTPトランザクションの早い段階で発生する可能性があります。その結果は、送信者政策の枠組み（SPF）などの段階的な段階でも発生する軽量ポリシーに使用できます（「RFC7208の付録D.3の最後の段落」も付録Aに示されています）。さらに、DNSWLルックアップの結果は後の段階で使用できます。例えば、電子メールメッセージのスパミネティを推定するために、配信エージェントはそれを使用してメールリレーの信頼性を学ぶことができる。後者の可能性は、ダウンストリーム使用のためのクエリ結果を収集する場所を必要とします。これは、認証結果ヘッダーフィールドが提供を目的としているものです。
Results often contain additional data, encoded according to DNSWL-specific criteria. The method described in this document considers only whitelists -- one of the major branches described by [RFC5782]. There are also blacklists/blocklists (DNSBLs) and combined lists. Since they all have the same structure, the abbreviation DNSxL is used to mean any. The core procedures of a Mail Transfer Agent (MTA) tend to be quite general, leaving particular cases to be handled by add-on modules. In the case of combined lists, the boundary MTA (see [RFC5598]), which carries out the check and possibly stores the result, has to be able to discern at least the color of each entry, as that is required to make accept/reject decisions. This document provides for storing the result when the DNSxL record to be reported is a whitelisting one.
結果は、DNSWL固有の基準に従ってエンコードされた追加のデータを含みます。この文書に記載されている方法は、ホワイトリストのみ - [RFC5782]で記述された主要なブランチの1つです。ブラックリスト/ブロックリスト（DNSBL）と組み合わせリストもあります。それらはすべて同じ構造を持ちますので、略語DNSXLは任意の意味です。メールトランスファーエージェント（MTA）の中核的手順は非常に一般的な傾向があり、アドオンモジュールによって処理されるべき特定のケースを残します。組み合わせリストの場合、境界MTA（[RFC5598]参照）がチェックされ、おそらく結果を記憶する場合は、受け入れられないように、少なくとも各エントリの色を識別することができる必要があります。決定を拒否します。このドキュメントは、報告されるDNSXLレコードがホワイトリストリング1であるときに結果を格納することを提供します。
Data conveyed in A and TXT records can be stored as properties of the method. The meaning of such data varies widely at the mercy of the list operator; hence, the queried zone has to be stored as well. Mail site operators who configure their MTAs to query specific DNWSLs marry the policies of those lists, as, in effect, they become tantamount to local policies, albeit outsourced. Downstream agents who know DNSWL-specific encoding and understand the meaning of that data can use it to make delivery or display decisions. For example, a mail filter that detects heuristic evidence of a scam can counterweight such information with the trustworthiness score encoded in the A response so as to protect against false positives. Mail User Agents (MUAs) can display those results or use them to decide how to report abusive messages, if configured to do so.
AおよびTXTレコードで伝達されたデータは、メソッドのプロパティとして格納できます。そのようなデータの意味は、リスト演算子の慈悲に大きく異なります。したがって、照会ゾーンも保存する必要があります。特定のDNWSLを照会するためにMTAを構成するメールサイトの演算子は、それらのリストのポリシーと結婚して、それらは有効なので、彼らは地元のポリシーへのタンターマウントになります。DNSWL固有のエンコーディングを知っているダウンストリームエージェントとそのデータの意味を理解することは、それを使用して配信または表示の決定を下すことができます。例えば、詐欺の発見的証拠を検出するメールフィルタは、誤検知を防止するために、応答で符号化された信頼性スコアを用いてそのような情報を促進することができる。メールユーザーエージェント（MUAS）はそれらの結果を表示するか、それらを使用して虐待的なメッセージを報告する方法を決定することができます。
This document describes a usage of TXT fields consistent with other authentication methods, namely to serve the domain name in the TXT record. That way, a downstream filter could also consider whether the sending agent is aligned with the author domain, with semantics similar to [RFC7489].
このドキュメントでは、他の認証方法と一致するTXTフィールドの使用方法、すなわちTXTレコード内のドメイン名を処理することが記載されています。そのように、ダウンストリームフィルタは、送信エージェントが著者ドメインと整列しているかどうかを検討することもでき、[RFC7489]の意味。
At the time of this writing, this method is implemented by Courier-MTA [Courier-MTA]. An outline of the implementation is given in Appendix B.
この書き込み時には、この方法はCourier-MTA [Courier-MTA]によって実装されています。実装の概要は付録Bに記載されています。
The result of the method states how the query did, up to the interpretation of the returned data.
このメソッドの結果は、クエリの結果を返したデータの解釈にどのようにして行ったのかを示します。
The method has four possible results:
この方法には4つの可能な結果があります。
pass: The query successfully returned applicable records. This result is usually accompanied by one or both of the policy properties described below. Since the list is configured as a DNSWL, agents unable to interpret list-specific properties can still derive a positive value from the fact that the sender is whitelisted.
pass：クエリは該当するレコードを正常に返しました。この結果は通常、以下の政策特性の一方または両方を伴う。リストはDNSWLとして設定されているため、リスト固有のプロパティを解釈できないエージェントは、送信者がホワイトリストされているという事実から正の値を導き出すことができます。
none: The query worked but yielded no A record or returned NXDOMAIN, so the sender is not whitelisted.
NONE：クエリは機能しましたが、レコードや返信NXDomainが返されなかったため、送信者は白人にありません。
temperror: The DNS evaluation could not be completed due to some error that is likely transient in nature, such as a temporary DNS error (e.g., a DNS RCODE of 2, commonly known as SERVFAIL) or other error condition. A later attempt may produce a final result.
気温：一時的なDNSエラー（例えば、2のDNS RCode、一般的にはSERMFAILとして知られている）または他のエラー状態など、ある程度の誤差のためにDNS評価を完了できませんでした。後の試みは最終結果を生み出すかもしれません。
permerror: The DNS evaluation cannot work because test entries don't work (that is, DNSWL is broken) or because queries are over quota (reported by a DNS RCODE of 5, commonly known as REFUSED, or by a DNSWL-specific property (policy.ip, defined below) with the same meaning). A later attempt is unlikely to produce a final result. Human intervention is required.
PermError：テストエントリが機能しない（つまり、DNSWLが壊れている）、またはクエリがOVERであるため、DNS評価は機能できません（つまり、拒否されたと一般にDNSWL固有のプロパティによって報告されます（5のDNS RCodeによって報告されます）。同じ意味で下記のpolicy.ip）。後の試みは最終結果を生み出すことはほとんどありません。人間の介入が必要です。
Note that there is no "fail" result.
「失敗」の結果はありません。
The following ptype.property items define how the data provided by the whitelist lookup can be saved.
次のPType.propertyアイテムは、ホワイトリストルックアップによって提供されたデータを保存できる方法を定義します。
dns.zone: DNSWL query root domain, which defines the meaning of the policy.ip property below. Note that an MTA can use a local mirror with a different name. The name stored here has to be the best available reference for all foreseeable downstream consumers. Setting dns.zone to the global zone makes the result intelligible even if the message is handed outside of the internal network.
DNS.Zone：DNSWLクエリルートドメイン。以下のPolicy.IPプロパティの意味を定義します。MTAは、異なる名前のローカルミラーを使用できます。ここに格納されている名前は、すべての予定下流の消費者にとって最高の参照である必要があります。DNS.Zoneをグローバルゾーンに設定すると、メッセージが内部ネットワークの外部に渡されても、結果がわかりやすくなります。
policy.ip: The bit mask value received in type A response, in dotted quad notation. Multiple entries can be arranged in a quoted, comma-separated list (quotes are necessary because commas are not allowed in a token).
policy.ip：タイプA応答で受信されたビットマスク値は、ドット付きクワッド表記で。複数のエントリを引用符で囲み、コンマ区切りリスト（トークンでは許可されていないため、引用符が必要です）に配置できます。
policy.txt: The TXT record, if any. Multiple records are concatenated in the usual way (explained, for example, in Section 3.3 of [RFC7208]). See Section 3 for the resulting content and query options.
Policy.txt：TXTレコードがあれば。複数のレコードは通常の方法で連結されています（たとえば、[RFC7208]のセクション3.3）。結果のコンテンツとクエリのオプションについては、セクション3を参照してください。
dns.sec: This is a generic property stating whether the relevant data was validated using DNSSEC [RFC4033]. For the present method, the relevant data consists of the reported policy properties above or, if the method result is "none", its nonexistence. This property has three possible values:
dns.sec：これは、DNSSEC [RFC4033]を使用して関連データが検証されたかどうかを示す一般的なプロパティです。本方法では、関連データは上記の報告されたポリシープロパティで構成されています。またはメソッドの結果が "None"の場合、存在しません。このプロパティには3つの値があります。
yes: DNSSEC validation confirms the integrity of data. Section 5.2 considers how that is related to the DNS response.
はい：DNSSECの検証データの整合性を確認します。セクション5.2は、それがDNS応答に関連する方法を考慮します。
no: The data is not signed. See Section 5.2.
いいえ：データは署名されていません。セクション5.2を参照してください。
na: Not applicable. No DNSSEC validation can be performed, possibly because the lookup is run through a different means than a security-aware DNS resolver. This does not necessarily imply less security. In particular, "na" is used if the data was downloaded in bulk and then loaded on a local nameserver, which is the case of an MTA querying a local zone different from the reported dns.zone. DNS errors, including validation errors, can also report "na". This is also the value assumed by default.
NA：該当なし。Lookupがセキュリティ対応DNSリゾルバとは異なる手段を介して実行されるため、DNSSEC検証は実行できません。これは必ずしもセキュリティが少なくて済むわけではありません。特に、データが一括してダウンロードされてからローカルネームサーバにロードされた場合、「NA」は使用され、これは報告されたDNS.Zoneとは異なるローカルゾーンを照会するMTAの場合である。検証エラーを含むDNSエラーも "NA"を報告することもできます。これもデフォルトで想定されている値です。
According to [RFC5782], TXT records describe the reason why IP addresses are listed in a DNSWL. An example of a DNSWL whose TXT records contain the domain name of the organization assignee of the sending IP is given in Appendix B. The domain name would correspond to the DNS domain name used by or within the Administrative Management Domain (ADMD) operating the relevant MTA, sometimes called the "organizational domain". In that case, the authentication provided by this method is equivalent to a DomainKeys Identified Mail (DKIM) signature [RFC6376] or an SPF check host [RFC7208], if the DNSWL is trusted.
[RFC5782]によると、TXTレコードはIPアドレスがDNSWLにリストされている理由を説明しています。TXTレコードが送信IPの組織担当者のドメイン名を含むDNSWLの例は、付録Bに記載されています。ドメイン名は、関連する管理ドメイン（ADMD）で使用されるDNSドメイン名に対応します。MTA、「組織ドメイン」と呼ばれることもあります。その場合、このメソッドによって提供された認証は、DNSWLが信頼されている場合、DomainKys識別されたメール（DKIM）署名[RFC6376]またはSPFチェックホスト[RFC7208]と同じです。
According to a DNSWL's policy, attributing responsibility of an IP address to an organization may require something more than a mere PTR record consistency. If no domain names can be responsibly associated to a given IP address, for example, because the IP address was added without direct involvement of the organization concerned, DNSWLs can use a subdomain of .INVALID [RFC2606] where the leftmost label hints at why an address is whitelisted. For example, if the address 192.0.2.38 was added by the list managers solely based on their knowledge, the corresponding TXT record might be AUTOPROMOTED.INVALID so as to avoid explicitly identifying an entity that didn't opt in.
DNSWLのポリシーによると、組織へのIPアドレスの責任を起こすことは、単なるPTRレコードの一貫性を超えるものを必要とするかもしれません。たとえば、特定のIPアドレスにドメイン名を宣伝できるようにすることができない場合、IPアドレスが関係する組織の直接的な関与なしに追加されたため、DNSWLSは.invalid [RFC2606]のサブドメインを使用できます。住所はホワイトリストです。たとえば、アドレス192.2.38がそれらの知識に基づいてリストマネージャによって追加された場合、対応するTXTレコードは、Opt INを明示的に識別しないように、AutoPromoted.InValidです。
Following the example of Multicast DNS (see the second paragraph of Section 16 of [RFC6762]), names containing non-ASCII characters can be encoded in UTF-8 [RFC3629] using the Normalization Form C [NFC], as described in "Unicode Format for Network Interchange" [RFC5198]. Inclusion of unaltered UTF-8 TXT values in the header entails an environment compatible with Email Address Internationalization (EAI) [RFC6530].
マルチキャストDNSの例に続いて（[RFC6762]のセクション16の第2段落を参照）、「Unicode」のように、正規化フォームC [NFC]を使用して、ASCII以外の文字を含む名前をUTF-8 [RFC3629]でエンコードできます。ネットワークインターチェンジのフォーマット[RFC5198]。ヘッダー内の変更されていないUTF-8 TXT値を含めることは、電子メールアドレス国際化（EAI）[RFC6530]と互換性のある環境を伴う。
DNS queries with a QTYPE of ANY may lead to inconsistent replies, depending on the cache status. In addition, ANY is not "all", and the provisions for queries that have QTYPE=ANY [RFC8482] don't cover DNSxLs. A mail server can issue two simultaneous queries, A and TXT. Otherwise, a downstream filter can issue a TXT query on its own, if it knows that an A query was successful and that the DNSWL serves useful TXT records. It is unlikely that TXT records exist if a query for QTYPE A brought a result of "none".
QTypeを使用したDNSクエリは、キャッシュのステータスによっては、矛盾した応答が発生する可能性があります。さらに、いずれも「all」ではなく、qtype = any [RFC8482]を持つクエリの規定はDNSXLSをカバーしていません。メールサーバーは、2つの同時クエリ、AおよびTXTを発行できます。それ以外の場合、ダウンストリームフィルタは、クエリが成功したことを知っていて、DNSWLが便利なTXTレコードを提供することがわかっている場合、それ自体でTXTクエリを発行できます。QType aのクエリが "None"の結果をもたらした場合、TXTレコードが存在することはありそうもない。
IANA maintains the "Email Authentication Parameters" registry with several subregistries. IANA has made the assignments set out in the following sections.
IANAはいくつかのサブレジストに「Eメール認証パラメータ」レジストリを維持しています。IANAは、次のセクションで割り当てを選択しました。
IANA has created four new entries in the "Email Authentication Methods" registry as follows.
IANAは、次のように「電子メール認証方法」レジストリに4つの新しいエントリを作成しました。
+======+===========+======+========+=================+======+=======+
|Method|Definition |ptype |property|Value |Status|Version|
+======+===========+======+========+=================+======+=======+
|dnswl |RFC 8904 |dns |zone |DNSWL publicly |active| 1 |
| | | | |accessible query | | |
| | | | |root domain | | |
+------+-----------+------+--------+-----------------+------+-------+
|dnswl |RFC 8904 |policy|ip |type A response |active| 1 |
| | | | |received (or a | | |
| | | | |quoted, comma- | | |
| | | | |separated list | | |
| | | | |thereof) | | |
+------+-----------+------+--------+-----------------+------+-------+
|dnswl |RFC 8904 |policy|txt |type TXT query |active| 1 |
| | | | |response | | |
+------+-----------+------+--------+-----------------+------+-------+
|dnswl |RFC 8904 |dns |sec |one of "yes" for |active| 1 |
| | | | |DNSSEC | | |
| | | | |authenticated | | |
| | | | |data, "no" for | | |
| | | | |not signed, or | | |
| | | | |"na" for not | | |
| | | | |applicable | | |
+------+-----------+------+--------+-----------------+------+-------+
Table 1
表1
IANA has created a new entry in the "Email Authentication Property Types" registry as follows.
IANAは、次のように「Eメール認証プロパティタイプ」レジストリに新しいエントリを作成しました。
+=======+============+====================================+
| ptype | Definition | Description |
+=======+============+====================================+
| dns | RFC 8904 | The property being reported |
| | | belongs to the Domain Name System. |
+-------+------------+------------------------------------+
Table 2
表2.
IANA has created four new entries in the "Email Authentication Result Names" registry as follows.
IANAは、次のように「電子メール認証結果名」レジストリに4つの新しいエントリを作成しました。
+=============+===========+===============+========+
| Auth Method | Code | Specification | Status |
+=============+===========+===============+========+
| dnswl | pass | RFC 8904 | active |
+-------------+-----------+---------------+--------+
| dnswl | none | RFC 8904 | active |
+-------------+-----------+---------------+--------+
| dnswl | temperror | RFC 8904 | active |
+-------------+-----------+---------------+--------+
| dnswl | permerror | RFC 8904 | active |
+-------------+-----------+---------------+--------+
Table 3
表3.
Some DNSWLs that provide for free access below a given quota are known to return special codes to signal that the quota has been exceeded (for example, 127.0.0.255). If the MTA cannot interpret that value, that case results in a false positive. It can accept messages that it would otherwise reject. A DNSWL-specific module would realize this fact and call for human intervention.
特定のクォータを下回る無料アクセスを提供するいくつかのDNSWLは、クォータが超えられたことを知らせるために特別なコードを返すことが知られている（例えば、127.0.0.255）。MTAがその値を解釈できない場合、その場合は誤検知が発生します。そうでなければ拒否されるメッセージを受け入れることができます。DNSWL固有のモジュールはこの事実を実現し、人間の介入を呼びかけます。
Returning an RCODE 5 (REFUSED) conveys the concept that the query is "unauthorized" and human intervention required.
RCODE 5を返す（拒否された）クエリが「不正な」と人間の介入であるという概念を伝えます。
The dns.sec property is meant to be as secure as DNSSEC results. It makes sense to use it in an environment where the DNSSEC validation can succeed.
DNS.SECプロパティは、DNSSECの結果と同じくらい安全であることを意味します。DNSSEC検証が成功できる環境でそれを使用することは理にかなっています。
Section 7 of [RFC4033] examines various ways of setting up a stub resolver that either validates DNSSEC locally or trusts the validation provided through a secure channel. For a different class, it is possible to set up a dedicated, caching, DNSSEC-enabled resolver reachable by the mail server through interprocess communication on 127.0.0.1. In such cases, the property dns.sec=yes corresponds to the Authenticated Data (AD) bit in the DNS response header.
[RFC4033]のセクション7は、DNSSECをローカルに検証するか、安全なチャネルを介して提供された検証を信頼するスタブリゾルバを設定するためのさまざまな方法を調べます。別のクラスの場合、127.0.0.1のプロセス間通信を通じて、メールサーバーによって到達可能な専用のキャッシュ、DNSSEC対応のリゾルバを設定することができます。そのような場合、プロパティDNS.SEC = YESは、DNS応答ヘッダの認証されたデータ（AD）ビットに対応します。
When the response contains no DNSSEC data, a security-aware resolver seeks a signed proof of the nonexistence of a DS record at some delegation point. If no error is returned, the zone is unsigned and dns.sec=no can be set. The Security Considerations section of [RFC3225] states:
応答にDNSSECデータが含まれていない場合、セキュリティ対応のリゾルバは、いくつかの委任ポイントでDSレコードの存在しないことの署名付き証明を求めています。エラーが返されない場合、ゾーンは符号なしでDNS.Sec = NOを設定できます。[RFC3225]のセキュリティ上の考慮事項セクション
| The absence of DNSSEC data in response to a query with the DO bit
| set MUST NOT be taken to mean no security information is available
| for that zone as the response may be forged or a non-forged
| response of an altered (DO bit cleared) query.
If the application verifies the DNSSEC signatures on its own, it effectively behaves like a validating resolver and hence can set dns.sec correspondingly.
アプリケーションが独自のDNSSECシグネチャを検証する場合は、検証したリゾルバのように効果的に動作し、それに対応してDNS.SECを設定できます。
When the data is downloaded in bulk and made available on a trusted channel without using DNSSEC, the application sets dns.sec=na or not at all. For example, consider DNSWLs that publish bulk versions of their data duly signed using OpenPGP [RFC4880]. It is the responsibility of system administrators to authenticate the data by downloading and validating the signature. The result of such validation is not reported using dns.sec.
DNSSECを使用せずにデータがバルクでダウンロードされ、信頼できるチャネルで使用可能にされたとき、アプリケーションはDNS.SEC = NAまたは全くないかどうかを設定します。たとえば、OpenPGP [RFC4880]を使用して、データのバルクバージョンのデータのバルクバージョンを公開するDNSWLを検討してください。署名をダウンロードして検証することによってデータを認証することは、システム管理者の責任です。そのような検証の結果はDNS.Secを使用して報告されていません。
For DNSSEC, the considerations of Section 12 of [RFC4033] apply.
DNSSECの場合、[RFC4033]のセクション12の考慮事項が適用されます。
All of the considerations described in Section 7 of [RFC8601] apply. That includes securing against tampering all the channels after the production of the Authentication-Results header field.
[RFC8601]のセクション7に記載されているすべての考慮事項が適用されます。これは、認証結果ヘッダーフィールドの作成後にすべてのチャンネルを改ざんすることに対する固定を含む。
In addition, the usual caveats apply about importing text from external online sources. Although queried DNSWLs are well-known, trusted entities, it is suggested that TXT records be reported only if, upon inspection, their content is deemed actionable and their format compatible with the computing environment.
さらに、通常の注意事項は、外部のオンラインソースからのテキストのインポートについて適用されます。照会されたDNSWLはよく知られているが信頼できるエンティティであるが、検査の際に、それらのコンテンツが実行可能であると見なされ、それらのフォーマットがコンピューティング環境と互換性とされていると見なされる場合にのみ、TXTレコードが報告されることが示唆されている。
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, <https://www.rfc-editor.org/info/rfc2606>.
[RFC2606]イーストレイク3RD、D.およびA.Panitz、「予約トップレベルDNS名」、BCP 32、RFC 2606、DOI 10.17487 / RFC2606、1999年6月、<https：//www.rfc-editor.org/info/RFC2606>。
[RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, DOI 10.17487/RFC5782, February 2010, <https://www.rfc-editor.org/info/rfc5782>.
[RFC5782] Levine、J.、「DNSブラックリストとホワイトリスト」、RFC 5782、DOI 10.17487 / RFC5782、2010年2月、<https：//www.rfc-editor.org/info/rfc5782>。
[RFC8601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 8601, DOI 10.17487/RFC8601, May 2019, <https://www.rfc-editor.org/info/rfc8601>.
[RFC8601] Kucherawy、M.、「メッセージ認証ステータスを示すメッセージヘッダフィールド」、RFC 8601、DOI 10.17487 / RFC8601、2019年5月、<https：//www.rfc-editor.org/info/rfc8601>。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P.、「ドメイン名 - コンセプトと施設」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https：//www.rfc-editor.org/info/rfc1034>。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, DOI 10.17487/RFC3225, December 2001, <https://www.rfc-editor.org/info/rfc3225>.
[RFC3225] Conrad、D.、「DNSSECのレゾルバのサポートの表示」、RFC 3225、DOI 10.17487 / RFC3225、2001年12月、<https://www.rfc-editor.org/info/rfc3225>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] YERGEAU、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https：//www.rfc-editor.org/info/RFC3629>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ紹介および要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https：//www.rfc-editor.org/info/rfc4033>。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, <https://www.rfc-editor.org/info/rfc4880>.
[RFC4880] Callas、J.、Donnerhacke、L.、Finney、H.、Shaw、D.、およびR.Thayer、D.、およびR.Thayer、 "OpenPGPメッセージフォーマット"、RFC 4880、DOI 10.17487 / RFC4880、2007年11月、<https：//www.rfc-editor.org/info/rfc4880>。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/info/rfc5198>.
[RFC5198] Klensin、J.およびM. Pidlipsky、「ネットワークインターチェンジのためのUnicode Format」、RFC 5198、DOI 10.17487 / RFC5198、2008年3月、<https：//www.rfc-editor.org/info/rfc5198>。
[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>。
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>.
[RFC6376] Crocker、D.、ED。、Hansen、T.、Ed。、およびM.Kucherawy、Ed。、「ドメインキー識別メール（DKIM）シグニチャ」、STD 76、RFC 6376、DOI 10.17487 / RFC6376、2011年9月<https：//www.rfc-editor.org/info/rfc6376>。
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, February 2012, <https://www.rfc-editor.org/info/rfc6530>.
[RFC6530] Klensin、J.およびY. KO、「国際化された電子メールのための概要とフレームワーク」、RFC 6530、DOI 10.17487 / RFC6530、2012年2月、<https：//www.rfc-editor.org/info/rfc6530>。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762] Cheshire、S.およびM. Krochmal、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<https：//www.rfc-editor.org/info/rfc6762>。
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>.
[RFC7208]キタマン、S。、「電子メールでのドメインの使用、バージョン1」、RFC 7208、DOI 10.17487 / RFC7208、<https://www.rfc-editor.org/ info / rfc7208>。
[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>。
[RFC8460] Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J., and M. Risher, "SMTP TLS Reporting", RFC 8460, DOI 10.17487/RFC8460, September 2018, <https://www.rfc-editor.org/info/rfc8460>.
[RFC8460]マルゴリス、D.、Brotman、A。、Ramakrishnan、B.、Jones、J.、およびM.Risher、「SMTP TLSレポート」、RFC 8460、DOI 10.17487 / RFC8460、2018年9月、<https：//www.rfc-editor.org/info/rfc8460>。
[RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, "Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January 2019, <https://www.rfc-editor.org/info/rfc8482>.
[RFC8482]、J.、Gudmundsson、O.、Majkowski、M.、およびE. Hunt、「Qtype = Any」、RFC 8482、DOI 10.17487 / RFC8482、2019年1月、DNSクエリへの最小の応答<https://www.rfc-editor.org/info/rfc8482>。
[Courier-MTA] "Courier Mail Server", <https://www.courier-mta.org/>.
[Courier-MTA]「Courier Mail Server」、<https：//www.courier-mta.org/>。
[DNSWL] "dnswl.org - E-Mail Reputation - Protect against false positives", <https://www.dnswl.org/>.
[DNSWL] "DNSWL.ORG - 電子メール評判 - 誤検知を保護する"、<https://www.dnswl.org/>。
[NFC] Whistler, K., Ed., "Unicode Normalization Forms", Unicode Standard Annex 15, February 2020, <https://www.unicode.org/reports/tr15/tr15-50.html>.
[NFC]ウィスラー、K。、「Unicode正規化フォーム」、Unicode標準附属書15、2020年2月15日、<https：//www.unicode.org/reports/tr15/tr15-50.html>。
Delivered-To: recipient@example.org
Return-Path: <sender@example.com>
Authentication-Results: mta.example.org;
dkim=pass (whitelisted) header.i=@example.com
Authentication-Results: mta.example.org;
dnswl=pass dns.zone=list.dnswl.example dns.sec=na
policy.ip=127.0.10.1
policy.txt="fwd.example https://dnswl.example/?d=fwd.example"
Received-SPF: fail (Address does not pass Sender Policy Framework)
client-ip=2001:db8::2:1;
envelope-from="sender@example.com";
helo=mail.fwd.example;
receiver=mta.example.org;
Received: from mail.fwd.example (mail.fwd.example [2001:db8::2:1])
(TLS: TLSv1/SSLv3,128bits,ECDHE-RSA-AES128-GCM-SHA256)
by mta.example.org with ESMTPS; Thu, 03 Oct 2019 19:23:11 +0200
id 00000000005DC044.000000005702D87C.000007FC
Figure 1: Trace Fields at the Top of the Header
図1：ヘッダー上部のトレースフィールド
The message went through a third party, fwd.example, which forwarded it to the final MTA. The mail path was not arranged beforehand with the involved MTAs; it emerged spontaneously. This message would not have made it to the target without whitelisting, because:
メッセージは第三者、fwd.exampleを経て、それを最終MTAに転送しました。メールパスは、関与するMTAと予め配置されていませんでした。自発的に出現しました。このメッセージは、ホワイトリスト化なしでターゲットにそれを作ったわけではありません。
* the author domain published a strict SPF policy (-all),
* 作者ドメインは厳密なSPFポリシーを発行しました（-all）、
* the forwarder did not alter the bounce address, and
* フォワーダはバウンスアドレスを変更しませんでした。
* the target usually honors reject on fail, according to Section 8.4 of [RFC7208].
* ターゲットは通常、[RFC7208]のセクション8.4によると、拒否を拒否します。
However, the target also implemented the last paragraph of Appendix D.3 of [RFC7208]. Its behavior hinges on the following DNS entries:
ただし、ターゲットは[RFC7208]の付録D.3の最後の段落を実施しました。その動作は次のDNSエントリを推定します。
1.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.b.8.2.0.0.1. list.dnswl.example. IN A 127.0.10.1 IN TXT "fwd.example https://dnswl.example/?d=fwd.example"
1.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.0.0.1。list.dnswl.example。TXT "fwd.example https：//dnswl.example/？d = fwd.example"で127.0.10.1では
Figure 2: DNS Resource Records for 2001:db8::2:1 (line breaks for
editorial reasons)
If mail.fwd.example had connected from address 192.0.2.1, then the query name would have been "1.2.0.192.list.dnswl.example". See full description in [RFC5782].
mail.fwd.exampleがアドレス192.2.1から接続されていた場合、クエリ名は "1.2.0.192.list.dnswl.example"でした。[RFC5782]の詳細な説明を参照してください。
At connection time, because the remote IP address is whitelisted, the target MTA did not reject the message before DATA. Instead, it recorded the SPF fail result and indicated the local policy mechanism that was applied in order to override that result. Subsequent filtering verified DKIM [RFC6376].
接続時には、リモートIPアドレスがホワイトリストされているため、ターゲットMTAはデータの前にメッセージを拒否しませんでした。代わりに、SPFの障害結果を記録し、その結果を上書きするために適用されたローカルポリシーメカニズムを示しました。その後のフィルタリング検証済みDKIM [RFC6376]。
At later stages, mail filters can reject or quarantine the message based on its content. A deeper knowledge of the policy values obtained from dnswl.example allows interpreting the values of policy.ip and weighing them against other factors so as to make better decisions.
後の段階で、メールフィルタはそのコンテンツに基づいてメッセージを拒否または隔離することができます。DNSWL.Exampleから得られたポリシー値についてのより深い知識は、Policy.IPの値を解釈し、より良い決定を下すようにそれらを他の要因に対して秤量することを可能にします。
Implementation details mentioned in this section have been stable for several years. Yet, this description is necessarily superficial, version dependent, and subject to change.
このセクションで説明されている実施の詳細は数年間安定しています。それでも、この説明は必ず表在した、バージョンに依存し、変更されることがあります。
Courier-MTA [Courier-MTA] can be configured to look up DNSBLs and DNSWLs, with similar command-line switches:
Courier-MTA [Courier-MTA]は、同様のコマンドラインスイッチでDNSBLとDNSWLを検索するように設定できます。
-block=zone[=displayzone][,var[/n.n.n.n][,msg]]
-allow=zone[=displayzone][,var[/n.n.n.n[,]]]
"zone" is the zone to be queried.
「ゾーン」は照会されるべきゾーンです。
"displayzone" is only used for -allow; it is the value to be set in the dns.zone property.
「DisplayZone」は、そのためにのみ使用されます。dns.zoneプロパティに設定される値です。
"var" stands for the environment variable whose existence triggers a special action. The default variable names result in a conventional behavior implemented by Courier-MTA. By setting different environment variables, users can customize the behavior. Conventional behavior differs widely between -block and -allow. The former rejects the message; the latter produces Authentication-Results header fields.
"var"存在が特別なアクションを引き起こす環境変数を表します。デフォルトの変数名は、Courier-MTAによって実装された従来の動作をもたらします。さまざまな環境変数を設定することで、ユーザーは動作をカスタマイズできます。従来の挙動は、ブロックと - その間に大きく異なる。前者はメッセージを拒否します。後者は認証結果ヘッダーフィールドを生成します。
The n.n.n.n IP address requires a precise A record response. If not given, any response results in setting the corresponding variable. If given, variables are set only if the response matches exactly. Such syntax provides for a very limited interpretation of the information encoded in A records. However, it is considered to be too complicated already. Even specifying a range, an enumeration of values, or a regular expression would require something beyond what a normal user would be willing to manage.
n.n.n.nのIPアドレスには、正確なレコード応答が必要です。与えられていない場合、応答は対応する変数を設定することになります。与えられた場合、変数は応答が正確に一致する場合にのみ設定されます。そのような構文は、レコード内で符号化された情報の非常に限られた解釈を提供する。しかし、すでに複雑すぎると考えられています。範囲を指定しても、値の列挙、または正規表現は、通常のユーザーが管理しても構わないと思っているものを超えて何かを必要とするでしょう。
Finally, the trailing message, which overrides the 5xx SMTP reply for -block, is not used for -allow, except that its mere presence requires querying TXT records to be registered in policy.txt.
最後に、-blockのための5xx SMTP応答をオーバーライドする末尾のメッセージは、Policy.txtに登録されるTXTレコードを照会する必要があることを除いて、-allowには使用されません。
SPF is part of Courier-MTA's core. It is configured separately and provides for an "allowok" keyword to indicate the choice to override rejection in case of SPF failure and -allow whitelisting.
SPFはCourier-MTAのコアの一部です。それは別々に構成され、SPF障害とホワイトリストの場合に拒否をオーバーライドするための選択を示すために "allowok"キーワードを提供します。
A customary whitelist is defined by DNSWL.org [DNSWL]. It serves A records encoded as follows:
慣習的なホワイトリストはDNSWL.org [DNSWL]によって定義されます。それは次のようにエンコードされたレコードを提供します。
1st octet: 127.
1番目のオクテット：127。
2nd octet: 0.
2番目のオクテット：0。
3rd octet: Category of business, 15 values.
3オクテット：ビジネスのカテゴリ、15の値。
4th octet: Trustworthiness/score, 4 values.
4番目のオクテット：信頼性/スコア、4つの値。
They also serve TXT records containing the domain name followed by a URL pointing to further information about the relevant organization, such as what other IP addresses of theirs are being whitelisted. They don't use UTF-8.
それらはまた、ドメイン名を含むTXTレコードとそれに続く他のIPアドレスがホワイトリストされているなどの関連組織に関するさらなる情報を指すURLを提供します。彼らはUTF-8を使わない。
DNSWL.org provides for free registration and free access below 100,000 queries per day. They use a special return code, 127.0.0.255 as exemplified above, to signal that the quota has been exceeded. Although Courier-MTA itself does not recognize this return code, it has a mail filter (zdkimfilter, named after its main usage) that hard codes recognition of this code and the code for trustworthiness in the 4th octet.
DNSwl.orgは、無料登録および1日1日100,000のクエリを下回る無料アクセスを提供します。それらは、上で例示されているように、クォータが超えたことを知らせるために、特別な戻りコード127.0.0.255を使用します。Courier-MTA自体がこの戻りコードを認識していないが、このコードのハードコードと4番目のオクテットの信頼性のためのコードを認識したメールフィルタ（主な使い方に指名されたZDKIMFilter）があります。
The description of the new ptype proposed in Section 4.2 says, "The property being reported belongs to the Domain Name System." That definition can broadly include any tag found in a domain's TXT record. For example, designers of authentication methods can agree that within a resinfo of a given method, any dns ptype refers to tags in the relevant DNS record, unless otherwise specified. So one could have, say:
セクション4.2で提案されている新しいPTYPEの説明は、「報告されているプロパティはドメインネームシステムに属しています」。その定義は、ドメインのTXTレコードにある任意のタグを広く含めることができます。たとえば、認証方法の設計者は、特定の方法の樹立FO内で、特に指定のない限り、任意のDNS PTYPEとは関連するDNSレコードのタグを参照することに同意できます。だから、言うことができる
Authentication-Results: example.com;
spf=pass smtp.mailfrom=example.net dns.sec=y;
dkim=pass header.i=@example.org header.b=jIvx30NG dns.s=tlsrpt
While dns.sec is defined above, albeit not for the spf method, the use of tlsrpt in the DKIM record is exemplified in Section 3 of [RFC8460]. The tag s= is part of the DKIM TXT record, not to be confused with the selector s=, which is part of a DKIM signature. Just like the latter can be reported as header.s because the DKIM header field is in the message header, it may make sense to report the former as dns.s because the DKIM DNS record is in the DNS.
DNS.Secは上記で定義されているが、SPF方式では含まれていないが、DKIMレコード内のTLSRPTの使用は[RFC8460]のセクション3に例示される。タグS =は、DKIM署名の一部であるセレクタS =と混同しないように、DKIM TXTレコードの一部である。DKIMヘッダーフィールドはメッセージヘッダーにあるため、後者がヘッダーSとして報告できるように、DKIM DNSレコードがDNSにあるため、以前はDNS.Sとして報告するのは理にかなっている可能性があります。
NOTE: This is only a hint at what may become a consistent naming convention around the new ptype. In any case, any new property using this ptype requires its own formal definition. This document does NOT define the property dns.s=, let alone the service tlsrpt.
注：これは、新しいPTypeの周囲の一貫した命名規則になる可能性があるものでのヒントにすぎません。いずれにせよ、このPTypeを使用した新しいプロパティでは、独自の正式な定義が必要です。このドキュメントは、プロパティDNS.S.S =を定義していません。サービスTLSRPT。
Author's Address
著者の住所
Alessandro Vesely v. L. Anelli 13 20122 Milano MI Italy
アレッサンドロヴァーリーv。L. Anelli 13 20122 Milano Miイタリア
Email: vesely@tana.it