Overall I'm comfortable with the introduction verbiage. I do have one concern:
"For a mail-receiving organization supporting DMARC, a message that passes validation is part of a message stream that is reliably associated with the Domain Owner and/or any, some, or all of the Authenticated Identifiers. Therefore, reputation assessment of that stream by the mail-receiving organization does not need to be encumbered by accounting for unauthorized use of any domains." My concern is with "does not need to be encumbered by accounting for unauthorized use of any domains". This ignores cases such as DNS hijacking and domain compromise. Perhaps changing it to "does not need to be encumbered by accounting for unauthorized use of any domains by 3rd party senders" or "does not need to be encumbered by accounting for unauthorized use of any domains by 3rd party originators" Michael Hammer On Thu, May 6, 2021 at 8:22 AM Todd Herr <todd.herr= 40valimail....@dmarc.ietf.org> wrote: > On Thu, May 6, 2021 at 5:47 AM Alessandro Vesely <ves...@tana.it> wrote: > >> Todd, >> >> does your message assume that the relevant tickets are all accepted as >> valid >> indications to alter the spec? In particular, tickets #52 and #75 have >> never >> been discussed on list. I'd guess they'll have to be discussed in their >> own >> threads. >> > > I don't know if each of those individual tickets has to be discussed in > their own threads or not, and I think it's more a decision for the chairs > to make than for the editors or the working group, but I could be very > wrong about that. > > What I will say is this: > > - The design team went off and effectively created a new version of > draft-ietf-dmarc-dmarcbis, specifically draft-ietf-dmarc-dmarcbis-01. It is > proposed text, nothing more, nothing less. > - The design team's work was influenced by those tickets which > currently show a status of 'infoneeded'. > - Due to the nature of the text, both of the following are true: > - Most, but perhaps not all, of the 'infoneeded' tickets had > impacts on multiple sections of draft-ietf-dmarc-dmarcbis-01 > - Most of the changes to sections of draft-ietf-dmarc-dmarcbis-00 > that were made in producing draft-ietf-dmarc-dmarcbis-01 were > influenced by > multiple tickets > > Back on April 23, when I posted here about setting expectations, I thought > at the time that adjudicating each of the infoneeded tickets might be the > way to go, but upon further reflection I'm not sure that's the case, since > it can be argued that those tickets were created against a work product > that no longer exists. It's also true that because those tickets affect the > wording in multiple sections of the document, adjudicating the -00 tickets > can theoretically result in a morass of edits made across multiple sections > of -01 and subsequent revisions, and everyone eventually losing the plot. > > Chairs, your thoughts? > > >> Discussing the resulting text before those tickets entails, for example, >> noting >> the cumbersomeness of the locution "severity of concern" where something >> like >> "desired disposition" might seem more immediate. In fact, ticket #85 was >> only >> discussed as a side effect of ticket #39, where the consensus, IIRC, was >> to >> keep the existing policy names while wavering about how to describe them. >> >> The term RFC5322.From is consistently used, notwithstanding ticket #96. >> For an >> alternative, let me attempt to define DMARC in terms of its acronym: >> >> The Domain-based Message Authentication, Reporting, and Conformance >> (DMARC) >> protocol recognizes the prevailing importance of the domain appearing >> in the >> From: header field of email messages. That domain name will be >> called the >> Main Identifier in this document. DMARC leverages the Sender Policy >> Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376]) >> protocols >> by focusing the authentication mechanisms they provide toward the Main >> Identifier. The Domain Owners corresponding to the Main Identifier >> are >> endowed with the possibility to receive feedback reports about >> authentication results at receivers. Finally, receivers are provided >> with >> the Domain Owners' desiderata about messages that fail >> authentication, which >> receivers may or may not decide to conform to. >> >> > As I stated above, I believe the better path for the working group is to > adjudicate draft-ietf-dmarc-dmarcbis-01. That revision contains a section > labeled "Introduction", you have proposed alternate text for that section, > let's discuss that section on the list, come to a consensus, and do it all > under the auspices of ticket 113. > > But that's just my opinion... > > -- > > *Todd Herr* | Sr. Technical Program Manager > *e:* todd.h...@valimail.com > *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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
