--- 1/draft-ietf-uta-smtp-tlsrpt-06.txt 2017-07-31 11:13:48.108412893 -0700 +++ 2/draft-ietf-uta-smtp-tlsrpt-07.txt 2017-07-31 11:13:48.152413945 -0700 @@ -1,25 +1,25 @@ Using TLS in Applications D. Margolis Internet-Draft Google, Inc Intended status: Standards Track A. Brotman -Expires: December 01, 2017 Comcast, Inc +Expires: February 1, 2018 Comcast, Inc B. Ramakrishnan Yahoo!, Inc J. Jones Microsoft, Inc M. Risher Google, Inc - May 31, 2017 + July 31, 2017 SMTP TLS Reporting - draft-ietf-uta-smtp-tlsrpt-06 + draft-ietf-uta-smtp-tlsrpt-07 Abstract A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE [RFC6698], and MTA-STS (TODO: Add ref). 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 @@ -35,21 +35,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 26, 2017. + This Internet-Draft will expire on February 1, 2018. Copyright Notice Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -58,53 +58,55 @@ 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 5 + 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 6 3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 6 3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 6 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 7 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 7 4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 7 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 7 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8 4.3.3. General Failures . . . . . . . . . . . . . . . . . . 8 4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 9 4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 9 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 11 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 12 - 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 13 + 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 14 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 14 - 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 14 + 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 15 6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 15 - 6.3. application/tlsrpt+* Media Types . . . . . . . . . . . . 15 - 6.4. STARTTLS Validation Result Types . . . . . . . . . . . . 16 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 18 - 8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 18 - 8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 18 - 9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 18 - 10. Normative References . . . . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + 6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 15 + 6.4. application/tlsrpt+gz Media Type . . . . . . . . . . . . 17 + 6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 18 + + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 19 + 8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 19 + 8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 19 + 9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 19 + 10. Normative References . . . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and hosts to establish secure SMTP sessions over TLS. The protocol design is based on "Opportunistic Security" (OS) [RFC7435], which maintains interoperability with clients that do not support STARTTLS but means that any attacker who can delete 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 @@ -194,21 +196,21 @@ The formal definition of the "_smtp-tlsrpt" TXT record, defined using [RFC5234], is as follows: tlsrpt-record = tlsrpt-version *WSP field-delim *WSP tlsrpt-rua [field-delim [tlsrpt-extensions]] field-delim = %x3B ; ";" tlsrpt-version = %x76 *WSP "=" *WSP %x54 %x4C %x53 %x52 - %x50 %x54 %x76 %x31 ; "v=TSRPTv1" + %x50 %x54 %x76 %x31 ; "v=TLSRPTv1" tlsrpt-rua = %x72 %x75 %x61 *WSP "=" *WSP tlsrpt-uri ; "rua=..." tlsrpt-uri = URI ; "URI" is imported from [@!RFC3986]; commas (ASCII ; 0x2C) and exclamation points (ASCII 0x21) ; MUST be encoded; the numeric portion MUST fit ; within an unsigned 64-bit integer tlsrpt-extensions = tlsrpt-extension *(field-delim tlsrpt-extension) @@ -238,22 +241,22 @@ "v=TLSRPTv1;rua=mailto:reports@example.com" 3.1.2. Report using HTTPS _smtp-tlsrpt.example.com. IN TXT \ "v=TLSRPTv1; \ rua=https://reporting.example.com/v1/tlsrpt" 4. Reporting Schema - The report is composed as a plain text file encoded in the JSON - format ([RFC7159]). + The report is composed as a plain text file encoded in the 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 @@ -389,118 +392,129 @@ }, "contact-info": email-address, "report-id": report-id, "policy": { "policy-type": policy-type, "policy-string": policy-string, "policy-domain": domain, "mx-host": mx-host-pattern }, "summary": { - "success-aggregate": total-successful-session-count, - "failure-aggregate:" total-failure-session-count + "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, - "session-count": failed-session-count, + "failed-session-count": failed-session-count, "additional-information": additional-info-uri, - "failure-reason-code": "Text body" + "failure-reason-code": "failure-reason-code" } ] } JSON Report Format 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 Section 5.6, "Internet Date/Time Format", of [RFC3339]. The report should be for a full UTC day, 0000-2400. o "email-address": The contact information for a responsible party of the report. It is provided as a string formatted according to - Section 3.4.1, "Addr-Spec", of [RFC5322]. + Section 3.4.1, "Addr-Spec", of [RFC5321]. 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": The JSON string serialization ([RFC7159] section 7) of the policy, whether TLSA record ([RFC6698] section 2.3) or MTA-STS policy. o "domain": The Policy Domain is the domain against which the MTA- - STS or DANE policy is defined. + STS or DANE policy is defined. In the case of Internationalized + Domain Names ([RFC5891]), the domain is the Punycode-encoded + A-label ([RFC3492]) and not the U-label. o "mx-host-pattern": The pattern of MX hostnames from the applied policy. It is provided as a string, and is interpreted in the same manner as the "Checking of Wildcard Certificates" rules in Section 6.4.3 of [RFC6125]. o "result-type": A value from Section 4.3, "Result Types", above. + In the case of Internationalized Domain Names ([RFC5891]), the + domain is the Punycode-encoded A-label ([RFC3492]) and not the + U-label. 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 or IPv6 address in dot-decimal or colon-hexadecimal - notation. + 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. o "receiving-mx-helo": (optional) The HELO or EHLO string from the banner announced during the reported session. - o "success-aggregate": The aggregate number (integer) of - successfully negotiated TLS-enabled connections to the receiving - site. + o "total-successful-session-count": The aggregate number (integer) + of successfully negotiated TLS-enabled connections to the + receiving site. - o "failure-aggregate": The aggregate number (integer) of failures to - negotiate an TLS-enabled connection to the receiving site. + o "total-failure-session-count": The aggregate number (integer) of + failures to negotiate an TLS-enabled connection to the receiving + site. - o "session-count": The number of (attempted) sessions that match the - relevant "result-type" for this section. + o "failed-session-count": The number of (attempted) sessions that + match the relevant "result-type" for this section. - o "additional-info-uri": An optional URI pointing 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": An optional URI [RFC3986] pointing 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 an TLS-related error code or error message. + For report purposes, an IPv4 Address is defined as: 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 + 5. Report Delivery Reports can be delivered either as an email message via SMTP or via HTTP POST. 5.1. Report Filename The filename is typically constructed using the following ABNF: filename = sender "!" policy-domain "!" begin-timestamp "!" end-timestamp [ "!" unique-id ] "." extension unique-id = 1*(ALPHA / DIGIT) - sender = domain ; imported from [@!RFC5322] + sender = domain ; imported from [@!RFC5321] policy-domain = domain 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 @@ -538,40 +552,41 @@ 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 - These message headers would allow for easy searching for all reports - submitted by a report domain or a particular submitter, for example - in IMAP: + These message headers MUST be included and should allow for easy + searching for all reports submitted by a report 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. The [RFC5322].Subject field for individual report submissions SHOULD conform to the following ABNF: - tlsrpt-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" - %x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" - domain-name 1*FWS ; from RFC 6376 - %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" - 1*FWS domain-name 1*FWS - %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" - msg-id ; from RFC 5322 + 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 @@ -638,117 +654,166 @@ 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: smtp + Applicable protocol: mail Status: standard Author/Change controller: IETF Specification document(s): this one Header field name: TLS-Report-Submitter - Applicable protocol: smtp + Applicable protocol: mail Status: standard Author/Change controller: IETF Specification document(s): this one 6.2. Report Type This document registers a new parameter "report-type="tlsrpt"" under "multipart/report" top-level media type for use with [RFC6522]. The media type suitable for use as a report-type is defined in the following section. -6.3. application/tlsrpt+* Media Types +6.3. application/tlsrpt+json Media Type - This document registers multiple media types, listed in Table 1 + This document registers multiple media types, beginning with Table 1 below. +-------------+----------------+-------------+-------------------+ | Type | Subtype | File extn | Specification | +-------------+----------------+-------------+-------------------+ | application | tlsrpt+json | .json | Section 5.3 | - | application | tlsrpt+gzip | .gz | Section 5.3 | +-------------+----------------+-------------+-------------------+ - Table 1: SMTP TLS Reporting Media Types + Table 1: SMTP TLS Reporting Media Type Type name: application - Subtype name: This documents registers multiple subtypes, as listed - in Table 1. + + 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 - [RFC7159]. + [RFC7493]. Security considerations: Security considerations relating to SMTP TLS Reporting are discussed in Section 7. Interoperability considerations: This document specifies format of conforming messages and the interpretation thereof. - Published specification: This document is the specification for these - media types; see Table 1 for the section documenting each media type. + Published specification: Section 5.3 of this document. Applications that use this media type: Mail User Agents (MUA) and Mail Transfer Agents. Additional information: Magic number(s): n/a - File extension(s): As listed in Table 1. + File extension(s): ".json" Macintosh file type code(s): n/a Person & email address to contact for further information: See Authors' Addresses section. Intended usage: COMMON Restrictions on usage: n/a Author: See Authors' Addresses section. Change controller: Internet Engineering Task Force (mailto:iesg@ietf.org). -6.4. STARTTLS Validation Result Types +6.4. application/tlsrpt+gz Media Type + + +-------------+----------------+-------------+-------------------+ + | Type | Subtype | File extn | 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: 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 format of + conforming messages and the interpretation thereof. + + Published specification: Section 5.3 of this document. + + Applications that use this media type: Mail User Agents (MUA) and + Mail Transfer Agents. + + Additional information: + + Magic number(s): n/a + + File extension(s): ".gz" + + Macintosh file type code(s): n/a + + Person & email address to contact for further information: See + Authors' Addresses section. + + Intended usage: COMMON + Restrictions on usage: n/a + + Author: See Authors' Addresses section. + + Change controller: Internet Engineering Task Force + (mailto:iesg@ietf.org). + +6.5. STARTTLS Validation Result Types This document creates a new registry, "STARTTLS Validation Result Types". The initial entries in the registry are: +-------------------------------+ | Result Type | +-------------------------------+ | "starttls-not-supported" | | "certificate-host-mismatch" | | "certificate-expired" | | "tlsa-invalid" | | "dnssec-invalid" | | "sts-policy-invalid" | | "sts-webpki-invalid" | | "validation-failure" | +-------------------------------+ The above entries are described in section Section 4.3, "Result - Types." New result types can be added to this registry without the - need to update this document. + Types." New result types can be added to this registry using "Expert + Review" IANA registration policy. 7. Security Considerations SMTP TLS Reporting provides transparency 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 @@ -802,45 +867,45 @@ { "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.com", "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be", "policy": { "policy-type": "sts", - "policy-string": "{ \"version\": \"STSv1\",\"mode\": \"report\", \"mx\": [\"*.mail.company-y.com\"], \"max_age\": 86400 }", + "policy-string": "{ \"version\": \"STSv1\",\"mode\": \"report\", \"mx\": [\".mail.company-y.com\"], \"max_age\": 86400 }", "policy-domain": "company-y.com", - "mx-host": "*.mail.company-y.com" + "mx-host": ".mail.company-y.com" }, "summary": { - "success-aggregate": 5326, - "failure-aggregate": 303 + "total-successful-session-count": 5326, + "total-failure-session-count": 303 } "failure-details": [{ "result-type": "certificate-expired", "sending-mta-ip": "98.136.216.25", "receiving-mx-hostname": "mx1.mail.company-y.com", - "session-count": 100 + "failed-session-count": 100 }, { "result-type": "starttls-not-supported", "sending-mta-ip": "98.22.33.99", "receiving-mx-hostname": "mx2.mail.company-y.com", - "session-count": 200, + "failed-session-count": 200, "additional-information": "hxxps://reports.company-x.com/ report_info?id=5065427c-23d3#StarttlsNotSupported" }, { "result-type: "validation-failure", "sending-mta-ip": "47.97.15.2", "receiving-mx-hostname: "mx-backup.mail.company-y.com", - "session-count": 3, + "failed-session-count": 3, "failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED" }] } Figure: Example JSON report for a 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". @@ -857,34 +922,62 @@ . [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . + [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode + for Internationalized Domain Names in Applications + (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, + . + + [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION + 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, + . + [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, . + [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, + . + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, . + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + DOI 10.17487/RFC5321, October 2008, + . + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . + [RFC5891] Klensin, J., "Internationalized Domain Names in + Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/ + RFC5891, August 2010, + . + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 + Address Text Representation", RFC 5952, DOI 10.17487/ + RFC5952, August 2010, + . + [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . @@ -909,20 +1002,24 @@ [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, . [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . + [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI + 10.17487/RFC7493, March 2015, + . + Authors' Addresses Daniel Margolis Google, Inc Email: dmargolis (at) google.com Alexander Brotman Comcast, Inc