(Reducing Ccs) That seems like it paints a much clearer picture, which is what Dale was after. A great start!
On Thu, Apr 9, 2020 at 12:54 PM Todd Herr <toddmh...@gmail.com> wrote: > Having reviewed the comments, I'm wondering if perhaps the following draft > rewrite of the Abstract section might be a first step to address many of > the points raised? > > *AbstractDMARC (Domain-based Message Authentication, Reporting, and > Conformance) is a scalable mechanism by which a mail-originating > organization can express domain-level policies and preferences for message > validation, disposition, and reporting, that a mail-receiving organization > can use to improve mail handling. * > > *The original design of DMARC applies only to domains that are registered > with a domain name registrar (called “Organizational Domains” in RFC 7489) > and nodes in the tree below Organizational Domains. Organizational Domains > are themselves nodes in the tree below domain names reserved for > registration, with the latter commonly referred to as “Top Level Domains” > (TLDs) (e.g., ‘.com’, ‘.co.uk <http://co.uk>’, etc.), although in this > document they will be referred to as Public Suffix Domains (PSDs).* > > *Since its deployment in 2015, use of DMARC has shown a clear need for the > ability to express policy for PSDs. This document describes an extension to > DMARC to enable DMARC functionality for PSDs.* > > *RFC 7489 describes an algorithm for a mail-receiving organization to use > in determining the Organizational Domain of an inbound mail message, and > this algorithm recommends the use of a “public suffix list” (PSL), with the > most common one maintained by the Mozilla Foundation and made public at > <http://publicsuffix.org/ <http://publicsuffix.org/>>. Use of such a PSL by > a mail-receiving organization will be required in order to discover and > apply any DMARC policy declared by a PSD.* > > *This document also seeks to address implementations that consider a > domain on a public Suffix list to be ineligible for DMARC* > > > On Sun, Apr 5, 2020 at 9:11 PM Dale Worley via Datatracker < > nore...@ietf.org> wrote: > >> Reviewer: Dale Worley >> Review result: Ready with Issues >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed by >> the IESG for the IETF Chair. Please treat these comments just like >> any other last call comments. >> >> For more information, please see the FAQ at >> >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >> >> Document: review-draft-ietf-dmarc-psd-08 >> Reviewer: Dale R. Worley >> Review Date: 2020-04-05 >> IETF LC End Date: 2020-04-08 >> IESG Telechat date: not known >> >> * Summary: >> >> This draft is on the right track but has open issues, described >> in the review. >> >> * Major issues: >> >> The privacy concerns described in section 4 are written as if there is >> no certainty that the mechanisms described in the document properly >> mitigate them. So the document appears to be incomplete. OTOH, since >> this is an Experimental RFC, such mitigation isn't necessary if there >> is commitment to do so later. In that case, the section should >> explicitly state that these are open issues and that there is an >> intention of revising the document to mitigate them. >> >> The text suggests that a mail receiver(?) that does DMARC processing >> has knowledge of all PSDs. This seems a priori unlikely and even >> impossible to implement. So this ought to be either explained at the >> appropriate place or resolved technically. >> >> * Minor issues: >> >> The document has the (common) editorial problem that it is written by >> people who are deeply familiar with the subject, and it's difficult to >> read if one doesn't share that familiarity. This is particularly >> significant because DMARC is an e-mail facility that (ideally) will >> affect all e-mail that is sent, so the target audience really should >> be anyone who has a basic understanding of e-mail. Three particular >> elements of this are: >> >> - It would be very helpful if the Introduction could state, in a few >> sentences, the purpose and operation of DMARC, thus informing the >> reader of the framework whose deficiencies this document attempts to >> address. In particular, one shouldn't have to read the DMARC RFCs >> to be able to read this document and understand its general import. >> >> - The "experiment" appendixes are unclear about what the experiments >> actually are: what questions they are to answer, what actions will >> be taken, how the results will be evaluated. Starting each appendix >> with an overview paragraph would be helpful. >> >> - Forward references should be minimized so that a reader can >> understand the document in one pass. >> >> As a derivative of the first of these elements, the terminology used >> for the properties of domain names is not clearly defined. In >> particular, where does a registration "occur"? The only term for >> which I think the general audience possesses an unambiguous definition >> is "the registered domain name", e.g. ietf.org. Now I *think* its PSD >> is ".org", but it might be "ietf.org", and I don't know whether the >> registration of ietf.org "occurs" at ietf.org or .org. Further points >> I didn't understand are pointed out in the review of the >> Abstract and Introduction. >> >> * Nits/editorial comments: >> >> Abstract >> >> I'm having quite a bit of difficulty figuring out exactly what the >> Abstract means. I'm sure that the working group clearly understands >> what is meant, but the writing is just loose enough that I can't fix >> the meaning. To raise the immediate questions: >> >> DMARC (Domain-based Message Authentication, Reporting, and >> Conformance) is a scalable mechanism by which a mail-originating >> organization can express domain-level policies and preferences for >> message validation, disposition, and reporting, that a mail-receiving >> organization can use to improve mail handling. >> >> This sentence is quite good, as it introduces what DMARC is all about. >> >> The design of DMARC >> presumes that domain names represent either nodes in the tree below >> which registrations occur, or nodes where registrations have >> occurred; it does not permit a domain name to have both of these >> properties simultaneously. >> >> You want to make clear here that "registration" means "domain name >> ownership registration" (which is what section 2.2 says). Otherwise >> it leaves open that there is some sort of DMARC registration that you >> might intend, until the reader gets to section 2.2. >> >> There's an ambiguity regarding "where" a registration happens. E.g., >> does the registration of "ietf.org" "occur at" "ietf.org" or "occur >> at" "org"? It's possible that this could be simplified/disambiguated >> by not using this term, but instead phrasing this in terms of domain >> names that "are registered", and the allowed relationships between >> them. >> >> And it appears certain that there are DNS nodes where registrations >> are only done *above* that node, e.g. "datatracker.ietf.org", which >> this sentence (if taken literally) says is not permitted by DMARC. Is >> the property you want to declare "one node where registrations are >> done cannot exist below another node where registrations are done"? >> >> Or perhaps domain names like "datatracker.ietf.org" are of no interest >> to DMARC because DMARC is never applied to messages for which that is >> the relevant address? >> >> Since its deployment in 2015, use of >> DMARC has shown a clear need for the ability to express policy for >> these domains as well. >> >> This sentence doesn't make it clear what "these domains" refers to. >> >> Domains at which registrations can occur are referred to as Public >> Suffix Domains (PSDs). This document describes an extension to DMARC >> to enable DMARC functionality for PSDs. >> >> It would probably be clearer to use "domain name ownership >> registrations" again here. >> >> This sentence suggests that the registration of "ietf.org" "occurs at" >> "org" and so "org" is a PSD. >> >> This document also seeks to address implementations that consider a >> domain on a public Suffix list to be ineligible for DMARC >> enforcement. >> >> This suggests that implementations believe that they know of all PSDs, >> so they can "consider them ineligible for DMARC enforcement". But >> it's hard to imagine that that they can know that they know of all >> PSDs. >> >> An additional point, and I'm not sure how valuable this is, would be >> to clarify "I'm holding an e-mail message in my hands. What do I do >> next?", that is, What address in the message is the domain whose DMARC >> information is applied to the message? And what indeed does DMARC >> processing do to a message? For most of the sentences of the >> Abstract, this is not important, but it leaves the effect of the last >> sentence unclear, as "DMARC is not enforced on messages whose *sender* >> is in a PSD" is quite a bit different from "DMARC is not enforced on >> messages whose *recipient* is in a PSD". (Section 3.3 suggests that >> the address in the From header of the message is the one that is used >> for DMARC processing.) >> >> It's unclear what exactly is the contents of a "public suffix list". >> Naively, it appears that it is the list of domain names under which >> names can be registered, but the text uses the term in the plural, so >> there must be some additional structure. >> >> Also, it seems there are some significant privacy matters addressed by >> this document, and it's probably worth adding a sentence to notify the >> reader of that. >> >> 1. Introduction >> >> A number of the questions about the Abstract apply to the Introduction >> as well. But generally, since e-mail is a subject that every reader >> has a basic knowledge of, it would be useful to write the introduction >> so that one did not have to have a knowledge of the DMARC architecture >> to understand the introduction. >> >> "gov.example" publishes the following DMARC record: >> >> "v=DMARC1; p=reject; rua=mailto:dm...@dmarc.service.gov.example"; >> >> at >> >> _dmarc.gov.example. >> >> Even better would be this aid to people who don't already know DMARC >> implementation: >> >> "gov.example" publishes the following DMARC DNS record: >> >> _dmarc.gov.example. TXT \ >> "v=DMARC1; p=reject; rua=mailto:dm...@dmarc.service.gov.example"; >> >> -- >> >> the non-existent organizational domain of @tax.gov.example >> >> I suspect you mean "t4x.gov.example" here. >> >> This document provides a simple extension to DMARC [RFC7489] to >> allow [...] >> >> This sentence lists 4 important items, each of which is fairly long, >> which together are the summary of the whole document, so it might be >> useful to break this into a bullet-list. >> >> 2. Terminology and Definitions >> >> In many cases the public portion of the DNS tree is [...] >> >> What does "the public portion" mean? I'm guessing it means "the names >> not available for private registration", but you should be unambiguous >> here. >> >> They are not available for private >> registration. In many cases the public portion of the DNS tree is >> more than one level deep. >> >> It seems like these two sentences are redundant and the flow of the >> paragraph would be better if they were removed. ... Actually once they >> are removed, it reveals that the next two sentences largely duplicate >> the first two sentences of the paragraph. >> >> 2.3. Longest PSD >> >> The longest PSD is the Organizational Domain with one label removed. >> >> 2.4. Organizational Domain >> >> The term Organizational Domains is defined in DMARC [RFC7489] >> Section 3.2. >> >> 2.4 should be moved ahead of 2.3 to avoid a forward-reference. But it >> would be really helpful if the definition of Organizational Domain was >> either summarized here or completely copied from RFC7489. In >> particular, if Organizational Domain is not the same as registered >> domain name, that should be flagged. >> >> 2.5. Public Suffix Operator (PSO) >> >> A Public Suffix Operator manages operations within its PSD. >> >> Better to explicitly define the possession relationship explicitly: >> >> A Public Suffix Operator is an organization which manages >> operations within a PSD, particularly the DNS records published for >> names at and under that domain name. >> >> -- >> >> 2.6. PSO Controlled Domain Names >> >> PSO Controlled Domain Names are names in the DNS that are managed by >> a PSO and are not available for use as Organizational Domains. >> Depending on PSD policy, these will have one (e.g., ".com") or more >> (e.g., ".co.uk") name components. >> >> The second sentence is odd; is it useful? Is it just to say "PSO >> Controlled Domain Names may have one or more components."? >> >> 3.1. General Updates >> >> References to "Domain Owners" also apply to PSOs. >> >> This change really ought to be localized to a specific textual change >> somewhere in RFC 7489, in the say way that the other changes are >> specific amendments to the DMARC algorithm. >> >> 3.2. Section 6.3 General Record Format >> >> These section titles are difficult to read. At first I thought there >> was some typographical problem. But you could clarify this as "3.2. >> Updates to Section 6.3. General Record Format". Similarly for the >> other subsections of section 3. >> >> 3.3. Section 6.5. Domain Owner Actions >> >> The mechanism for doing so is one of the >> experimental elements of this document. >> >> I think that what this means is that the whole document is an >> experimental "mechanism for doing so". If so, I think it could be >> better phrased >> >> This document is an experimental mechanism for doing so. >> >> -- >> >> 3.4. Section 6.6.1. Extract Author Domain >> >> [...] when the domain name extracted by the receiver (from the >> RFC5322.From) is on the public suffix list used by the receiver. >> >> This touches the question above about what a public suffix list is, >> and how there can be more than one of them. But without that >> knowledge, it's hard to see which PSL is "used" by the receiver of the >> message. >> >> Also, it's not clear to me how *this* document creates a capability >> which applies to domains that are on the PSL. E.g., if an "np" is >> defined for ".org", it applies to (that is, affects processing of >> e-mail from) any "X.org" that doesn't have its own DMARC records. But >> I don't see how an "np" tag for ".org" affects processing of messages >> from "example@org". >> >> 3.5. Section 6.6.3. Policy Discovery >> >> (discussed in the experiment description >> (Appendix A)) >> >> Given that this text is nominally an update to the text of RFC 7489, >> you want to disambiguate the binding of "Appendix A": >> >> (discussed in the experiment description >> ([this document] Appendix A)) >> >> 3.6. Section 7. DMARC Feedback >> >> See Section 4 of this document for discussion of Privacy >> Considerations. >> >> Similarly to section 3.5, but also clarifying the scope of "privacy >> considerations": >> >> See Section 4 of [this document] for discussion of Privacy >> Considerations for PSD DMARC. >> >> 4. Privacy Considerations >> >> The Privacy Considerations of [RFC7489] apply to this document. >> >> This could be clarified as >> >> Additionally, the Privacy Considerations of [RFC7489] apply to the >> mechanisms described by this document. >> >> -- >> >> Providing feedback reporting to PSOs can, in some cases, create >> leakage of information outside of an organization to the PSO. >> >> "outside" probably isn't the word you want to use here, as it is >> easier to read "outside" as giving the original location of >> "information" than to read "outside" as giving the direction of >> "leakage". Perhaps >> >> Providing feedback reporting to PSOs can, in some cases, create >> leakage of information out of an organization to the PSO of its >> domain name. >> >> -- >> >> To minimize this potential concern, >> PSD DMARC feedback is best limited to Aggregate Reports. [...] >> >> [...] any Feedback Reporting related to multi- >> organizational PSDs ought to be limited to non-existent domains >> except in cases where the reporter knows that PSO requires use of >> DMARC. >> >> I can't see where in the document that these principles are turned >> into MUST statements that ensure the privacy issues are solved. >> >> The experiment is to evaluate different possible approaches. >> >> Calling this an "experiment" suggests that these is an intended series >> of actions whose result will answer the listed questions. But there >> doesn't seem to be any such actions listed. The description makes it >> sound like what is intended is continuing discussions in the working >> group, but that wouldn't be an "experiment". >> >> A.2. Non-Existent Subdomain Policy >> >> Similar questions arise for this section. The second paragraph >> suggests that the experiment is to see whether the "np" tag is >> successful. >> >> There are also >> suggestions that it would be more generally useful for DMARC. >> >> What does "it" refer to? (Does it mean "this ability"?) >> >> Appendix B. DMARC PSD Registry Examples >> >> In this appendix, it appears that the contents of the experiment are >> clear in the authors' minds, but there is no summary at the top that >> states what the experimental facilities are and the "big picture" into >> which they fit. >> >> Appendix C. Implementations >> >> C.1. Authheaders Module >> >> What e-mail MTA is Authheaders an extension for? >> >> [END] >> >> >> >> _______________________________________________ >> dmarc mailing list >> dm...@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > -- > Todd Herr >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
