This thread hasn't generated any discussion or momentum yet, and I know that's not because y'all have found the proposed text for the Abstract and Introduction to be acceptable, so I'm going to add the text to this thread and see where the discussion leads.
----------------------------------------------- cut here ---------------------------------------------------- Abstract This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting. Mail-receiving organizations can in turn use these expressions of policies and preferences to inform their mail handling decisions should they choose to do so. This document obsoletes RFC 7489. [...] 1. Introduction RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: The source for this draft is maintained in GitHub at: https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis (https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis) The Sender Policy Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376]) protocols provide domain-level authentication, and DMARC builds on these protocols. DMARC is designed to give ADminstrative Management Domains (ADMDs) that originate email the ability to publish in a DNS TXT record their email authentication policies, specify preferred handling for mail that fails authentication checks, and request reports about mail purportedly originated by the ADMD, as determined by the RFC5322.From header in the message. As with SPF and DKIM, DMARC authentication checks result in verdicts of "pass" or "fail". A DMARC pass verdict requires not only that SPF or DKIM pass for the message in question, but also that the domain validated by the SPF or DKIM check is aligned with the domain in the RFC5322.From header. In the DMARC protocol, two domains are said to be "in alignment" if they have the same Organizational Domain (a.k.a., relaxed alignment) or they are identical (a.k.a., strict alignment). A DMARC pass verdict asserts only that the RFC5322.From domain has been authenticated in that message; there is no explicit or implied value assertion attributed to a message that receives such a verdict. A mail-receiving organization that performs DMARC validation checks on inbound mail can choose to use the results and the preferences expressed by the originating domain for message disposition to inform its mail handling decision for that message. For messages that pass DMARC validation checks, the mail-receiving organization can be confident in applying handling based on its known history for similarly authenticated messages, whereas messages that fail such checks cannot be reliably associated with a domain with a history of sending DMARC-validated messages. DMARC also describes a reporting framework in which mail-receiving domains can generate regular reports containing data about messages seen that claim to be from domains that publish DMARC policies, and send those reports to the ADMD as requested by its DMARC policy record. Experience with DMARC has revealed some issues of interoperability with email in general that require due consideration before deployment, particularly with configurations that can cause mail to be rejected. These are discussed in Section 9. ----------------------------------------------- cut here ---------------------------------------------------- On Fri, Nov 13, 2020 at 2:54 PM Todd Herr <todd.h...@valimail.com> wrote: > Hi. > > I wanted to call everyone's attention to how draft-ietf-dmarc-dmarcbis-00 > differs from the existing RFC 7489. > > The key differences are as follows: > > - Section 7, DMARC Feedback, has been mostly removed except for a > paragraph that mentions that reporting will be discussed in a different > document (as per current plans) > - Section 9, Privacy Considerations, has been removed (under the > expectation that they'll be discussed in the reporting documents) > - Appendix C, DMARC XML Schema, has been removed (under the > expectation that it'll be discussed in the the reporting documents) > - Remaining target references to "verifying-external-destinations", > "failure-reports", and "aggregate-reports", which were anchors in the > removed sections mentioned above, have been replaced by hand-wavy language > referencing "The DMARC reporting document(s)" > - The Abstract and Introduction section have been rewritten as an > attempt to address issue #80 > <https://trac.ietf.org/trac/dmarc/ticket/80> - *DMARCbis Should Have a > Clear and Concise Definition of DMARC* > > Obviously the text applicable to the first four bullet points above will > evolve over time, and it may not yet be the right time in the process to > discuss those sections. However, the proposed new text for the Abstract and > Introduction is certainly worthy of discussion at this time, I believe. > > On Wed, Nov 11, 2020 at 4:55 PM <internet-dra...@ietf.org> wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Domain-based Message Authentication, >> Reporting & Conformance WG of the IETF. >> >> Title : Domain-based Message Authentication, Reporting, >> and Conformance (DMARC) >> Authors : Emil Gustafsson >> Todd M. Herr >> John Levine >> Filename : draft-ietf-dmarc-dmarcbis-00.txt >> Pages : 55 >> Date : 2020-11-11 >> >> Abstract: >> This document describes the Domain-based Message Authentication, >> Reporting, and Conformance (DMARC) protocol. >> >> DMARC is a scalable mechanism by which a mail-originating >> organization can express domain-level policies and preferences for >> message validation, disposition, and reporting. Mail-receiving >> organizations can in turn use these expressions of policies and >> preferences to inform their mail handling decisions should they >> choose to do so. >> >> This document obsoletes RFC 7489. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ >> >> There is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-00.html >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> I-D-Announce mailing list >> i-d-annou...@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > > -- > > *Todd Herr* | Sr. Technical Program Manager > *e:* todd.h...@valimail.com > *p:* 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. > -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.h...@valimail.com *p:* 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
