[要約] RFC 8460は、SMTP TLS Reportingのための仕様であり、TLS接続の問題を報告するためのメカニズムを提供します。目的は、SMTPサーバーのTLS接続のセキュリティを向上させ、問題の特定と解決を容易にすることです。
Internet Engineering Task Force (IETF) D. Margolis
Request for Comments: 8460 Google, Inc.
Category: Standards Track A. Brotman
ISSN: 2070-1721 Comcast, Inc.
B. Ramakrishnan
Oath, Inc.
J. Jones
Microsoft, Inc.
M. Risher
Google, Inc.
September 2018
SMTP TLS Reporting
SMTP TLSレポート
Abstract
概要
A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS-Based Authentication of Named Entities (DANE) TLSA, and MTA Strict Transport Security (MTA-STS). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations.
STARTTLS、DNSベースの名前付きエンティティの認証（DANE）TLSA、MTA Strict Transport Security（MTA-STS）など、SMTPメール転送エージェント（MTA）間の暗号化チャネルを確立するためのプロトコルがいくつかあります。これらのプロトコルは、設定ミスやアクティブな攻撃が原因で失敗し、メッセージが配信されなかったり、暗号化されていないチャネルや認証されていないチャネルで配信されたりする可能性があります。このドキュメントでは、送信システムが統計情報と潜在的な障害に関する特定の情報を受信者ドメインと共有できるレポートメカニズムと形式について説明します。受信者のドメインは、この情報を使用して、潜在的な攻撃を検出し、意図しない誤設定を診断できます。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8460.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8460で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Related Technologies . . . . . . . . . . . . . . . . . . . . 5
3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 8
3.1.1. Report Using MAILTO . . . . . . . . . . . . . . . . . 8
3.1.2. Report Using HTTPS . . . . . . . . . . . . . . . . . 8
4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Report Time Frame . . . . . . . . . . . . . . . . . . . . 9
4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 10
4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 10
4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 11
4.3.3. General Failures . . . . . . . . . . . . . . . . . . 11
4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 12
4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 12
4.5. Policy Samples . . . . . . . . . . . . . . . . . . . . . 15
5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 16
5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 19
5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 19
5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 20
5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6.1. Message Headers . . . . . . . . . . . . . . . . . . . . . 20
6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 21
6.3. +gzip Media Type Suffix . . . . . . . . . . . . . . . . . 22
6.4. application/tlsrpt+json Media Type . . . . . . . . . . . 23
6.5. application/tlsrpt+gzip Media Type . . . . . . . . . . . 24
6.6. STARTTLS Validation Result Types . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 32
A.1. Report Using MAILTO . . . . . . . . . . . . . . . . . . . 32
A.2. Report Using HTTPS . . . . . . . . . . . . . . . . . . . 32
Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 32
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and hosts to establish secure SMTP sessions over TLS. The protocol design uses an approach that has come to be known as "Opportunistic Security" (OS) [RFC7435]. This method maintains interoperability with clients that do not support STARTTLS, but it means that any attacker could potentially eavesdrop on a session. An attacker could perform a downgrade or interception attack by deleting parts of the SMTP session (such as the "250 STARTTLS" response) or redirect the entire SMTP session (perhaps by overwriting the resolved MX record of the delivery domain).
SMTPのSTARTTLS拡張[RFC3207]により、SMTPクライアントおよびホストは、TLSを介して安全なSMTPセッションを確立できます。プロトコル設計は、「日和見セキュリティ」（OS）[RFC7435]として知られるようになったアプローチを使用します。この方法は、STARTTLSをサポートしないクライアントとの相互運用性を維持しますが、攻撃者がセッションを盗聴する可能性があることを意味します。攻撃者は、SMTPセッションの一部（ "250 STARTTLS"応答など）を削除することでダウングレードまたはインターセプト攻撃を実行するか、SMTPセッション全体をリダイレクトする可能性があります（おそらく配信ドメインの解決済みMXレコードを上書きすることにより）。
Because such "downgrade attacks" are not necessarily apparent to the receiving MTA, this document defines a mechanism for sending domains to report on failures at multiple stages of the MTA-to-MTA conversation.
このような「ダウングレード攻撃」は受信側のMTAには必ずしも明らかではないため、このドキュメントでは、MTAからMTAへの会話の複数の段階で障害を報告するためにドメインを送信するメカニズムを定義します。
Recipient domains may also use the mechanisms defined by MTA-STS [RFC8461] or DANE [RFC6698] to publish additional encryption and authentication requirements; this document defines a mechanism for sending domains that are compatible with MTA-STS or DANE to share success and failure statistics with recipient domains.
受信者ドメインは、MTA-STS [RFC8461]またはDANE [RFC6698]によって定義されたメカニズムを使用して、追加の暗号化および認証要件を公開することもできます。このドキュメントでは、MTA-STSまたはDANEと互換性のあるドメインを送信して、成功および失敗の統計を受信者ドメインと共有するためのメカニズムを定義します。
Specifically, this document defines a reporting schema that covers failures in routing, DNS resolution, and STARTTLS negotiation; policy validation errors for both DANE [RFC6698] and MTA-STS [RFC8461]; and a standard TXT record that recipient domains can use to indicate where reports in this format should be sent. The report can also serve as a heartbeat to indicate that systems are successfully negotiating TLS during sessions as expected.
具体的には、このドキュメントでは、ルーティング、DNS解決、およびSTARTTLSネゴシエーションの失敗に対応するレポートスキーマを定義しています。 DANE [RFC6698]とMTA-STS [RFC8461]の両方のポリシー検証エラー。受信者のドメインがこの形式のレポートの送信先を示すために使用できる標準のTXTレコード。レポートは、システムがセッション中にTLSを正常にネゴシエートしていることを示すハートビートとしても機能します。
This document is intended as a companion to the specification for SMTP MTA-STS [RFC8461] and adds reporting abilities for those implementing DANE [RFC7672].
このドキュメントは、SMTP MTA-STS [RFC8461]の仕様と対になることを目的としており、DANE [RFC7672]を実装する人のためのレポート機能を追加します。
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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
We also define the following terms for further use in this document:
このドキュメントでさらに使用するために、次の用語も定義します。
o MTA-STS Policy: A mechanism by which administrators can specify the expected TLS availability, presented identity, and desired actions for a given email recipient domain. MTA-STS is defined in [RFC8461].
o MTA-STSポリシー：管理者が予想されるTLSの可用性、提示されたID、および特定の電子メール受信者ドメインに必要なアクションを指定できるメカニズム。 MTA-STSは[RFC8461]で定義されています。
o DANE Policy: A mechanism by which administrators can use DNSSEC to commit an MTA to support STARTTLS and to publish criteria to be used to validate its presented certificates. DANE for SMTP is defined in [RFC7672], with the base specification defined in [RFC6698] (and updated by [RFC7671]).
o DANEポリシー：管理者がDNSSECを使用してMTAをコミットし、STARTTLSをサポートし、提示された証明書の検証に使用される基準を公開できるメカニズム。 DANE for SMTPは[RFC7672]で定義されており、基本仕様は[RFC6698]で定義されています（[RFC7671]によって更新されています）。
o TLSRPT (TLS Reporting) Policy: A policy specifying the endpoint to which Sending MTAs should deliver reports.
o TLSRPT（TLSレポート）ポリシー：送信側MTAがレポートを配信するエンドポイントを指定するポリシー。
o Policy Domain: The domain against which a TLSRPT, an MTA-STS, or a DANE policy is defined. For TLSRPT and MTA-STS, this is typically the same as the envelope recipient domain [RFC5321], but when mail is routed to a "smarthost" gateway by local policy, the "smarthost" domain name is used instead. For DANE, the Policy Domain is the "TLSA base domain" of the receiving SMTP server as described in Section 2.2.3 of RFC 7672 and Section 3 of RFC 6698.
o ポリシードメイン：TLSRPT、MTA-STS、またはDANEポリシーが定義されているドメイン。 TLSRPTおよびMTA-STSの場合、これは通常、エンベロープ受信者ドメイン[RFC5321]と同じですが、メールがローカルポリシーによって「スマートホスト」ゲートウェイにルーティングされる場合、代わりに「スマートホスト」ドメイン名が使用されます。 DANEの場合、ポリシードメインは、RFC 7672のセクション2.2.3およびRFC 6698のセクション3で説明されているように、受信SMTPサーバーの「TLSAベースドメイン」です。
o Sending MTA: The MTA initiating the relay of an email message.
o MTAの送信：電子メールメッセージのリレーを開始するMTA。
o Aggregate Report URI (rua): A comma-separated list of locations where the report is to be submitted.
o 集約レポートURI（rua）：レポートが送信される場所のコンマ区切りのリスト。
o ABNF: Augmented Backus-Naur Form, a syntax for formally specifying syntax, defined in [RFC5234] and [RFC7405].
o ABNF：[RFC5234]と[RFC7405]で定義されている、構文を正式に指定するための構文である拡張Backus-Naurフォーム。
o This document is intended as a companion to the specification for SMTP MTA-STS [RFC8461].
o このドキュメントは、SMTP MTA-STS [RFC8461]の仕様と対になることを意図しています。
o SMTP TLSRPT defines a mechanism for sending domains that are compatible with MTA-STS or DANE to share success and failure statistics with recipient domains. DANE is defined in [RFC6698], and MTA-STS is defined in [RFC8461].
o SMTP TLSRPTは、MTA-STSまたはDANEと互換性のあるドメインを送信して、成功および失敗の統計を受信者ドメインと共有するためのメカニズムを定義します。 DANEは[RFC6698]で定義されており、MTA-STSは[RFC8461]で定義されています。
A domain publishes a record to its DNS indicating that it wishes to receive reports. These SMTP TLSRPT policies are distributed via DNS from the Policy Domain's zone as TXT records (similar to Domain-based Message Authentication, Reporting, and Conformance (DMARC) policies) under the name "_smtp._tls". For example, for the Policy Domain "example.com", the recipient's TLSRPT policy can be retrieved from "_smtp._tls.example.com".
ドメインは、レポートの受信を希望することを示すレコードをDNSに発行します。これらのSMTP TLSRPTポリシーは、DNSを介してポリシードメインのゾーンからTXTレコード（ドメインベースのメッセージ認証、レポート、および準拠（DMARC）ポリシーに類似）として「_smtp._tls」という名前で配布されます。たとえば、ポリシードメイン「example.com」の場合、受信者のTLSRPTポリシーは「_smtp._tls.example.com」から取得できます。
Policies consist of the following directives:
ポリシーは次のディレクティブで構成されています。
o "v": This document defines version 1 of TLSRPT, for which this value MUST be equal to "TLSRPTv1". Other versions may be defined in later documents.
o "v"：このドキュメントは、この値が "TLSRPTv1"と等しくなければならないTLSRPTのバージョン1を定義します。他のバージョンは、後のドキュメントで定義される場合があります。
o "rua": A URI specifying the endpoint to which aggregate information about policy validation results should be sent (see Section 4, "Reporting Schema", for more information). Two URI schemes are supported: "mailto" and "https". As with DMARC [RFC7489], the Policy Domain can specify a comma-separated list of URIs.
o 「rua」：ポリシー検証結果に関する集約情報の送信先となるエンドポイントを指定するURI（詳細については、セクション4「レポートスキーマ」を参照）。 「mailto」と「https」の2つのURIスキームがサポートされています。 DMARC [RFC7489]と同様に、ポリシードメインはURIのコンマ区切りリストを指定できます。
o In the case of "https", reports should be submitted via POST [RFC7231] to the specified URI. Report submitters MAY ignore certificate validation errors when submitting reports via HTTPS POST.
o 「https」の場合、レポートはPOST [RFC7231]経由で指定されたURIに送信する必要があります。レポート送信者は、HTTPS POSTを介してレポートを送信するときに、証明書検証エラーを無視する場合があります。
o In the case of "mailto", reports should be submitted to the specified email address [RFC6068]. When sending failure reports via SMTP, Sending MTAs MUST deliver reports despite any TLS-related failures and SHOULD NOT include this SMTP session in the next report. This may mean that the reports are delivered unencrypted. Reports sent via SMTP MUST contain a valid DomainKeys Identified Mail (DKIM) [RFC6376] signature by the reporting domain. Reports lacking such a signature MUST be ignored by the recipient. DKIM signatures MUST NOT use the "l=" attribute to limit the body length used in the signature. This ensures attackers cannot append extraneous or misleading data to a report without breaking the signature. The DKIM TXT record SHOULD contain the appropriate service type declaration, "s=tlsrpt". If not present, the receiving system MAY ignore reports lacking that service type.
o 「mailto」の場合、レポートは指定された電子メールアドレス[RFC6068]に送信する必要があります。 SMTP経由で障害レポートを送信する場合、MTAを送信すると、TLS関連の障害があってもレポートを配信する必要があり、次のレポートにこのSMTPセッションを含めないでください。これは、レポートが暗号化されずに配信されることを意味する場合があります。 SMTP経由で送信されるレポートには、レポートドメインによる有効なDomainKeys Identified Mail（DKIM）[RFC6376]署名が含まれている必要があります。このような署名がないレポートは、受信者が無視する必要があります。 DKIM署名は、署名で使用される本文の長さを制限するために「l =」属性を使用してはなりません（MUST NOT）。これにより、攻撃者は署名を壊すことなく、無関係なデータや誤解を招くデータをレポートに追加できなくなります。 DKIM TXTレコードには、適切なサービスタイプ宣言「s = tlsrpt」を含める必要があります（SHOULD）。存在しない場合、受信システムは、そのサービスタイプが不足しているレポートを無視してもよい（MAY）。
Sample DKIM record:
DKIMレコードの例：
dkim_selector._domainkey.example.com TXT
"v=DKIM1;k=rsa;s=tlsrpt;p=Mlf4qwSZfase4fa=="
The formal definition of the "_smtp._tls" TXT record, defined using [RFC5234] and [RFC7405], is as follows:
[_smtp._tls] TXTレコードの正式な定義は、[RFC5234]と[RFC7405]を使用して定義され、次のようになります。
tlsrpt-record = tlsrpt-version 1*(field-delim tlsrpt-field) [field-delim]
tlsrpt-record = tlsrpt-version 1 *（field-delim tlsrpt-field）[field-delim]
field-delim = *WSP ";" *WSP
tlsrpt-field = tlsrpt-rua / ; Note that the tlsrpt-extension ; tlsrpt-rua record is ; required.
tlsrpt-field = tlsrpt-rua /; tlsrpt-extensionに注意してください。 tlsrpt-ruaレコードは;必須。
tlsrpt-version = %s"v=TLSRPTv1"
tlsrpt-rua = %s"rua="
tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri)
tlsrpt-uri = URI
; "URI" is imported from [RFC3986];
; commas (ASCII 0x2C), exclamation
; points (ASCII 0x21), and semicolons
; (ASCII 0x3B) MUST be encoded
tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value
tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value
tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA /
DIGIT / "_" / "-" / ".")
tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
; chars excluding "=", ";", SP, and control
; chars
If multiple TXT records for "_smtp._tls" are returned by the resolver, records that do not begin with "v=TLSRPTv1;" are discarded. If the number of resulting records is not one, senders MUST assume the recipient domain does not implement TLSRPT. If the resulting TXT record contains multiple strings (as described in Section 3.3 of [RFC7208]), then the record MUST be treated as if those strings are concatenated without adding spaces.
「_smtp._tls」の複数のTXTレコードがリゾルバーによって返された場合、「v = TLSRPTv1;」で始まらないレコード。破棄されます。結果のレコードの数が1でない場合、送信者は受信者のドメインがTLSRPTを実装していないと想定する必要があります。結果のTXTレコードに複数の文字列が含まれている場合（[RFC7208]のセクション3.3で説明）、レコードは、スペースを追加せずにそれらの文字列が連結されているかのように処理する必要があります。
The record supports the ability to declare more than one rua, and if there exists more than one, the reporter MAY attempt to deliver to each of the supported rua destinations. A receiver MAY opt to only attempt delivery to one of the endpoints; however, the report SHOULD NOT be considered successfully delivered until one of the endpoints accepts delivery of the report.
レコードは複数のruaを宣言する機能をサポートします。複数が存在する場合、レポーターはサポートされている各rua宛先への配信を試みてもかまいません（MAY）。受信者は、いずれかのエンドポイントへの配信のみを試みることを選択できます。ただし、エンドポイントの1つがレポートの配信を受け入れるまで、レポートは正常に配信されたと見なすべきではありません。
Parsers MUST accept TXT records that are syntactically valid (i.e., valid key/value pairs separated by semicolons) and implement a superset of this specification, in which case unknown fields SHALL be ignored.
パーサーは、構文的に有効なTXTレコード（つまり、セミコロンで区切られた有効なキー/値のペア）を受け入れ、この仕様のスーパーセットを実装する必要があります。この場合、不明なフィールドは無視されます。
_smtp._tls.example.com. IN TXT \
"v=TLSRPTv1;rua=mailto:reports@example.com"
_smtp._tls.example.com. IN TXT \
"v=TLSRPTv1; \
rua=https://reporting.example.com/v1/tlsrpt"
The report is composed as a plaintext file encoded in the Internet JSON (I-JSON) format [RFC7493].
レポートは、インターネットJSON（I-JSON）形式[RFC7493]でエンコードされたプレーンテキストファイルとして構成されます。
Aggregate reports contain the following fields:
集計レポートには、次のフィールドが含まれています。
o Report metadata:
o レポートのメタデータ：
* The organization responsible for the report
* レポートを担当する組織
* Contact information for one or more responsible parties for the contents of the report
* レポートの内容の責任者の連絡先情報
* A unique identifier for the report
* レポートの一意の識別子
* The reporting date range for the report
* レポートのレポート期間
o Policy, consisting of:
o 以下から構成されるポリシー：
* One of the following policy types: (1) the MTA-STS Policy applied (as a string), (2) the DANE TLSA record applied (as a string, with each RR entry of the RRset listed and separated by a semicolon), and (3) the literal string "no-policy-found", if neither a DANE nor MTA-STS Policy could be found.
* 次のポリシータイプのいずれか：（1）MTA-STSポリシーが適用された（文字列として）、（2）DANE TLSAレコードが適用された（文字列として、RRsetの各RRエントリがセミコロンでリストされ、区切られている）、 （3）DANEポリシーもMTA-STSポリシーも見つからなかった場合は、リテラル文字列「no-policy-found」。
* The domain for which the policy is applied
* ポリシーが適用されるドメイン
* The MX host
* MXホスト
o Aggregate counts, comprising result type, Sending MTA IP, receiving MTA hostname, session count, and an optional additional information field containing a URI for recipients to review further information on a failure type.
o 結果タイプ、MTA IPの送信、MTAホスト名の受信、セッションカウント、および受信者が失敗タイプに関する詳細情報を確認するためのURIを含むオプションの追加情報フィールドを含む集計カウント。
Note that the failure types are non-exclusive; an aggregate report may contain overlapping "counts" of failure types when a single send attempt encountered multiple errors. Reporters may report multiple applied policies (for example, an MTA-STS Policy and a DANE TLSA record for the same domain and MX). Because of this, even in the case where only a single policy was applied, the "policies" field of the report body MUST be an array and not a singular value.
失敗のタイプは非排他的であることに注意してください。単一の送信試行で複数のエラーが発生した場合、集約レポートには、重複する障害タイプの「カウント」が含まれることがあります。レポーターは、複数の適用されたポリシー（たとえば、同じドメインとMXのMTA-STSポリシーとDANE TLSAレコード）を報告できます。このため、単一のポリシーのみが適用された場合でも、レポート本文の「policies」フィールドは配列であり、特異な値ではありません。
In the case of multiple failure types, the "failure-details" array would contain multiple entries. Each entry would have its own set of information pertaining to that failure type.
複数の障害タイプの場合、「failure-details」配列には複数のエントリが含まれます。各エントリには、その障害タイプに関連する独自の情報セットがあります。
The report SHOULD cover a full day, from 00:00-24:00 UTC. This should allow for easier correlation of failure events. To avoid unintentionally overloading the system processing the reports, the reports should be delivered after some delay, perhaps several hours.
レポートは、UTC 00:00から24:00までの1日をカバーする必要があります（SHOULD）。これにより、障害イベントの関連付けが容易になります。レポートを処理するシステムが意図せず過負荷になることを避けるために、レポートは、おそらく数時間の遅延の後に配信される必要があります。
As an example, a sending site might want to introduce a random delay of up to four hours:
例として、送信サイトは最大4時間のランダムな遅延を導入することができます。
func generate_sleep_delay() {
min_delay = 1
max_delay = 14400
rand = random(min_delay, max_delay)
return rand
}
func generate_report(policy_domain) {
do_rpt_work(policy_domain)
send_rpt(policy_domain)
}
func generate_tlsrpt() {
sleep(generate_sleep_delay())
for policy_domain in list_of_tlsrpt_enabled_domains {
generate_report(policy_domain)
}
}
o "total-successful-session-count": This indicates that the Sending MTA was able to successfully negotiate a policy-compliant TLS connection and serves to provide a "heartbeat" to receiving domains that signifies reporting is functional and tabulating correctly. This field contains an aggregate count of successful connections for the reporting system.
o "total-successful-session-count"：これは、送信MTAがポリシー準拠のTLS接続を正常にネゴシエートでき、受信ドメインに「ハートビート」を提供して、レポートが機能し、正しく集計されていることを示します。このフィールドには、レポートシステムの成功した接続の総数が含まれます。
o "total-failure-session-count": This indicates that the Sending MTA was unable to successfully establish a connection with the receiving platform. Section 4.3, "Result Types", will elaborate on the failed negotiation attempts. This field contains an aggregate count of failed connections.
o 「total-failure-session-count」：これは、送信側MTAが受信側プラットフォームとの接続を正常に確立できなかったことを示します。セクション4.3、「結果タイプ」では、失敗した交渉の試みについて詳しく説明します。このフィールドには、失敗した接続の総数が含まれます。
The list of result types will start with the minimal set below and is expected to grow over time based on real-world experience. The initial set is outlined in Sections 4.3.1 to 4.3.4:
結果のタイプのリストは、以下の最小限のセットから始まり、実際の経験に基づいて、時間の経過とともに拡大すると予想されます。最初のセットの概要は、セクション4.3.1から4.3.4にあります。
o "starttls-not-supported": This indicates that the recipient MX did not support STARTTLS.
o 「starttls-not-supported」：これは、受信者MXがSTARTTLSをサポートしていなかったことを示します。
o "certificate-host-mismatch": This indicates that the certificate presented did not adhere to the constraints specified in the MTA-STS or DANE policy, e.g., if the MX hostname does not match any identities listed in the subject alternative name (SAN) [RFC5280].
o 「certificate-host-mismatch」：これは、提示された証明書がMTA-STSまたはDANEポリシーで指定された制約に準拠していなかったことを示します。たとえば、MXホスト名がサブジェクトの別名（SAN）にリストされているIDと一致しない場合[RFC5280]。
o "certificate-expired": This indicates that the certificate has expired.
o 「certificate-expired」：証明書の有効期限が切れていることを示します。
o "certificate-not-trusted": This is a label that covers multiple certificate-related failures that include, but are not limited to, errors such as untrusted/unknown certification authorities (CAs), certificate name constraints, certificate chain errors, etc. When using this declaration, the reporting MTA SHOULD utilize the "failure-reason-code" to provide more information to the receiving entity.
o 「certificate-not-trusted」：これは、信頼されていない/不明な認証局（CA）、証明書名の制約、証明書チェーンエラーなどのエラーを含む（ただしこれらに限定されない）複数の証明書関連の障害をカバーするラベルです。この宣言を使用する場合、レポートMTAは「failure-reason-code」を使用して、受信エンティティに詳細情報を提供する必要があります（SHOULD）。
o "validation-failure": This indicates a general failure for a reason not matching a category above. When using this declaration, the reporting MTA SHOULD utilize the "failure-reason-code" to provide more information to the receiving entity.
o 「検証失敗」：これは、上記のカテゴリと一致しない理由による一般的な失敗を示します。この宣言を使用する場合、レポートMTAは「failure-reason-code」を使用して、受信エンティティに詳細情報を提供する必要があります（SHOULD）。
o "tlsa-invalid": This indicates a validation error in the TLSA record associated with a DANE policy. None of the records in the RRset were found to be valid.
o 「tlsa-invalid」：これは、DANEポリシーに関連付けられたTLSAレコードの検証エラーを示します。 RRset内のどのレコードも有効ではありませんでした。
o "dnssec-invalid": This indicates that no valid records were returned from the recursive resolver.
o 「dnssec-invalid」：これは、再帰リゾルバから有効なレコードが返されなかったことを示します。
o "dane-required": This indicates that the sending system is configured to require DANE TLSA records for all the MX hosts of the destination domain, but no DNSSEC-validated TLSA records were present for the MX host that is the subject of the report. Mandatory DANE for SMTP is described in Section 6 of [RFC7672]. Such policies may be created by mutual agreement between two organizations that frequently exchange sensitive content via email.
o 「dane-required」：これは、送信システムが宛先ドメインのすべてのMXホストにDANE TLSAレコードを要求するように構成されているが、レポートの対象であるMXホストにDNSSEC検証済みのTLSAレコードが存在しなかったことを示します。 SMTPの必須DANEは、[RFC7672]のセクション6で説明されています。このようなポリシーは、電子メールを介して機密コンテンツを頻繁に交換する2つの組織間の相互合意によって作成される場合があります。
o "sts-policy-fetch-error": This indicates a failure to retrieve an MTA-STS policy, for example, because the policy host is unreachable.
o "sts-policy-fetch-error"：これは、たとえば、ポリシーホストに到達できないために、MTA-STSポリシーを取得できなかったことを示します。
o "sts-policy-invalid": This indicates a validation error for the overall MTA-STS Policy.
o "sts-policy-invalid"：これは、MTA-STSポリシー全体の検証エラーを示します。
o "sts-webpki-invalid": This indicates that the MTA-STS Policy could not be authenticated using PKIX validation.
o "sts-webpki-invalid"：これは、MTA-STSポリシーがPKIX検証を使用して認証できなかったことを示します。
When a negotiation failure cannot be categorized into one of the "Negotiation Failures" stated above, the reporter SHOULD use the "validation-failure" category. As TLS grows and becomes more complex, new mechanisms may not be easily categorized. This allows for a generic feedback category. When this category is used, the reporter SHOULD also use "failure-reason-code" to give some feedback to the receiving entity. This is intended to be a short text field, and the contents of the field should be an error code or error text, such as "X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION".
交渉の失敗が上記の「交渉の失敗」のいずれかに分類できない場合、レポーターは「検証失敗」カテゴリを使用する必要があります。 TLSが成長し、より複雑になると、新しいメカニズムを簡単に分類できない場合があります。これにより、一般的なフィードバックカテゴリが可能になります。このカテゴリが使用される場合、レポーターは「failure-reason-code」も使用して受信エンティティにフィードバックを提供する必要があります（SHOULD）。これは短いテキストフィールドであることが意図されており、フィールドの内容は、エラーコードまたはエラーテキスト（「X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION」など）である必要があります。
Transient errors due to too-busy networks, TCP timeouts, etc., are not required to be reported.
ビジー状態のネットワーク、TCPタイムアウトなどによる一時的なエラーは、報告する必要はありません。
The JSON schema is derived from the HTTP Public Key Pinning (HPKP) JSON schema; see Section 3 of [RFC7469].
JSONスキーマは、HTTP公開鍵ピンニング（HPKP）JSONスキーマから派生しています。 [RFC7469]のセクション3をご覧ください。
{
"organization-name": organization-name,
"date-range": {
"start-datetime": date-time,
"end-datetime": date-time
},
"contact-info": email-address,
"report-id": report-id,
"policies": [{
"policy": {
"policy-type": policy-type,
"policy-string": policy-string,
"policy-domain": domain,
"mx-host": mx-host-pattern
},
"summary": {
"total-successful-session-count": total-successful-session-count,
"total-failure-session-count": total-failure-session-count
},
"failure-details": [
{
"result-type": result-type,
"sending-mta-ip": ip-address,
"receiving-mx-hostname": receiving-mx-hostname,
"receiving-mx-helo": receiving-mx-helo,
"receiving-ip": receiving-ip,
"failed-session-count": failed-session-count,
"additional-information": additional-info-uri,
"failure-reason-code": failure-reason-code
}
]
}
]
}
JSON Report Format
JSONレポート形式
o "organization-name": The name of the organization responsible for the report. It is provided as a string.
o "organization-name"：レポートを担当する組織の名前。文字列として提供されます。
o "date-time": The date-time indicates the start and end times for the report range. It is provided as a string formatted according to "Internet Date/Time Format", Section 5.6 of [RFC3339]. The report should be for a full UTC day, 00:00-24:00.
o 「date-time」：日時は、レポート範囲の開始時間と終了時間を示します。 [インターネット日付/時刻形式]、[RFC3339]のセクション5.6に従ってフォーマットされた文字列として提供されます。レポートは、UTCの1日全体で、00：00から24:00です。
o "email-address": The contact information for the party responsible for the report. It is provided as a string formatted according to "Addr-Spec Specification", Section 3.4.1 of [RFC5322].
o 「メールアドレス」：レポートの責任者の連絡先情報。 [RFC5322]のセクション3.4.1の「Addr-Spec Specification」に従ってフォーマットされた文字列として提供されます。
o "report-id": A unique identifier for the report. Report authors may use whatever scheme they prefer to generate a unique identifier. It is provided as a string.
o "report-id"：レポートの一意の識別子。レポートの作成者は、一意の識別子を生成するために好む方法を使用できます。文字列として提供されます。
o "policy-type": The type of policy that was applied by the sending domain. Presently, the only three valid choices are "tlsa", "sts", and the literal string "no-policy-found". It is provided as a string.
o 「policy-type」：送信ドメインによって適用されたポリシーのタイプ。現在、有効な選択肢は「tlsa」、「sts」、およびリテラル文字列「no-policy-found」の3つだけです。文字列として提供されます。
o "policy-string": An encoding of the applied policy as a JSON array of strings, whether it's a TLSA record ([RFC6698], Section 2.3) or an MTA-STS Policy. Examples follow in the next section.
o 「policy-string」：TLSAレコード（[RFC6698]、セクション2.3）でもMTA-STSポリシーでも、適用されたポリシーの文字列のJSON配列としてのエンコーディング。次のセクションで例を示します。
o "domain": The Policy Domain against which the MTA-STS or DANE policy is defined. In the case of Internationalized Domain Names [RFC5891], the domain MUST consist of the Punycode-encoded A-labels [RFC3492] and not the U-labels.
o 「ドメイン」：MTA-STSまたはDANEポリシーが定義されているポリシードメイン。国際化ドメイン名[RFC5891]の場合、ドメインは、UラベルではなくPunycodeでエンコードされたAラベル[RFC3492]で構成する必要があります。
o "mx-host-pattern": In the case where "policy-type" is "sts", it's the pattern of MX hostnames from the applied policy. It is provided as a JSON array of strings and is interpreted in the same manner as the rules in "MX Host Validation"; see Section 4.1 of [RFC8461]. In the case of Internationalized Domain Names [RFC5891], the domain MUST consist of the Punycode-encoded A-labels [RFC3492] and not the U-labels.
o 「mx-host-pattern」：「policy-type」が「sts」の場合、適用されたポリシーからのMXホスト名のパターンです。文字列のJSON配列として提供され、「MXホスト検証」のルールと同じ方法で解釈されます。 [RFC8461]のセクション4.1をご覧ください。国際化ドメイン名[RFC5891]の場合、ドメインは、UラベルではなくPunycodeでエンコードされたAラベル[RFC3492]で構成する必要があります。
o "result-type": A value from Section 4.3, "Result Types", above.
o "result-type"：上記の4.3「結果タイプ」の値。
o "ip-address": The IP address of the Sending MTA that attempted the STARTTLS connection. It is provided as a string representation of an IPv4 (see below) or IPv6 [RFC5952] address in dot-decimal or colon-hexadecimal notation.
o "ip-address"：STARTTLS接続を試みた送信MTAのIPアドレス。これは、IPv4（下記参照）またはIPv6 [RFC5952]アドレスの文字列表現として、ドット10進またはコロン16進表記で提供されます。
o "receiving-mx-hostname": The hostname of the receiving MTA MX record with which the Sending MTA attempted to negotiate a STARTTLS connection.
o "receiveing-mx-hostname"：送信側MTAがSTARTTLS接続のネゴシエートを試みた受信側MTA MXレコードのホスト名。
o "receiving-mx-helo" (optional): The HELLO (HELO) or Extended HELLO (EHLO) string from the banner announced during the reported session.
o "receiveing-mx-helo"（オプション）：レポートされたセッション中にアナウンスされたバナーからのHELLO（HELO）または拡張HELLO（EHLO）文字列。
o "receiving-ip": The destination IP address that was used when creating the outbound session. It is provided as a string representation of an IPv4 (see below) or IPv6 [RFC5952] address in dot-decimal or colon-hexadecimal notation.
o "receiveing-ip"：アウトバウンドセッションの作成時に使用された宛先IPアドレス。これは、IPv4（下記参照）またはIPv6 [RFC5952]アドレスの文字列表現として、ドット10進またはコロン16進表記で提供されます。
o "total-successful-session-count": The aggregate count (an integer, encoded as a JSON number) of successfully negotiated TLS-enabled connections to the receiving site.
o "total-successful-session-count"：受信サイトへのTLS対応接続のネゴシエーションに成功した総数（整数、JSON番号としてエンコード）。
o "total-failure-session-count": The aggregate count (an integer, encoded as a JSON number) of failures to negotiate a TLS-enabled connection to the receiving site.
o "total-failure-session-count"：受信サイトへのTLS対応接続のネゴシエーションに失敗した回数の合計（JSON番号としてエンコードされた整数）。
o "failed-session-count": The number of (attempted) sessions that match the relevant "result-type" for this section (an integer, encoded as a JSON number).
o "failed-session-count"：このセクションの関連する "result-type"に一致する（試行された）セッションの数（JSON番号としてエンコードされた整数）。
o "additional-info-uri" (optional): A URI [RFC3986] that points to additional information around the relevant "result-type". For example, this URI might host the complete certificate chain presented during an attempted STARTTLS session.
o 「additional-info-uri」（オプション）：関連する「result-type」に関する追加情報を指すURI [RFC3986]。たとえば、このURIは、試行されたSTARTTLSセッション中に提示された完全な証明書チェーンをホストする場合があります。
o "failure-reason-code": A text field to include a TLS-related error code or error message.
o "failure-reason-code"：TLS関連のエラーコードまたはエラーメッセージを含めるテキストフィールド。
For report purposes, an IPv4 address is defined via the following ABNF:
レポートのために、IPv4アドレスは次のABNFを介して定義されます。
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
And an IPv6 address is defined via the following ABNF:
また、IPv6アドレスは次のABNFを介して定義されます。
IPv6address = <as defined in [RFC5954]>
Part of the report body includes the policy that is applied when attempting relay to the destination.
レポート本文の一部には、宛先へのリレーを試行するときに適用されるポリシーが含まれています。
For DANE TLSA policies, this is a JSON array of strings each representing the RDATA of a single TLSA resource record as a space-separated list of its four TLSA fields; the fields are in presentation format (defined in [RFC6698], Section 2.2) with no internal spaces or grouping parentheses:
DANE TLSAポリシーの場合、これは、それぞれが単一のTLSAリソースレコードのRDATAを、4つのTLSAフィールドのスペース区切りリストとして表す文字列のJSON配列です。フィールドはプレゼンテーション形式（[RFC6698]、セクション2.2で定義）であり、内部スペースまたはグループ化括弧はありません。
[ "3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513 D747D1D085D", "3 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513 D747D1D1234" ]
[「3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513 D747D1D085D」、「3 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8E8513」DEC8513
For MTA-STS policies, this is an array of JSON strings that represents the policy that is declared by the receiving site, including any errors that may be present. Note that where there are multiple "mx" values, they must be listed as separate "mx" elements in the policy array rather than as a single nested "mx" sub-array.
MTA-STSポリシーの場合、これは、存在する可能性のあるエラーを含む、受信サイトによって宣言されたポリシーを表すJSON文字列の配列です。複数の「mx」値がある場合、それらは単一のネストされた「mx」サブ配列としてではなく、ポリシー配列内の個別の「mx」要素としてリストする必要があることに注意してください。
[ "version: STSv1", "mode: testing", "mx: mx1.example.com", "mx: mx2.example.com", "mx: mx.backup-example.com", "max_age: 604800" ]
["バージョン：STSv1"、 "モード：テスト"、 "mx：mx1.example.com"、 "mx：mx2.example.com"、 "mx：mx.backup-example.com"、 "max_age：604800" ]
Reports can be delivered either via SMTP (as an email message) or via HTTP POST.
レポートは、SMTP（電子メールメッセージとして）またはHTTP POSTを介して配信できます。
The filename is RECOMMENDED to be constructed using the following ABNF:
ファイル名は、次のABNFを使用して作成することをお勧めします。
filename = sender "!" policy-domain "!" begin-timestamp
"!" end-timestamp [ "!" unique-id ] "." extension
unique-id = 1*(ALPHA / DIGIT)
sender = domain ; from [RFC5321] -- this is used
; as the domain for the `contact-info`
; address in the report body.
; In the case of Internationalized Domain
; Names [RFC5891], the domain MUST consist of
; the Punycode-encoded A-labels [RFC3492] and
; not the U-labels.
policy-domain = domain
; In the case of Internationalized Domain
; Names [RFC5891], the domain MUST consist of
; the Punycode-encoded A-labels [RFC3492] and
; not the U-labels.
begin-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating start of the time range contained
; in the report
end-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained
; in the report
extension = "json" / "json.gz"
The extension MUST be "json" for a plain JSON file or "json.gz" for a JSON file compressed using gzip.
拡張子は、プレーンなJSONファイルの場合は「json」、gzipを使用して圧縮されたJSONファイルの場合は「json.gz」でなければなりません。
"unique-id" allows an optional unique ID generated by the Sending MTA to distinguish among multiple reports generated simultaneously by different sources for the same Policy Domain. For example, this is a possible filename for a compressed report to the Policy Domain "example.net" from the Sending MTA "mail.sndr.example.com":
「unique-id」を使用すると、送信側MTAによって生成されるオプションの一意のIDで、同じポリシードメインの異なるソースによって同時に生成された複数のレポートを区別できます。たとえば、これは送信MTA「mail.sndr.example.com」からポリシードメイン「example.net」への圧縮レポートの可能なファイル名です。
"mail.sndr.example.com!example.net!1470013207!1470186007!001.json.gz"
The report SHOULD be subjected to gzip [RFC1952] compression for both email and HTTPS transport. Declining to apply compression can cause the report to be too large for a receiver to process (a commonly observed receiver limit is ten megabytes); compressing the file increases the chances of acceptance of the report at some computational cost.
レポートは、電子メールとHTTPSトランスポートの両方でgzip [RFC1952]圧縮を受ける必要があります（SHOULD）。圧縮の適用を拒否すると、レポートが大きくなりすぎて受信者が処理できなくなる場合があります（一般的に観察される受信者の制限は10メガバイトです）。ファイルを圧縮すると、一部の計算コストでレポートを受け入れる可能性が高くなります。
The report MAY be delivered by email. To make the reports machine-parsable for the receivers, we define a top-level media type "multipart/report" with a new parameter "report-type="tlsrpt"". Inside it, there are two parts: The first part is human readable, typically "text/plain", and the second part is machine readable with a new media type defined called "application/tlsrpt+json". If compressed, the report should use the media type "application/ tlsrpt+gzip".
レポートはメールで配信される場合があります。レポートをレシーバーで機械解析可能にするために、新しいパラメーター「report-type = "tlsrpt"」を使用してトップレベルのメディアタイプ「multipart / report」を定義します。その内部には2つの部分があります。最初の部分は人間が読める形式で、通常は「text / plain」です。2番目の部分は、「application / tlsrpt + json」と呼ばれる新しいメディアタイプが定義された機械可読です。圧縮されている場合、レポートはメディアタイプ「application / tlsrpt + gzip」を使用する必要があります。
In addition, the following two new top-level message header fields are defined:
さらに、次の2つの新しい最上位メッセージヘッダーフィールドが定義されています。
"TLS-Report-Domain: Receiver-Domain"
「TLS-Report-Domain：Receiver-Domain」
"TLS-Report-Submitter: Sender-Domain"
「TLSレポート送信者：送信者ドメイン」
The "TLS-Report-Submitter" value MUST match the value found in the domain [RFC5321] of the "contact-info" from the report body. These message header fields MUST be included and should allow for easy searching for all reports submitted by a reporting domain or a particular submitter, for example, in IMAP [RFC3501]:
「TLS-Report-Submitter」の値は、レポート本文の「contact-info」のドメイン[RFC5321]にある値と一致する必要があります。これらのメッセージヘッダーフィールドを含める必要があり、レポートドメインまたは特定の送信者から送信されたすべてのレポートを簡単に検索できるようにする必要があります。たとえば、IMAP [RFC3501]で次のようにします。
"s SEARCH HEADER "TLS-Report-Domain" "example.com""
"s SEARCH HEADER" TLS-Report-Domain "" example.com ""
It is presumed that the aggregate reporting address will be equipped to process new message header fields and extract MIME parts with the prescribed media type and filename, and ignore the rest. These additional headers SHOULD be included in the DKIM [RFC6376] signature for the message.
集約レポートアドレスは、新しいメッセージヘッダーフィールドを処理し、規定のメディアタイプとファイル名でMIME部分を抽出し、残りは無視するようになっていると想定されています。これらの追加ヘッダーは、メッセージのDKIM [RFC6376]署名に含める必要があります（SHOULD）。
The RFC5322.Subject field for report submissions SHOULD conform to the following ABNF:
レポート送信のRFC5322.Subjectフィールドは、次のABNFに準拠する必要があります（SHOULD）。
tlsrpt-subject = %s"Report" FWS ; "Report"
%s"Domain:" FWS ; "Domain:"
domain-name FWS ; per [RFC6376]
%s"Submitter:" FWS ; "Submitter:"
domain-name FWS ; per [RFC6376]
%s"Report-ID:" FWS ; "Report-ID:
"<" id-left "@" id-right ">" ; per [RFC5322]
[CFWS] ; per [RFC5322]
; (as with FWS)
The first domain-name indicates the DNS domain name about which the report was generated. The second domain-name indicates the DNS domain name representing the Sending MTA generating the report. The purpose of the "Report-ID:" portion of the field is to enable the Policy Domain to identify and ignore duplicate reports that might be sent by a Sending MTA.
最初のドメイン名は、レポートが生成されたDNSドメイン名を示します。 2番目のドメイン名は、レポートを生成する送信側MTAを表すDNSドメイン名を示します。フィールドの「Report-ID：」部分の目的は、ポリシードメインが送信側MTAによって送信される可能性のある重複レポートを識別して無視できるようにすることです。
For instance, this is a possible Subject field for a report to the Policy Domain "example.net" from the Sending MTA "mail.sender.example.com". It is line-wrapped as allowed by [RFC5322]:
たとえば、これは送信MTA「mail.sender.example.com」からポリシードメイン「example.net」へのレポートの可能なサブジェクトフィールドです。 [RFC5322]で許可されているとおりに行が折り返されます。
Subject: Report Domain: example.net
Submitter: mail.sender.example.com
Report-ID: <735ff.e317+bf22029@mailexample.net>
From: tlsrpt@mail.sender.example.com
Date: Fri, May 09 2017 16:54:30 -0800
To: mts-sts-tlsrpt@example.net
Subject: Report Domain: example.net
Submitter: mail.sender.example.com
Report-ID: <735ff.e317+bf22029@example.net>
TLS-Report-Domain: example.net
TLS-Report-Submitter: mail.sender.example.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type="tlsrpt";
boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00"
Content-Language: en-us
This is a multipart message in MIME format.
これはMIME形式のマルチパートメッセージです。
------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
This is an aggregate TLS report from mail.sender.example.com
これは、mail.sender.example.comからの集約TLSレポートです
------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: application/tlsrpt+gzip
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="mail.sender.example!example.com!
1013662812!1013749130.json.gz"
<gzipped content of report>
<レポートのgzip圧縮されたコンテンツ>
------=_NextPart_000_024E_01CC9B0A.AFE54C00--
...
Note that, when sending failure reports via SMTP, Sending MTAs MUST NOT honor MTA-STS or DANE TLSA failures.
SMTP経由で障害レポートを送信する場合、MTAを送信してもMTA-STSまたはDANE TLSAの障害を受け入れてはならないことに注意してください。
The report MAY be delivered by POST to HTTPS. If compressed, the report SHOULD use the media type "application/tlsrpt+gzip"; otherwise it SHOULD use the media type "application/tlsrpt+json" (see Section 6, "IANA Considerations").
レポートはPOSTによってHTTPSに配信される場合があります。圧縮されている場合、レポートはメディアタイプ「application / tlsrpt + gzip」を使用する必要があります。それ以外の場合は、メディアタイプ「application / tlsrpt + json」を使用する必要があります（セクション6「IANAに関する考慮事項」を参照）。
The receiving system MUST return a "successful" response from its HTTPS server, typically a 200 or 201 HTTP code [RFC7231]. Other codes could indicate a delivery failure and may be retried as per local sender policy. The receiving system is not expected to process reports at receipt time and MAY store them for processing at a later time.
受信側システムは、HTTPSサーバーから「成功した」応答、通常は200または201 HTTPコード[RFC7231]を返さなければなりません（MUST）。その他のコードは配信の失敗を示している可能性があり、ローカル送信者ポリシーに従って再試行される場合があります。受信システムは、受信時にレポートを処理することは想定されておらず、後で処理するためにそれらを保存してもよい（MAY）。
In the event of a delivery failure, regardless of the delivery method, a sender SHOULD attempt redelivery for up to 24 hours after the initial attempt. As previously stated, the reports are optional, so while it is ideal to attempt redelivery, it is not required. If multiple retries are attempted, ideally they SHOULD be done with exponential backoff.
配信が失敗した場合、配信方法に関係なく、送信者は最初の試行から最大24時間、再配信を試行する必要があります（SHOULD）。前述のように、レポートはオプションであるため、再配信を試みることが理想的ですが、必須ではありません。複数の再試行が試行される場合、理想的には、指数バックオフで実行する必要があります。
As stated above, there are a variable number of ways to declare information about the data therein. If any of the items declared via subject or filename disagree with the report, the report MUST be considered the authoritative source.
上記のように、その中のデータに関する情報を宣言する方法はさまざまです。件名またはファイル名を介して宣言された項目のいずれかがレポートに同意しない場合、レポートは信頼できる情報源と見なされなければなりません。
The following are the IANA considerations discussed in this document.
このドキュメントで説明されているIANAの考慮事項は次のとおりです。
Below is the Internet Assigned Numbers Authority (IANA) Permanent Message Header Field registration information per [RFC3864].
以下は、[RFC3864]によるInternet Assigned Numbers Authority（IANA）Permanent Message Header Fieldの登録情報です。
Header field name: TLS-Report-Domain
Applicable protocol: mail
Status: standard
Author/Change controller: IETF
Specification document(s): RFC 8460
Header field name: TLS-Report-Submitter
Applicable protocol: mail
Status: standard
Author/Change controller: IETF
Specification document(s): RFC 8460
This document creates a new registry for the "report-type" parameter to the Content-Type header field for the "multipart/report" top-level media type defined in [RFC6522].
このドキュメントは、[RFC6522]で定義されている "multipart / report"トップレベルメディアタイプのContent-Typeヘッダーフィールドへの "report-type"パラメータの新しいレジストリを作成します。
The registry name is "Report Type Registry", and the procedure for updating the registry will be "Specification Required" [RFC8126].
レジストリ名は「Report Type Registry」であり、レジストリの更新手順は「Specification Required」[RFC8126]となります。
An entry in this registry should contain:
このレジストリのエントリには、以下が含まれている必要があります。
o the report-type being registered
o 登録されているレポートタイプ
o one or more registered media types that can be used with this report-type
o このレポートタイプで使用できる1つ以上の登録済みメディアタイプ
o the document containing the registration action
o 登録アクションを含むドキュメント
o an optional comment
o オプションのコメント
The initial entries are:
最初のエントリは次のとおりです。
Report-Type: tlsrpt
Media Type: application/tlsrpt+gzip, application/tlsrpt+json
Registered By: [RFC8460]
Comment: Media types suitable for use with this report-type are
defined in Sections 6.4 and 6.5 of [RFC8460]
Report-Type: disposition-notification Media Type: message/disposition-notification Registered By: [RFC8098], Section 10
Report-Type：disposition-notification Media Type：message / disposition-notification Registered By：[RFC8098]、Section 10
Report-Type: disposition-notification Media Type: message/global-disposition-notification Registered By: [RFC6533], Section 6
Report-Type：disposition-notification Media Type：message / global-disposition-notification Registered By：[RFC6533]、Section 6
Report-Type: delivery-status Media Type: message/delivery-status Registered By: [RFC3464], Section 6.2
Report-Type：delivery-status Media Type：message / delivery-status Registered By：[RFC3464]、Section 6.2
Report-Type: delivery-status Media Type: message/global-delivery-status Registered By: [RFC6533], Section 6
Report-Type：delivery-status Media Type：message / global-delivery-status Registered By：[RFC6533]、Section 6
This document registers a new media type suffix "+gzip". The gzip format is a public domain, cross-platform, interoperable file storage and transfer format, specified in [RFC1952]; it supports compression and is used as the underlying representation by a variety of file formats. The media type "application/gzip" has been registered for such files. The suffix "+gzip" MAY be used with any media type whose representation follows that established for "application/gzip". The registration form for the structured syntax suffix for use with media types is as follows:
このドキュメントでは、新しいメディアタイプサフィックス「+ gzip」を登録しています。 gzip形式は、パブリックドメイン、クロスプラットフォーム、相互運用可能なファイルストレージおよび転送形式であり、[RFC1952]で指定されています。圧縮をサポートし、さまざまなファイル形式の基礎となる表現として使用されます。このようなファイルには、メディアタイプ「application / gzip」が登録されています。接尾辞「+ gzip」は、「application / gzip」用に確立されたものに従う表現に従う任意のメディアタイプで使用できます。メディアタイプで使用する構造化構文のサフィックスの登録フォームは次のとおりです。
Type name: gzip file storage and transfer format.
タイプ名：gzipファイルの保存と転送形式。
+suffix: +gzip
References: [RFC1952] [RFC6713]
参照：[RFC1952] [RFC6713]
Encoding considerations: gzip is a binary encoding.
エンコーディングに関する考慮事項：gzipはバイナリエンコーディングです。
Fragment identifier considerations: The syntax and semantics of fragment identifiers specified for +gzip SHOULD be as specified for "application/gzip". (At publication of this document, there is no fragment identification syntax defined for "application/gzip".) The syntax and semantics for fragment identifiers for a specific "xxx/ yyy+gzip" SHOULD be processed as follows:
フラグメント識別子の考慮事項：+ gzipに指定されたフラグメント識別子の構文とセマンティクスは、「application / gzip」に指定されたとおりである必要があります（SHOULD）。 （このドキュメントの公開時には、「application / gzip」に対して定義されたフラグメント識別構文はありません。）特定の「xxx / yyy + gzip」のフラグメント識別子の構文とセマンティクスは、次のように処理する必要があります。
For cases defined in +gzip, where the fragment identifier resolves per the +gzip rules, process as specified in +gzip.
+ gzipで定義されているケースで、フラグメント識別子が+ gzipルールに従って解決される場合は、+ gzipで指定されているとおりに処理します。
For cases defined in +gzip, where the fragment identifier does not resolve per the +gzip rules, process as specified in "xxx/yyy+gzip".
+ gzipで定義されているケースで、フラグメント識別子が+ gzipルールに従って解決されない場合は、「xxx / yyy + gzip」で指定されているように処理します。
For cases not defined in +gzip, process as specified in "xxx/yyy+gzip".
+ gzipで定義されていないケースの場合は、「xxx / yyy + gzip」で指定されているように処理します。
Interoperability considerations: N/A
相互運用性に関する考慮事項：N / A
Security considerations: gzip format doesn't provide confidentiality protection. Integrity protection is provided by an Adler-32 checksum, which is not cryptographically strong. See also the security considerations of [RFC6713]. Each individual media type registered with a +gzip suffix can have additional security considerations. Additionally, gzip objects can contain multiple files and associated paths. File paths must be validated when the files are extracted; a malicious file path could otherwise cause the extractor to overwrite application or system files.
セキュリティに関する考慮事項：gzip形式は機密保護を提供しません。完全性保護は、暗号的に強力ではないAdler-32チェックサムによって提供されます。 [RFC6713]のセキュリティに関する考慮事項も参照してください。 + gzipサフィックスで登録された個々のメディアタイプには、セキュリティに関する追加の考慮事項があります。さらに、gzipオブジェクトには複数のファイルと関連するパスを含めることができます。ファイルを抽出するときに、ファイルパスを検証する必要があります。悪意のあるファイルパスがあると、エクストラクターがアプリケーションまたはシステムファイルを上書きする可能性があります。
Contact: art@ietf.org
連絡先：art@ietf.org
Author/Change controller: Internet Engineering Task Force (iesg@ietf.org).
著者/変更管理者：Internet Engineering Task Force（iesg@ietf.org）。
This document registers multiple media types, beginning with Table 1 below.
このドキュメントでは、以下の表1から始まる複数のメディアタイプを登録しています。
+-------------+----------------+-------------+-------------------+
| Type | Subtype | File Ext | Specification |
+-------------+----------------+-------------+-------------------+
| application | tlsrpt+json | .json | Section 5.3 |
+-------------+----------------+-------------+-------------------+
Table 1: SMTP TLS Reporting Media Type
表1：SMTP TLSレポートメディアタイプ
Type name: application
タイプ名：アプリケーション
Subtype name: tlsrpt+json
サブタイプ名：tlsrpt + json
Required parameters: N/A
必須パラメーター：なし
Optional parameters: N/A
オプションのパラメーター：N / A
Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type. See [RFC7493].
エンコーディングの考慮事項：エンコーディングの考慮事項は、「application / json」メディアタイプに指定されたものと同じです。 [RFC7493]を参照してください。
Security considerations: Security considerations relating to SMTP TLS Reporting are discussed in Section 7.
セキュリティの考慮事項：SMTP TLSレポートに関連するセキュリティの考慮事項については、セクション7で説明します。
Interoperability considerations: This document specifies the format of conforming messages and the interpretation thereof.
相互運用性に関する考慮事項：このドキュメントでは、適合メッセージの形式とその解釈について説明します。
Published specification: Section 5.3 of RFC 8460.
公開された仕様：RFC 8460のセクション5.3。
Applications that use this media type: Mail User Agents (MUAs) and Mail Transfer Agents.
このメディアタイプを使用するアプリケーション：メールユーザーエージェント（MUA）およびメール転送エージェント。
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの非推奨のエイリアス名：N / A
Magic number(s): N/A
File extension(s): ".json"
ファイル拡張子： ".json"
Macintosh file type code(s): N/A
Person & email address to contact for further information: See the Authors' Addresses section.
詳細については、連絡先の個人と電子メールアドレス：作成者のアドレスセクションを参照してください。
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: N/A
使用上の制限：N / A
Author: See the Authors' Addresses section.
作成者：「作成者のアドレス」セクションを参照してください。
Change controller: Internet Engineering Task Force (iesg@ietf.org).
変更コントローラー：Internet Engineering Task Force（iesg@ietf.org）。
+-------------+----------------+-------------+-------------------+
| Type | Subtype | File Ext | Specification |
+-------------+----------------+-------------+-------------------+
| application | tlsrpt+gzip | .gz | Section 5.3 |
+-------------+----------------+-------------+-------------------+
Table 2: SMTP TLS Reporting Media Type
表2：SMTP TLSレポートメディアタイプ
Type name: application
タイプ名：アプリケーション
Subtype name: tlsrpt+gzip
サブタイプ名：tlsrpt + gzip
Required parameters: N/A
必須パラメーター：なし
Optional parameters: N/A
オプションのパラメーター：N / A
Encoding considerations: Binary
エンコードに関する考慮事項：バイナリ
Security considerations: Security considerations relating to SMTP TLS Reporting are discussed in Section 7. Security considerations related to gzip compression are discussed in RFC 6713.
セキュリティの考慮事項：SMTP TLSレポートに関連するセキュリティの考慮事項は、セクション7で説明されています。gzip圧縮に関連するセキュリティの考慮事項は、RFC 6713で説明されています。
Interoperability considerations: This document specifies the format of conforming messages and the interpretation thereof.
相互運用性に関する考慮事項：このドキュメントでは、適合メッセージの形式とその解釈について説明します。
Published specification: Section 5.3 of RFC 8460.
公開された仕様：RFC 8460のセクション5.3。
Applications that use this media type: Mail User Agents (MUAs) and Mail Transfer Agents.
このメディアタイプを使用するアプリケーション：メールユーザーエージェント（MUA）およびメール転送エージェント。
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの非推奨のエイリアス名：N / A
Magic number(s): The first two bytes are 0x1f, 0x8b.
マジックナンバー：最初の2バイトは0x1f、0x8bです。
File extension(s): ".gz"
ファイル拡張子： ".gz"
Macintosh file type code(s): N/A
Person & email address to contact for further information: See the Authors' Addresses section.
詳細については、連絡先の個人と電子メールアドレス：作成者のアドレスセクションを参照してください。
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: N/A
使用上の制限：N / A
Author: See the Authors' Addresses section.
作成者：「作成者のアドレス」セクションを参照してください。
Change controller: Internet Engineering Task Force (iesg@ietf.org).
変更コントローラー：Internet Engineering Task Force（iesg@ietf.org）。
This document creates a new registry, "STARTTLS Validation Result Types". The initial entries in the registry are:
このドキュメントは、新しいレジストリ「STARTTLS検証結果タイプ」を作成します。レジストリの最初のエントリは次のとおりです。
+-----------------------------+--------------+
| Result Type | Description |
+-----------------------------+--------------+
| starttls-not-supported | Section 4.3 |
| certificate-host-mismatch | Section 4.3 |
| certificate-expired | Section 4.3 |
| tlsa-invalid | Section 4.3 |
| dnssec-invalid | Section 4.3 |
| dane-required | Section 4.3 |
| certificate-not-trusted | Section 4.3 |
| sts-policy-invalid | Section 4.3 |
| sts-webpki-invalid | Section 4.3 |
| validation-failure | Section 4.3 |
| sts-policy-fetch-error | Section 4.3 |
+-----------------------------+--------------+
The above entries are described in Section 4.3, "Result Types". New result types can be added to this registry using the "Expert Review" IANA registration policy.
上記のエントリは、4.3項「結果タイプ」で説明されています。 「エキスパートレビュー」IANA登録ポリシーを使用して、新しい結果タイプをこのレジストリに追加できます。
SMTP TLS Reporting provides visibility into misconfigurations or attempts to intercept or tamper with mail between hosts who support STARTTLS. There are several security risks presented by the existence of this reporting channel:
SMTP TLSレポートは、構成の誤りを可視化したり、STARTTLSをサポートするホスト間のメールを傍受または改ざんしようとしたりする試みを提供します。このレポートチャネルの存在によって提示されるいくつかのセキュリティリスクがあります。
o Flooding of the Aggregate Report URI (rua) endpoint: An attacker could flood the endpoint with excessive reporting traffic and prevent the receiving domain from accepting additional reports. This type of Denial-of-Service attack would limit visibility into STARTTLS failures, leaving the receiving domain blind to an ongoing attack.
o 集約レポートURI（rua）エンドポイントのフラッディング：攻撃者は、過剰なレポートトラフィックでエンドポイントをフラッディングし、受信ドメインが追加のレポートを受け入れないようにする可能性があります。このタイプのサービス拒否攻撃は、STARTTLS障害の可視性を制限し、受信ドメインを進行中の攻撃から見えないようにします。
o Untrusted content: An attacker could inject malicious code into the report, exploiting any vulnerabilities in the report-handling systems of the receiving domain. Implementers are advised to take precautions against evaluating the contents of the report.
o 信頼できないコンテンツ：攻撃者は悪意のあるコードをレポートに挿入し、受信ドメインのレポート処理システムの脆弱性を悪用する可能性があります。実装者は、レポートの内容を評価しないように予防策を講じることをお勧めします。
o Report snooping: An attacker could create a bogus TLSRPT record to receive statistics about a domain the attacker does not own. Since an attacker that is able to poison DNS is already able to receive counts of SMTP connections (and, absent DANE or MTA-STS policies, actual SMTP message payloads), this does not present a significant new vulnerability.
o スヌーピングを報告する：攻撃者は偽のTLSRPTレコードを作成して、攻撃者が所有していないドメインに関する統計を受け取る可能性があります。 DNSを害する攻撃者は既にSMTP接続の数（およびDANEまたはMTA-STSポリシーがない場合、実際のSMTPメッセージペイロード）を受信できるため、これは重大な新しい脆弱性をもたらしません。
o Ignoring HTTPS validation when submitting reports: When reporting benign misconfigurations, it is likely that a misconfigured SMTP server may also mean a misconfigured HTTPS server; as a result, reporters who require HTTPS validity on the reporting endpoint may fail to alert administrators about such misconfigurations. Conversely, in the event of an actual attack, an attacker who wishes to create a gap in reporting and could intercept HTTPS reports could, just as easily, simply thwart the resolution of the TLSRPT TXT record or establishment of the TCP session to the HTTPS endpoint. Furthermore, such a man-in-the-middle attacker could discover most or all of the metadata exposed in a report merely through passive observation. As a result, we consider the risks of failure to deliver reports on misconfigurations to outweigh those of attackers intercepting reports.
o レポートの送信時にHTTPS検証を無視する：害のない構成の誤りを報告する場合、SMTPサーバーの構成の誤りはHTTPSサーバーの構成の誤りを意味している可能性があります。その結果、レポートエンドポイントでHTTPSの有効性を必要とするレポーターは、このような設定ミスについて管理者に警告できないことがあります。逆に、実際の攻撃が発生した場合、レポートにギャップを作り、HTTPSレポートを傍受できる攻撃者は、TLSRPT TXTレコードの解決またはHTTPSエンドポイントへのTCPセッションの確立を簡単に阻止できます。 。さらに、このような中間者攻撃者は、単に受動的な観察によって、レポートで公開されているメタデータのほとんどまたはすべてを発見する可能性があります。その結果、誤設定に関するレポートの配信に失敗した場合のリスクを考慮して、レポートを傍受する攻撃者のリスクを上回ります。
o Reports as DDoS: TLSRPT allows specifying destinations for the reports that are outside the authority of the Policy Domain, which allows domains to delegate processing of reports to a partner organization. However, an attacker who controls the Policy Domain DNS could also use this mechanism to direct the reports to an unwitting victim, flooding that victim with excessive reports. DMARC [RFC7489] defines a solution for verifying delegation to avoid such attacks; the need for this is greater with DMARC, however, because DMARC allows an attacker to trigger reports to a target from an innocent third party by sending mail to that third party (which triggers a report from the third party to the target). In the case of TLSRPT, the attacker would have to induce the third party to send mail to the attacker in order to trigger reports from the third party to the victim; this reduces the risk of such an attack and the need for a verification mechanism.
o DDoSとしてのレポート：TLSRPTでは、ポリシードメインの権限の範囲外であるレポートの宛先を指定できます。これにより、ドメインはレポートの処理をパートナー組織に委任できます。ただし、ポリシードメインDNSを制御する攻撃者は、このメカニズムを使用してレポートを無意識の被害者に送信し、被害者を過剰なレポートで溢れさせる可能性があります。 DMARC [RFC7489]は、そのような攻撃を回避するために委任を検証するためのソリューションを定義しています。ただし、DMARCの場合、DMARCでは攻撃者が無害なサードパーティにメールを送信することにより、ターゲットへのレポートをトリガーできるため、この必要性が高くなります（サードパーティからターゲットへのレポートをトリガーします）。 TLSRPTの場合、攻撃者は第三者から被害者へのレポートをトリガーするために、第三者に攻撃者にメールを送信するよう誘導する必要があります。これにより、このような攻撃のリスクと検証メカニズムの必要性が減少します。
Finally, because TLSRPT is intended to help administrators discover man-in-the-middle attacks against transport-layer encryption, including attacks designed to thwart negotiation of encrypted connections (by downgrading opportunistic encryption or, in the case of MTA-STS, preventing discovery of a new MTA-STS Policy), we must also consider the risk that an adversary who can induce such a downgrade attack can also prevent discovery of the TLSRPT TXT record (and thus prevent discovery of the successful downgrade attack). Administrators are thus encouraged to deploy TLSRPT TXT records with a large TTL (reducing the window for successful application of transient attacks against DNS resolution of the record) or to deploy DNSSEC on the deploying zone.
最後に、TLSRPTは、管理者がトランスポート層暗号化に対する中間者攻撃を発見できるようにすることを目的としているため、暗号化された接続のネゴシエーションを阻止する（日和見暗号化をダウングレードすることにより、またはMTA-STSの場合は発見を防ぐことにより）新しいMTA-STSポリシー）の場合、このようなダウングレード攻撃を誘発できる攻撃者がTLSRPT TXTレコードの発見を妨げる可能性がある（したがって、ダウングレード攻撃の成功を妨げる）リスクも考慮する必要があります。したがって、管理者は、大きなTTLを使用してTLSRPT TXTレコードを展開する（レコードのDNS解決に対する一時的な攻撃を成功させるためのウィンドウを減らす）か、展開ゾーンにDNSSECを展開することをお勧めします。
MTAs are generally considered public knowledge; however, the internals of how those MTAs are configured and the users of those MTAs may not be as public. It should be noted that providing a receiving site with information about TLS failures may reveal information about the sender's configuration or even information about the senders themselves. For example, sending a report may disclose what TLS implementation the sender uses, as the inability to negotiate a session may be a known incompatibility between two implementations. This may, indirectly, leak information on the reporter's operating system or even region, if, for example, a rare TLS implementation is popular among certain users or in certain locations.
MTAは一般に公開知識と見なされます。ただし、これらのMTAがどのように構成されているか、およびそれらのMTAのユーザーの内部は、それほど公開されていない場合があります。受信サイトにTLSの失敗に関する情報を提供すると、送信者の構成に関する情報や、送信者自体に関する情報が明らかになる場合があることに注意してください。たとえば、セッションをネゴシエートできないことが2つの実装間の既知の非互換性である可能性があるため、レポートを送信すると、送信者が使用するTLS実装が開示される場合があります。これは、たとえば、特定のユーザー間または特定の場所でまれなTLS実装が一般的である場合、レポーターのオペレーティングシステムまたは地域に関する情報を間接的にリークする可能性があります。
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, <https://www.rfc-editor.org/info/rfc1952>.
[RFC1952] Deutsch、P。、「GZIPファイル形式仕様バージョン4.3」、RFC 1952、DOI 10.17487 / RFC1952、1996年5月、<https://www.rfc-editor.org/info/rfc1952>。
[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。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3339] Klyne、G。およびC. Newman、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<https://www.rfc-editor.org/info/rfc3339 >。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, <https://www.rfc-editor.org/info/rfc3492>.
[RFC3492] Costello、A。、「Punycode：A Bootstring encoding for Unicode for Internationalized Domain Names in Applications（IDNA）」、RFC 3492、DOI 10.17487 / RFC3492、2003年3月、<https://www.rfc-editor.org / info / rfc3492>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：/ /www.rfc-editor.org/info/rfc3986>。
[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]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<https://www.rfc-editor.org/info/rfc5321>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<https://www.rfc-editor.org/info/rfc5322>。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、DOI 10.17487 / RFC5891、2010年8月、<https://www.rfc-editor.org/info/rfc5891>。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.
[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、DOI 10.17487 / RFC5952、August 2010、<https://www.rfc-editor.org/info/rfc5952> 。
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, <https://www.rfc-editor.org/info/rfc6068>.
[RFC6068] Duerst、M.、Masinter、L。、およびJ. Zawinski、「The 'mailto' URI Scheme」、RFC 6068、DOI 10.17487 / RFC6068、2010年10月、<https://www.rfc-editor.org / info / rfc6068>。
[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。、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>。
[RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages", STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, <https://www.rfc-editor.org/info/rfc6522>.
[RFC6522] Kucherawy、M。、編、「メールシステム管理メッセージのレポート用のマルチパート/レポートメディアタイプ」、STD 73、RFC 6522、DOI 10.17487 / RFC6522、2012年1月、<https：//www.rfc -editor.org/info/rfc6522>。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6698] Hoffman、P。およびJ. Schlyter、「DNSベースの名前付きエンティティ（DANE）トランスポート層セキュリティ（TLS）プロトコルの認証：TLSA」、RFC 6698、DOI 10.17487 / RFC6698、2012年8月、<https：/ /www.rfc-editor.org/info/rfc6698>。
[RFC6713] Levine, J., "The 'application/zlib' and 'application/gzip' Media Types", RFC 6713, DOI 10.17487/RFC6713, August 2012, <https://www.rfc-editor.org/info/rfc6713>.
[RFC6713] Levine、J。、「「application / zlib」および「application / gzip」メディアタイプ」、RFC 6713、DOI 10.17487 / RFC6713、2012年8月、<https://www.rfc-editor.org/info / rfc6713>。
[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.、「電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク（SPF）、バージョン1」、RFC 7208、DOI 10.17487 / RFC7208、2014年4月、<https://www.rfc-editor.org / info / rfc7208>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231 >。
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.
[RFC7405] Kyzivat、P。、「ABNFでの大文字と小文字を区別する文字列のサポート」、RFC 7405、DOI 10.17487 / RFC7405、2014年12月、<https://www.rfc-editor.org/info/rfc7405>。
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/rfc7493>.
[RFC7493]ブレイ、T。、編、「The I-JSON Message Format」、RFC 7493、DOI 10.17487 / RFC7493、2015年3月、<https://www.rfc-editor.org/info/rfc7493>。
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <https://www.rfc-editor.org/info/rfc7671>.
[RFC7671] Dukhovni、V。およびW. Hardaker、「DNSベースの名前付きエンティティの認証（DANE）プロトコル：更新および運用ガイダンス」、RFC 7671、DOI 10.17487 / RFC7671、2015年10月、<https：// www。 rfc-editor.org/info/rfc7671>。
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10.17487/RFC7672, October 2015, <https://www.rfc-editor.org/info/rfc7672>.
[RFC7672] Dukhovni、V。およびW. Hardaker、「名前付きエンティティの便宜的DNSベース認証（DANE）トランスポート層セキュリティ（TLS）によるSMTPセキュリティ」、RFC 7672、DOI 10.17487 / RFC7672、2015年10月、<https：/ /www.rfc-editor.org/info/rfc7672>。
[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>。
[RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA-STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, <https://www.rfc-editor.org/info/rfc8461>.
[RFC8461]マーゴリス、D。、リシャー、M。、ラマクリシュナン、B。、ブロトマン、A.、J。ジョーンズ、「SMTP MTA Strict Transport Security（MTA-STS）」、RFC 8461、DOI 10.17487 / RFC8461、9月2018年、<https://www.rfc-editor.org/info/rfc8461>。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[RFC3207] Hoffman、P。、「トランスポート層セキュリティを介したセキュアSMTPのためのSMTPサービス拡張」、RFC 3207、DOI 10.17487 / RFC3207、2002年2月、<https://www.rfc-editor.org/info/rfc3207>。
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, January 2003, <https://www.rfc-editor.org/info/rfc3464>.
[RFC3464] Moore、K。およびG. Vaudreuil、 "An Extensible Message Format for Delivery Status Notifications"、RFC 3464、DOI 10.17487 / RFC3464、2003年1月、<https://www.rfc-editor.org/info/rfc3464 >。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/info/rfc3501>.
[RFC3501] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、DOI 10.17487 / RFC3501、2003年3月、<https://www.rfc-editor.org/info/rfc3501>。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <https://www.rfc-editor.org/info/rfc3864>.
[RFC3864] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、DOI 10.17487 / RFC3864、2004年9月、<https：//www.rfc- editor.org/info/rfc3864>。
[RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, DOI 10.17487/RFC6533, February 2012, <https://www.rfc-editor.org/info/rfc6533>.
[RFC6533] Hansen、T。、編、Newman、C。、およびA. Melnikov、「Internationalized Delivery Status and Disposition Notifications」、RFC 6533、DOI 10.17487 / RFC6533、2012年2月、<https：//www.rfc- editor.org/info/rfc6533>。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V。、「日和見セキュリティ：ほとんどの場合はある程度の保護」、RFC 7435、DOI 10.17487 / RFC7435、2014年12月、<https://www.rfc-editor.org/info/rfc7435>。
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <https://www.rfc-editor.org/info/rfc7469>.
[RFC7469] Evans、C.、Palmer、C。、およびR. Sleevi、「HTTPの公開キー固定拡張機能」、RFC 7469、DOI 10.17487 / RFC7469、2015年4月、<https://www.rfc-editor.org / info / rfc7469>。
[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、編、「ドメインベースのメッセージ認証、レポート、および準拠（DMARC）」、RFC 7489、DOI 10.17487 / RFC7489、2015年3月、<https://www.rfc-editor.org/info/ rfc7489>。
[RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, February 2017, <https://www.rfc-editor.org/info/rfc8098>.
[RFC8098]ハンセン、T。、エド。およびA. Melnikov編、「Message Disposition Notification」、STD 85、RFC 8098、DOI 10.17487 / RFC8098、2017年2月、<https://www.rfc-editor.org/info/rfc8098>。
[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。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
_smtp._tls.mail.example.com. IN TXT \
"v=TLSRPTv1;rua=mailto:reports@example.com"
_smtp._tls.mail.example.com. IN TXT \
"v=TLSRPTv1; \
rua=https://reporting.example.com/v1/tlsrpt"
Below is an example JSON report for messages from Company-X to Company-Y, where 100 sessions were attempted to Company-Y servers with an expired certificate, and 200 sessions were attempted to Company-Y servers that did not successfully respond to the "STARTTLS" command. Additionally, 3 sessions failed due to "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".
以下は、Company-XからCompany-YへのメッセージのJSONレポートの例です。100個のセッションが有効期限が切れた証明書を使用してCompany-Yサーバーに試行され、200個のセッションがCompany-Yサーバーに試行され、「 STARTTLS」コマンド。さらに、「X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED」が原因で3つのセッションが失敗しました。
{
"organization-name": "Company-X",
"date-range": {
"start-datetime": "2016-04-01T00:00:00Z",
"end-datetime": "2016-04-01T23:59:59Z"
},
"contact-info": "sts-reporting@company-x.example",
"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
"policies": [{
"policy": {
"policy-type": "sts",
"policy-string": ["version: STSv1","mode: testing",
"mx: *.mail.company-y.example","max_age: 86400"],
"policy-domain": "company-y.example",
"mx-host": "*.mail.company-y.example"
},
"summary": {
"total-successful-session-count": 5326,
"total-failure-session-count": 303
},
"failure-details": [{
"result-type": "certificate-expired",
"sending-mta-ip": "2001:db8:abcd:0012::1",
"receiving-mx-hostname": "mx1.mail.company-y.example",
"failed-session-count": 100
}, {
"result-type": "starttls-not-supported",
"sending-mta-ip": "2001:db8:abcd:0013::1",
"receiving-mx-hostname": "mx2.mail.company-y.example",
"receiving-ip": "203.0.113.56",
"failed-session-count": 200,
"additional-information": "https://reports.company-x.example/
report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported "
}, {
"result-type": "validation-failure",
"sending-mta-ip": "198.51.100.62",
"receiving-ip": "203.0.113.58",
"receiving-mx-hostname": "mx-backup.mail.company-y.example",
"failed-session-count": 3,
"failure-reason-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"
}]
}]
}
Contributors
貢献者
Laetitia Baudoin Google, Inc. lbaudoin@google.com
Laetitia Baudoin Google、Inc. lbaudoin@google.com
Authors' Addresses
著者のアドレス
Daniel Margolis Google, Inc.
ダニエルマーゴリスGoogle、Inc.
Email: dmargolis@google.com
Alexander Brotman Comcast, Inc.
Alexander Brotman Comcast、Inc.
Email: alex_brotman@comcast.com
Binu Ramakrishnan Oath, Inc.
Binu Ramakrishnan Oath、Inc.
Email: prbinu@yahoo.com
Janet Jones Microsoft, Inc.
Janet Jones Microsoft、Inc.
Email: janet.jones@microsoft.com
Mark Risher Google, Inc.
Mark Risher Google, Inc.
Email: risher@google.com