> On May 27, 2019, at 6:59 PM, Scott Kitterman <skl...@kitterman.com> wrote: > > On Monday, May 27, 2019 6:53:17 PM EDT 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 : DMARC (Domain-based Message Authentication, >> Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) >> Author : Scott Kitterman >> Filename : draft-ietf-dmarc-psd-04.txt >> Pages : 11 >> Date : 2019-05-27 > > There isn't much to this update. It corrects one typo and reverts the RUF > MUST NOT as discussed on the list. As far as I'm aware there are no other > pending issues in the WG with the draft.
Hi Scott, I've reviewed the doc and have made some comments. Feel free to dispose of them as you will. I had a hard time with the introduction. "sets of domains within a single organization" and "lower level policy" left me not knowing what I was reading. I'm unhappy just complaining, so I took a stab at this admittedly difficult section. The original: 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 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. This prevents policy application to non-existent domains and identification of domain abuse in email, which can be important for brand and consumer protection. My stab: 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 for organizational domains and their sub-domains within a single organization. For TLDs and domains that exist between TLDs and organization level domains, policy can only be published for the exact domain. No method is available for such domains to express policy or receive feedback reporting for sub-domains. This missing method allows for the abuse of non-existent organizational-level domains and prevents identification of domain abuse in email. The example section doesn't read like the rest of the draft and was hard for me to read through. Original: This would provide policy and feedback for mail sent from @gov.example, but not @tax.gov.example and there is no way to publish an organizational level policy that would do so. While, in theory, receivers could reject mail from non-existent domains, not all receivers do so. Non-existence of the sending domain can be a factor in a mail delivery decision, but is not generally treated as definitive on its own. Again my stab: This DMARC record provides policy and a reporting destination for mail sent from @gov.example. However, due to DMARC's current method of discovering and applying policy at the organizational domain level, the non-existent organizational domain of @tax.gov.example does not and cannot fall under a DMARC policy. I don't have too much more, I just got just caught up in the initial read. This paragraph contains a construct that was confusing to me: This memo provides a simple extension to DMARC [RFC7489] to allow operators of Public Suffix Domains (PSDs) to express policy for groups of subdomains, extends the DMARC [RFC7489] policy query functionality to detect and process such a policy, describes receiver feedback for such policies, and provides controls to mitigate potential privacy considerations associated with this extension. ^^^ why "groups of subdomains" and not just "subdomains"? One step further, why not "express policy at the level of the PSD that covers all organizational domains that do not explicitly publish DMARC records"? OK, two more things: 2.3. Longest PSD Organizational Domain (DMARC [RFC7489] Section 3.2) with one label removed. ^^^ "one left-most label removed"? Last thing: Security considerations might call out DNS cache poisoning as a way to get reports for a PSD. Applies to vanilla DMARC too, but the scope and potential breadth of information with PSD-DMARC is really interesting. I imagine an attack that gets .COM listed into the PSD Registry for a specific report generator.. combined with cache poisoning and the poor report generator would probably explode at best. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
