Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
There seems to be a bit of internal inconsistency in Appendix B.2: Names of PSDs participating in PSD DMARC must be registered this new registry. New entries are assigned only for PSDs that require use of DMARC. [...] These two sentences seem to be in conflict, since a PSD can participate in PSD DMARC without requiring use of DMARC for all its subdomains. The rest of the section is clear that the registry is only intended to be for PSDs that do require the use of DMARC for subdomains, so I expect that a minor tweak to the wording of "PSDs participating in PSD DMARC" would be an appropriate fix.
This document is generally in pretty good shape; my comments (and, to some extent, my discuss as well) are pretty minor points. Thanks to Sandra Murphy for the secdir review. I think there were some questions in there that are worth a response and possibly clarifications in the document. Section 1.2 It seems like the "branded PSD" and "multi-organization PSD" cases would benefit from a protocol-level indication and separate handling by message recipients. It seems likely that the newly defined np (in combination with the preexisting sp) provides the flexibility to describe the different cases, but it seems like it would be helpful to have some discussion in this document that relates these two cases to the actual protocol mechanisms used to achieve them. Section 3 As Lars and Éric already commented, I suggest using a phrasing that includes something like "this experiment" and maybe "proposes", since actually formally updating the DMARC specification would procedurally be a bit exciting. Section 3.2 np: Requested Mail Receiver policy for non-existent subdomains (plain-text; OPTIONAL). Indicates the policy to be enacted by the I assume that "subdomains" here refers only to direct children (i.e., one additional label), not deeper in the hierarchy. It's not entirely clear to me whether all readers will do likewise, though... Section 3.3, 3.6 It sounds like this entire paragraph is appended to the section? In other subsections we are a bit more explicit about where the new text is going and what part is the new text. Section 4.1 o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC usage: Privacy risks for Organizational Domains that have not deployed DMARC within such PSDs are significant. For non-DMARC Organizational Domains, all DMARC feedback will be directed to the PSO. PSD DMARC is opt-out (by publishing a DMARC record at the Organizational Domain level) vice opt-in, which would be the more desirable characteristic. This means that any non-DMARC organizational domain would have its feedback reports redirected to the PSO. The content of such reports, particularly for existing domains, is privacy sensitive. It might be worth making some statement about the applicability of PSD DMARC for such PSDs that do not mandate DMARC usage. (I guess the following paragraphs mostly play that role, though perhaps editorially tying them together more clearly is possible.) Or, in the vein of my comment on section 1.2, an explicit protocol mechanism could be introduced that limits the reporting to just the indicated (public suffix) domain and does not apply to subdomains. organizational PSDs MUST be limited to non-existent domains except in cases where the reporter knows that PSO requires use of DMARC. Do we have examples of how the reporter might come to know this? Say ... Appendix B.2? Appendix A o Section 3.2 adds the "np" tag for non-existent subdomains (DNS NXDOMAIN). [...] Per §2.7, this is for NXDOMAIN or NODATA, not just NXDOMAIN. Appendix B.1 A sample stand-alone DNS query service is available at [psddmarc.org]. It was developed based on the contents suggested for "DNS query service" is so generic so as to be almost meaningless. Even if we defer usage instructions to the external site, we should probably say a bit more about what it is expected to do.
Thank you to Sandra Murphy for the SECDIR review. Please review those proposed clarifying edits. ** Section 4.1 Due to the inherent Privacy and Security risks associated with PSD DMARC for Organizational Domains in multi-organization PSDs that do not particpate in DMARC, any Feedback Reporting related to multi- organizational PSDs MUST be limited to non-existent domains except in cases where the reporter knows that PSO requires use of DMARC. Is there any guidance on how the reporter might know “that [the] PSO requires use of DMARC”. ** Section B.2. -- Please define the semantics of the “status” column and the expected/possible values -- Reconcile the differences between the initial values noted in this this document and those at http://psddmarc.org/registry.html: o the text in this section says “current” for the status column, but the html page has same values as set to “active” o the PSD names in the initial values of this document are of the form “.*”, but the html page has no leading dot (i.e., “.bank” vs. “bank”)
Section 3, paragraph 2, comment: > 3. PSD DMARC Updates to DMARC Requirements > > This document updates DMARC as follows: If I understand things correctly, this document specifies an experiment that - if successful - would lead to an update of RFC7489. It's therefore confusing to see the text in Section 3 that is written as if that update was already being brought into effect. I'd much prefer text that said things like "to participate in this experiment, implementations should do X or Y or Z and/or interpret Section foo of RFC7489 as bar", etc. Section 7.3, paragraph 1, comment: > 7.3. URIs It's unusual for an RFC to have reference sections other than for normative and informative references, because it's not clear what category references here would fall into. Also, I'll note that [psddmarc.org] was cited as an informative reference in that section, so why not this one? ------------------------------------------------------------------------------- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 3.2, paragraph 3, nit: > to that of the "p" tag defined below. If the 'np' tag is absent, The document uses both single and double quotes throughput (above is an example), and it's not clear if this is deliberate (i.e., there is a meaning to this) or whether this is an editorial oversight that should be corrected. Section 6.1, paragraph 5, nit: > +----------+-----------+---------+-------------------------------+ > | Tag Name | Reference | Status | Description | > +----------+-----------+---------+-------------------------------+ > | np | this | current | Requested handling policy for | > | | document | | non-existent subdomains | > +----------+-----------+---------+-------------------------------+ > You should add an RFC Editor Note instructing them to replace "this document" with the RFC number of this document (to make sure they are aware of the action). Section 1, paragraph 2, nit: - DMARC ([RFC7489]) provides a mechanism for publishing organizational - - - + DMARC [RFC7489] provides a mechanism for publishing organizational Section 1, paragraph 3, nit: - found in Section 3.2 of the DMARC specification. Currently the + found in Section 3.2 of the DMARC specification. Currently, the + + Section 1, paragraph 4, nit: - In the basic DMARC model, PSDs are not organizational domains and are + In the basic DMARC model, Public Suffix Domains (PSDs) are not organizational domains and are + +++++++++++++++++++++++ + Section 1.2, paragraph 7, nit: - handling policy for non-existent subdommains. This is provided - - + handling policy for non-existent subdomains. This is provided Section 1.2, paragraph 7, nit: - of requesting harsh policy treatment (e.g. reject) is lower. + of requesting harsh policy treatment (e.g., reject) is lower. + + Section 1.2, paragraph 8, nit: - (i.e. if a DMARC record were published for 'example', then mail from + (i.e., if a DMARC record were published for 'example', then mail from + + Section 2.7, paragraph 2, nit: - is a broader definition than that in NXDOMAIN [RFC8020]. - --------- + is a broader definition than that in [RFC8020]. Section 4.1, paragraph 7, nit: - not particpate in DMARC, any Feedback Reporting related to multi- + not participate in DMARC, any Feedback Reporting related to multi- + + "B.3.", paragraph 3, nit: - supposed to be the output domain of the regular PSL lookup, i.e. the + supposed to be the output domain of the regular PSL lookup, i.e., the + +
Thank you for the work put into this document. It is easy to read and specify an experiment, which could be useful. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Sections 1 and 3-- I share Lars' concern about the "update" in the last paragraph. -- Section 5.1 -- Editorial comment: why using a sub-section ? Let's 'glue' its contents to the first § of section 5. BTW, interesting read this section. == NITS == -- Section 2.2 -- Unsure whether "Requests for Comment (RFC)" is really required ;-) cfr https://www.rfc-editor.org/materials/abbrev.expansion.txt -- Sections 2.2 ... 2.7 -- Mostly cosmetic but I would have preferred the usual presentation to introduce terminology, i.e., a list and not several sub-sections.
Thanks for this document. A few minor clarifying comments that may help this document: o Branded PSDs (e.g., ".google"): These domains are effectively Organizational Domains as discussed in [RFC7489]. They control all subdomains of the tree. These are effectively private domains, but listed in the current public suffix list. They are treated as Public for DMARC purposes. They require the same protections as DMARC Organizational Domains, but are currently unable to benefit from DMARC. I found this paragraph confusing. In "These are effectively private domains", it wasn't clear to me what "these" refers to. Is it the domains or the subdomains. Otherwise it says "these are effectively" twice, with two different descriptions. Perhaps, check if this paragraph can be reworded to make it clearer. These issues are not typically applicable to PSDs, since they (e.g., the ".gov.example" used above) do not typically send mail. I presume that this means that emails are not directly sent from @gov.example, rather than there is no mail below .gov.example. Perhaps worth clarifying? For DMARC purposes, a non-existent domain is a domain for which there is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This is a broader definition than that in NXDOMAIN [RFC8020]. I presume that this means that there is no response for any of A, AAAA and MX records, not that there is no response for a particular type of record. Should this be clarified? Although arguably it seems pretty obvious. Thanks, Rob