Scott, I have two editorial nits that account for a grand total of three characters. It seemed less complicated to just send a PR in Github, so I did.
Stan On Sat, Jul 27, 2019, at 4:45 PM, Scott Kitterman wrote: > On Monday, July 22, 2019 12:23:15 PM EDT Murray S. Kucherawy wrote: > > Reviewing as the document shepherd: > > > > Abstract > > > > [...] > > organization can use to improve mail handling. DMARC policies can be > > applied at the individual domain level or for a set of domains at the > > organizational level. > > > > I think the abstract is a bit too abstract. Which set of domains? > > > > > > The design of DMARC precludes grouping > > policies for a set of domains above the organizational level, such as > > TLDs (Top Level Domains). > > > > Is that the same set? > > I updated the paragraph to start: > > 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. DMARC policies can be > applied to individual domains or to all domains within an > organization. The design of DMARC precludes grouping policies for > domains based on policy published above the organizational level, > such as TLDs (Top Level Domains). > > Does that clear those comments up? > > > > These types of domains (which are not all > > at the top level of the DNS tree) can be collectively referred to as > > Public Suffix Domains (PSDs). > > > > What "types" are there? > > Changed to: > > organization. The design of DMARC precludes grouping policies for > domains based on policy published above the organizational level, > such as TLDs (Top Level Domains). Domains at this higher level of > the DNS tree (but not necessarily at the top of the DNS tree) can be > collectively referred to as Public Suffix Domains (PSDs). > > > For the subset of PSDs that require > > DMARC usage, this memo describes an extension to DMARC to enable > > DMARC functionality for such domains. > > > > What's the requirement? > > Given that the document no longer contains such a constraint, I've updated my > working copy to say: > > This memo describes an extension to DMARC to enable DMARC functionality PSDs. > > > 1. Introduction > > > > DMARC [RFC7489] provides a mechanism for publishing organizational > > policy information to email receivers. DMARC [RFC7489] allows policy > > to be specified for both individual domains and sets of domains > > > > Which sets? > > > Comment is OBE based on previous changes. > > > within a single organization. For domains above the organizational > > level in the DNS tree, policy can only be published for the exact > > domain. There is no method available to such domains to express > > lower level policy or receive feedback reporting for sets of domains. > > > > Still too abstract. I don't know what sort of set groupings you might > > be after here. > > I think the new text is better. Please check and let me know if it's there > yet or not. > > > This prevents policy application to non-existent domains and > > identification of domain abuse in email, which can be important for > > brand and consumer protection. > > > > As an example, imagine a country code TLD (ccTLD) which has public > > subdomains for government and commercial use (.gov.example and > > .com.example). Within the .gov.example public suffix, use of DMARC > > [RFC7489] has been mandated and .gov.example has published its own > > DMARC [RFC7489] record: > > > > "v=DMARC1;p=reject;rua=mailto:dm...@dmarc.service.gov.example"; > > > > Can we add spaces after the semicolons? I know this is legal format > > but it would be more readable. > > Changed. > > > This memo provides a simple extension to DMARC [RFC7489] to allow > > > > s/memo/document/g > > Changed throughout. > > > operators of Public Suffix Domains (PSDs) to express policy for > > groups of subdomains, extends the DMARC [RFC7489] policy query > > > > "groups of subdomains" suggests the capability of creating a policy > > that applies to parts of the subtree only, or different policies for > > different parts of the subtree. If that's not what we're actually > > defining here, this should be reworded. > > OBE to previous comments. > > > As an additional benefit, the PSD DMARC extension will clarify > > > > s/will clarify/clarifies/ > > Changed. > > > existing requirements. Based on the requirements of DMARC [RFC7489], > > DMARC should function above the organizational level for exact domain > > matches (i.e. if a DMARC record were published for 'example', then > > mail from example@example should be subject to DMARC processing). > > Testing had revealed that this is not consistently applied in > > different implementations. PSD DMARC will help clarify that DMARC is > > > > s/will help clarify/clarifies/ > > Changed. > > > ....and saying it twice in the same paragraph is probably not necessary. > > And then deleted the sentence. > > > > not limited to organizational domains and their sub-domains. > > > > There are two types of Public Suffix Operators (PSOs) for which this > > extension would be useful and appropriate: > > > > o Branded PSDs (e.g., ".google"): These domains are effectively > > Organizational Domains as discussed in DMARC [RFC7489]. They > > control all subdomains of the tree. These are effectively private > > domains, but listed in the Public Suffix List. They are treated > > as Public for DMARC [RFC7489] purposes. They require the same > > protections as DMARC [RFC7489] Organizational Domains, but are > > currently excluded. > > > > How are they current excluded? Is this because they're on the PSL, so > > DMARC treats them differently? > > Yes. Per the DMARC definition, they are not organizational domains. > > > o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): > > Because existing Organizational Domains using this PSD have their > > own DMARC policy, the applicability of this extension is for non- > > existent domains. The extension allows the brand protection > > benefits of DMARC [RFC7489] to extend to the entire PSD, including > > cousin domains of registered organizations. > > > > An example would be useful here. > > I've added this: > > As an example, take the ".gov.example" described above and add that > for this entity emails about tax returns are sent from > tax.gov.example. It would not be surprising if fraudulent emails > were sent purporting to be from taxes.gov.example (taxes is a cousin > of tax - different enough to evade DMARC protection, but similar > enough to potentially confuse users). As defined in DMARC [RFC7489], > a DMARC record could be published for tax.gov.example, but there is > no general solution to publishing a DMARC policy to defend against > abuse of non-existent cousins such as taxes.gov.example. While an > explicit record could be published for this one domain, the universe > of possible cousins is such that this approach does not scale. > > How's that? > > > Due to the design of DMARC [RFC7489] and the nature of the Internet > > email architecture [RFC5598], there are interoperability issues > > associated with DMARC [RFC7489] deployment. These are discussed in > > Interoperability Issues between DMARC and Indirect Email Flows > > [RFC7960]. These issues are not applicable to PSDs, since they > > (e.g., the ".gov.example" used above) do not send mail. > > > > DMARC doesn't need to be followed by its RFC number every time. > > I went through and removed most of these. I tried to remove them so that it's > mostly there when talking about DMARC the RFC, not DMARC the protocol. > > > 2.2. Public Suffix Domain (PSD) > > > > The global Internet Domain Name System (DNS) is documented in > > numerous Requests for Comment (RFC). It defines a tree of names > > starting with root, ".", immediately below which are Top Level Domain > > names such as ".com" and ".us". They are not available for private > > registration. In many cases the public portion of the DNS tree is > > more than one level deep. PSD DMARC includes all public domains > > above the organizational level in the tree, e.g., ".gov.uk". > > > > I don't know what that last sentence means. PSD DMARC is an > > extension; how does it include domains? > > Deleted the sentence. I don't think it is necessary for the definition, so > let's not confuse things. > > > 2.4. Public Suffix Operator (PSO) > > > > A Public Suffix Operator manages operations within their PSD. > > > > s/their/its/; "operator" is singular. > > Changed. > > > 2.6. Non-existent Domains > > > > For DMARC [RFC7489] purposes, a non-existent domain is a domain name > > that publishes none of A, AAAA, or MX records that the receiver is > > willing to accept. This is a broader definition than that in > > NXDOMAIN [RFC8020]. > > > > Is there any discussion that could be referenced about DNS RRs that > > one is not willing to accept? > > OBE. Removed that from the definition based on the WGLC discussion about the > definition. > > > 3.2. Section 6.1 DMARC Policy Record > > > > PSD DMARC records are published as a subdomain of the PSD. For the > > PSD ".example", the PSO would post DMARC policy in a TXT record at > > "_dmarc.example". > > > > Don't you mean the PSD DMARC record is a record in the zone of the > > PSD? It's not a subdomain. > > Here's what's in RFC 7489 about DMARC record publishing: > > 6.1. DMARC Policy Record > > Domain Owner DMARC preferences are stored as DNS TXT records in > subdomains named "_dmarc". For example, the Domain Owner of > "example.com" would post DMARC preferences in a TXT record at > "_dmarc.example.com". > > I think our 3.2 is equivalent and adequate given this section is a > modification > to RFC 7489 Section 6.1. I did not make a change. > > > 3.3. Section 6.5. Domain Owner Actions > > > > In addition to the DMARC [RFC7489] domain owner actions, PSOs that > > require use of DMARC ought to make that information available to > > receivers. > > By what mechanism? > > Changed to: > > In addition to the DMARC domain owner actions, PSOs that require use > of DMARC and participate in PSD DMARC ought to make that information > available to receivers. The mechanism for doing so is one of the > experimental elements of this document. See the experiment > description (Appendix A). > > > 3.4. Section 6.6.3. Policy Discovery > > > > A new step between step 3 and 4 is added: > > > > 3A. If the set is now empty and the longest PSD (Section 2.3) of the > > Organizational Domain is one that the receiver has determined is > > acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for > > a DMARC TXT record at the DNS domain matching the longest PSD > > (Section 2.3) in place of the RFC5322.From domain in the message > > (if different). A possibly empty set of records is returned. > > > > Section 6.6.3 of DMARC doesn't talk about "acceptable for DMARC", so I > > don't know what "acceptable for PSD DMARC" might mean. > > Changed to: > > 3A. If the set is now empty and the longest PSD (Section 2.3) of the > Organizational Domain is one that the receiver has determined is > acceptable for PSD DMARC (discussed in the experiment description > (Appendix A)), the Mail Receiver MUST query the DNS for a DMARC > TXT record at the DNS domain matching the longest PSD > (Section 2.3) in place of the RFC5322.From domain in the message > (if different). A possibly empty set of records is returned. > > > Section numbers in the prose of this section should make clear which > > document they're referencing. > > I checked and any reference to an RFC7489 paragraph number that's in the text > is labeled as such. > > > > 3.5. Section 7. DMARC Feedback > > > > Operational note for PSD DMARC: For PSOs, feedback for non-existent > > domains is desired and useful. See Section 4 for discussion of > > Privacy Considerations. > > > > Section 4 of which document? > > Added 'of this document'. > > > 4. Privacy Considerations > > > > These privacy considerations are developed based on the requiremetns > > > > typo > > > > of [RFC6973]. The Privacy Considerations of [RFC7489] apply to this > > document. > > > > 4.1. Feedback leakage > > > > Providing feedback reporting to PSOs can, in some cases, create > > leakage of information outside of an organization to the PSO. This > > leakage could be potentially be utilized as part of a program of > > > > Remove one of the "be"s. > > Fixed. > > > pervasive surveillance (See [RFC7624]). There are roughly three > > cases to consider: > > > > o Single Organization PSDs (e.g., ".google"), RUA and RUF reports > > based on PSD DMARC have the potential to contain information about > > emails related to entities managed by the organization. Since > > both the PSO and the Organizational Domain owners are common, > > there is no additional privacy risk for either normal or non- > > existent Domain reporting due to PSD DMARC. > > > > o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): > > PSD DMARC based reports will only be generated for domains that do > > not publish a DMARC policy at the organizational or host level. > > For domains that do publish the required DMARC policy records, the > > feedback reporting addresses (RUA and RUF) of the organization (or > > hosts) will be used. The only direct feedback leakage risk for > > these PSDs are for Organizational Domains that are out of > > compliance with PSD policy. Data on non-existent cousin domains > > would be sent to the PSO. > > > > This is the second use of "cousin domain". An example here or at the > > first use might be a good idea. > > Added at first use. > > And that's the last comment. > > I intend to post a revision shortly so the group can more easily review my > proposed changes based on WGLC. > > Scott K > > > _______________________________________________ > 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
