On Thu, Jun 3, 2021 at 8:27 PM Dave Crocker <[email protected]> wrote:
> On 5/5/2021 11:48 AM, Todd Herr wrote: > > > We would like to achieve rough consensus on this section of text by > Friday, May 21. > > Apologies. I've only just been able to review this text. Attached are > suggested changes, done as a Word document with revision tracking turned on. > > It might appear that the edits effect major substance changes to the > Introduction, but I believe they do not; the intent was to retain the same > goals for the Introduction. > > Changes were driven by: > > - Providing better lead-in for readers with less background on the > document's topic > - Eliminating detail that is not need in an introduction > - Minimizing PSO text, since I belive the covered domains have Domain > Owners whether they are PSOs or not; hence the fact of being a PSO has > minimal import in the Introduction > - General wordsmithing, to tighten things up > > > Taking most of Dave's input into account results in an Introduction section that will read as follows: ------------------------------------begin current proposed text ----------------------------------- 1. Introduction Abusive email often includes unauthorized and deceptive use of a domain name in the RFC5322.From header field. The domain typically belongs to an organization expected to be known to - and presumably trusted by - the recipient. The Sender Policy Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376]) protocols provide domain- level authentication but are not directly associated with the RFC5322.From domain. DMARC leverages them, so that Domain Owners publish a DNS record indicating their RFC5322.From field: * Email authentication policies * Level of concern for mail that fails authentication checks * Desire for reports about email use of the domain name DMARC can cover non-existent sub-domains, below the "Organizational Domain", as well as domains at the top of the name hierarchy, controlled by Public Suffix Operators (PSOs). As with SPF and DKIM, DMARC classes results as "pass" or "fail". A pass from either SPF or DKIM is required. Also the passed domain must be "aligned" with the RFC5322.From domain. Domains are said to be "in alignment" if they have the same Organizational Domain, which is at the top of the domain hierarchy, while having the same administrative authority as the RFC5322.From domain. A DMARC pass indicates only that the RFC5322.From domain has been authenticated for that message. Of course, authentication does not carry an explicit or implicit value assertion about that message or about the Domain Owner. Indeed, a mail-receiving organization that performing DMARC validation can choose to follow the Domain Owner's requested disposition for authentication failures, and to inform the Domain Owner of the mail handling decision for that message. It also might choose different actions. For a mail-receiving organization supporting DMARC, a message that passes validation is part of a message stream that is reliably associated with the RFC5322.From field Domain Owner. Therefore, reputation assessment of that stream by the mail-receiving organization is not encumbered by accounting for unauthorized use of that domain in the RFC5322.From field. A message that fails this validation is not necessarily associated with the Domain Owner's domain and its reputation. DMARC, in the associated [DMARC-Aggregate-Reporting] and [DMARC-Failure-Reporting] documents, also specifies a reporting framework. Using it, a mail-receiving domain can generate regular reports about messages that claim to be from a domain publishing DMARC policies, sending those reports to the addresses specified by the Domain Owner. Use of DMARC creates some interoperability challenges that require due consideration before deployment, particularly with configurations that can cause mail to be rejected. These are discussed in Section 9. -------------------------------------end current proposed text ----------------------------------- I expect that discussion of this topic will continue for some time. -- *Todd Herr* | Sr. Technical Program Manager *e:* [email protected] *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
