doc: Add RFC documents

1 files changed, 1907 insertions, 0 deletions

diff --git a/doc/rfc/rfc8460.txt b/doc/rfc/rfc8460.txt
new file mode 100644
index 0000000..be3bc46
--- /dev/null
+++ b/doc/rfc/rfc8460.txt
@@ -0,0 +1,1907 @@
+
+
+
+
+
+
+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
+
+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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                    [Page 1]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+Copyright Notice
+
+   Copyright (c) 2018 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                    [Page 2]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+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
+
+
+
+
+Margolis, et al.             Standards Track                    [Page 3]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+1.  Introduction
+
+   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).
+
+   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.
+
+   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.
+
+   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.
+
+   This document is intended as a companion to the specification for
+   SMTP MTA-STS [RFC8461] and adds reporting abilities for those
+   implementing DANE [RFC7672].
+
+1.1.  Terminology
+
+   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.
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                    [Page 4]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   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  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  TLSRPT (TLS Reporting) Policy: A policy specifying the endpoint to
+      which Sending MTAs should deliver reports.
+
+   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  Sending MTA: The MTA initiating the relay of an email message.
+
+   o  Aggregate Report URI (rua): A comma-separated list of locations
+      where the report is to be submitted.
+
+   o  ABNF: Augmented Backus-Naur Form, a syntax for formally specifying
+      syntax, defined in [RFC5234] and [RFC7405].
+
+2.  Related Technologies
+
+   o  This document is intended as a companion to the specification for
+      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].
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                    [Page 5]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+3.  Reporting Policy
+
+   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".
+
+   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  "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  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  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.
+
+   Sample DKIM record:
+
+      dkim_selector._domainkey.example.com TXT
+            "v=DKIM1;k=rsa;s=tlsrpt;p=Mlf4qwSZfase4fa=="
+
+
+
+Margolis, et al.             Standards Track                    [Page 6]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   The formal definition of the "_smtp._tls" TXT record, defined using
+   [RFC5234] and [RFC7405], is as follows:
+
+        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-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-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.
+
+   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.
+
+
+
+
+
+Margolis, et al.             Standards Track                    [Page 7]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   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.
+
+3.1.  Example Reporting Policy
+
+3.1.1.  Report Using MAILTO
+
+            _smtp._tls.example.com. IN TXT \
+                    "v=TLSRPTv1;rua=mailto:reports@example.com"
+
+3.1.2.  Report Using HTTPS
+
+           _smtp._tls.example.com. IN TXT \
+                   "v=TLSRPTv1; \
+                   rua=https://reporting.example.com/v1/tlsrpt"
+
+4.  Reporting Schema
+
+   The report is composed as a plaintext file encoded in the Internet
+   JSON (I-JSON) format [RFC7493].
+
+   Aggregate reports contain the following fields:
+
+   o  Report metadata:
+
+      *  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:
+
+      *  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.
+
+      *  The domain for which the policy is applied
+
+      *  The MX host
+
+
+
+
+Margolis, et al.             Standards Track                    [Page 8]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   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.
+
+   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.
+
+   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.
+
+4.1.  Report Time Frame
+
+   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.
+
+   As an example, a sending site might want to introduce a random delay
+   of up to four hours:
+
+          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)
+            }
+          }
+
+
+
+
+
+
+Margolis, et al.             Standards Track                    [Page 9]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+4.2.  Delivery Summary
+
+4.2.1.  Success Count
+
+   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.
+
+4.2.2.  Failure Count
+
+   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.
+
+4.3.  Result Types
+
+   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.  Negotiation Failures
+
+   o  "starttls-not-supported": This indicates that the recipient MX did
+      not support 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-expired": This indicates that the certificate has
+      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.
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 10]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   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.
+
+4.3.2.  Policy Failures
+
+4.3.2.1.  DANE-Specific Policy Failures
+
+   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  "dnssec-invalid": This indicates that no valid records were
+      returned from the recursive resolver.
+
+   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.
+
+4.3.2.2.  MTA-STS-specific Policy Failures
+
+   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-invalid": This indicates a validation error for the
+      overall MTA-STS Policy.
+
+   o  "sts-webpki-invalid": This indicates that the MTA-STS Policy could
+      not be authenticated using PKIX validation.
+
+4.3.3.  General Failures
+
+   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".
+
+
+
+Margolis, et al.             Standards Track                   [Page 11]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+4.3.4.  Transient Failures
+
+   Transient errors due to too-busy networks, TCP timeouts, etc., are
+   not required to be reported.
+
+4.4.  JSON Report Schema
+
+   The JSON schema is derived from the HTTP Public Key Pinning (HPKP)
+   JSON schema; see Section 3 of [RFC7469].
+
+ {
+   "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
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 12]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   o  "organization-name": The name of the organization responsible for
+      the report.  It is provided as a string.
+
+   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  "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  "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  "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-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  "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  "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  "result-type": A value from Section 4.3, "Result Types", above.
+
+   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  "receiving-mx-hostname": The hostname of the receiving MTA MX
+      record with which the Sending MTA attempted to negotiate a
+      STARTTLS connection.
+
+
+
+Margolis, et al.             Standards Track                   [Page 13]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   o  "receiving-mx-helo" (optional): The HELLO (HELO) or Extended HELLO
+      (EHLO) string from the banner announced during the reported
+      session.
+
+   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  "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-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  "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  "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  "failure-reason-code": A text field to include a TLS-related error
+      code or error message.
+
+   For report purposes, an IPv4 address is defined via the following
+   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:
+
+
+     IPv6address = <as defined in [RFC5954]>
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 14]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+4.5.  Policy Samples
+
+   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:
+
+       [
+       "3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513
+              D747D1D085D",
+       "3 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513
+              D747D1D1234"
+       ]
+
+   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.
+
+                       [
+                       "version: STSv1",
+                       "mode: testing",
+                       "mx: mx1.example.com",
+                       "mx: mx2.example.com",
+                       "mx: mx.backup-example.com",
+                       "max_age: 604800"
+                       ]
+
+5.  Report Delivery
+
+   Reports can be delivered either via SMTP (as an email message) or via
+   HTTP POST.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 15]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+5.1.  Report Filename
+
+   The filename is RECOMMENDED to be constructed using the following
+   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.
+
+   "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":
+
+   "mail.sndr.example.com!example.net!1470013207!1470186007!001.json.gz"
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 16]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+5.2.  Compression
+
+   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.
+
+5.3.  Email Transport
+
+   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".
+
+   In addition, the following two new top-level message header fields
+   are defined:
+
+   "TLS-Report-Domain: Receiver-Domain"
+
+   "TLS-Report-Submitter: Sender-Domain"
+
+   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]:
+
+   "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.
+
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 17]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   The RFC5322.Subject field for report submissions SHOULD conform to
+   the following ABNF:
+
+       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.
+
+   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]:
+
+              Subject: Report Domain: example.net
+                  Submitter: mail.sender.example.com
+                  Report-ID: <735ff.e317+bf22029@mailexample.net>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 18]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+5.3.1.  Example Report
+
+      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.
+
+          ------=_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
+
+          ------=_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>
+
+     ------=_NextPart_000_024E_01CC9B0A.AFE54C00--
+     ...
+
+   Note that, when sending failure reports via SMTP, Sending MTAs MUST
+   NOT honor MTA-STS or DANE TLSA failures.
+
+5.4.  HTTPS Transport
+
+   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").
+
+   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
+
+
+
+Margolis, et al.             Standards Track                   [Page 19]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   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.
+
+5.5.  Delivery Retry
+
+   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.
+
+5.6.  Metadata Variances
+
+   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.
+
+6.  IANA Considerations
+
+   The following are the IANA considerations discussed in this document.
+
+6.1.  Message Headers
+
+   Below is the Internet Assigned Numbers Authority (IANA) Permanent
+   Message Header Field registration information per [RFC3864].
+
+             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
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 20]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+6.2.  Report Type
+
+   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].
+
+   The registry name is "Report Type Registry", and the procedure for
+   updating the registry will be "Specification Required" [RFC8126].
+
+   An entry in this registry should contain:
+
+   o  the report-type being registered
+
+   o  one or more registered media types that can be used with this
+      report-type
+
+   o  the document containing the registration action
+
+   o  an optional comment
+
+   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/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/global-delivery-status
+   Registered By: [RFC6533], Section 6
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 21]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+6.3.  +gzip Media Type Suffix
+
+   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:
+
+   Type name: gzip file storage and transfer format.
+
+   +suffix: +gzip
+
+   References: [RFC1952] [RFC6713]
+
+   Encoding considerations: gzip is a binary encoding.
+
+   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:
+
+       For cases defined in +gzip, where the fragment identifier
+       resolves per the +gzip rules, process as specified in
+       +gzip.
+
+       For cases defined in +gzip, where the fragment identifier does
+       not resolve per the +gzip rules, process as specified in
+       "xxx/yyy+gzip".
+
+       For cases not defined in +gzip, process as specified in
+       "xxx/yyy+gzip".
+
+   Interoperability considerations: 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
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 22]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   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.
+
+   Contact: art@ietf.org
+
+   Author/Change controller: Internet Engineering Task Force
+   (iesg@ietf.org).
+
+6.4.  application/tlsrpt+json Media Type
+
+   This document registers multiple media types, beginning with Table 1
+   below.
+
+    +-------------+----------------+-------------+-------------------+
+    | Type        | Subtype        | File Ext    | Specification     |
+    +-------------+----------------+-------------+-------------------+
+    | application | tlsrpt+json    |  .json      | Section 5.3       |
+    +-------------+----------------+-------------+-------------------+
+
+                    Table 1: SMTP TLS Reporting Media Type
+
+   Type name: application
+
+   Subtype name: tlsrpt+json
+
+   Required parameters: N/A
+
+   Optional parameters: N/A
+
+   Encoding considerations: Encoding considerations are identical to
+   those specified for the "application/json" media type.  See
+   [RFC7493].
+
+   Security considerations: Security considerations relating to SMTP TLS
+   Reporting are discussed in Section 7.
+
+   Interoperability considerations: This document specifies the format
+   of conforming messages and the interpretation thereof.
+
+   Published specification: Section 5.3 of RFC 8460.
+
+   Applications that use this media type: Mail User Agents (MUAs) and
+   Mail Transfer Agents.
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 23]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   Additional information:
+
+      Deprecated alias names for this type: N/A
+
+      Magic number(s): N/A
+
+      File extension(s): ".json"
+
+      Macintosh file type code(s): N/A
+
+   Person & email address to contact for further information:
+   See the Authors' Addresses section.
+
+   Intended usage: COMMON
+
+   Restrictions on usage: N/A
+
+   Author: See the Authors' Addresses section.
+
+   Change controller: Internet Engineering Task Force (iesg@ietf.org).
+
+6.5.  application/tlsrpt+gzip Media Type
+
+    +-------------+----------------+-------------+-------------------+
+    | Type        | Subtype        | File Ext    | Specification     |
+    +-------------+----------------+-------------+-------------------+
+    | application | tlsrpt+gzip    |  .gz        | Section 5.3       |
+    +-------------+----------------+-------------+-------------------+
+
+                    Table 2: SMTP TLS Reporting Media Type
+
+   Type name: application
+
+   Subtype name: tlsrpt+gzip
+
+   Required parameters: N/A
+
+   Optional parameters: 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.
+
+   Interoperability considerations: This document specifies the format
+   of conforming messages and the interpretation thereof.
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 24]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   Published specification: Section 5.3 of RFC 8460.
+
+   Applications that use this media type: Mail User Agents (MUAs) and
+   Mail Transfer Agents.
+
+   Additional information:
+
+      Deprecated alias names for this type: N/A
+
+      Magic number(s): The first two bytes are 0x1f, 0x8b.
+
+      File extension(s): ".gz"
+
+      Macintosh file type code(s): N/A
+
+   Person & email address to contact for further information:
+   See the Authors' Addresses section.
+
+   Intended usage: COMMON
+
+   Restrictions on usage: N/A
+
+   Author: See the Authors' Addresses section.
+
+   Change controller: Internet Engineering Task Force (iesg@ietf.org).
+
+6.6.  STARTTLS Validation Result Types
+
+   This document creates a new registry, "STARTTLS Validation Result
+   Types".  The initial entries in the registry are:
+
+              +-----------------------------+--------------+
+              | 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 |
+              +-----------------------------+--------------+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 25]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   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.
+
+7.  Security Considerations
+
+   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:
+
+   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  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  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  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.
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 26]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   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.
+
+   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.
+
+8.  Privacy Considerations
+
+   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.
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 27]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+9.  References
+
+9.1.  Normative References
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+              DOI 10.17487/RFC5321, October 2008,
+              <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>.
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 28]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [RFC7405]  Kyzivat, P., "Case-Sensitive String Support in ABNF",
+              RFC 7405, DOI 10.17487/RFC7405, December 2014,
+              <https://www.rfc-editor.org/info/rfc7405>.
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 29]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   [RFC7493]  Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
+              DOI 10.17487/RFC7493, March 2015,
+              <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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+9.2.  Informative References
+
+   [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>.
+
+   [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>.
+
+   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
+              <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>.
+
+   [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>.
+
+
+
+Margolis, et al.             Standards Track                   [Page 30]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 31]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+Appendix A.  Example Reporting Policy
+
+A.1.  Report Using MAILTO
+
+            _smtp._tls.mail.example.com. IN TXT \
+                    "v=TLSRPTv1;rua=mailto:reports@example.com"
+
+A.2.  Report Using HTTPS
+
+           _smtp._tls.mail.example.com. IN TXT \
+                   "v=TLSRPTv1; \
+                   rua=https://reporting.example.com/v1/tlsrpt"
+
+Appendix B.  Example JSON Report
+
+   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".
+
+   {
+     "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
+       }, {
+
+
+
+Margolis, et al.             Standards Track                   [Page 32]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+         "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"
+       }]
+     }]
+   }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 33]
+
+RFC 8460                   SMTP TLS Reporting             September 2018
+
+
+Contributors
+
+   Laetitia Baudoin
+   Google, Inc.
+   lbaudoin@google.com
+
+Authors' Addresses
+
+   Daniel Margolis
+   Google, Inc.
+
+   Email: dmargolis@google.com
+
+
+   Alexander Brotman
+   Comcast, Inc.
+
+   Email: alex_brotman@comcast.com
+
+
+   Binu Ramakrishnan
+   Oath, Inc.
+
+   Email: prbinu@yahoo.com
+
+
+   Janet Jones
+   Microsoft, Inc.
+
+   Email: janet.jones@microsoft.com
+
+
+   Mark Risher
+   Google, Inc.
+
+   Email: risher@google.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 34]
+