On Thu, Apr 05, 2018 at 07:22:37AM -0700, Peter M. Goldstein wrote: > On Thu, Apr 5, 2018 at 6:07 AM, Andrew Sullivan <[email protected]> > wrote: > > > Do you mean this _across_ TLDs (e.g. the "variants" case such as > > differnet spellings of China depending on the writing system) or do > > you just mean that the top most label and everything flowing down from > > there is all under the same policy? > > The latter. > > To be more clear, there are now a significant number of TLDs that are > managed exclusively by one entity (e.g. .microsoft, .google) as well as > other TLDs that make specific guarantees around DMARC (e.g. .bank). In > those cases it may make sense to give the registry owners some defined > mechanism for imposing global DMARC policy across the TLD. This is > especially important for organizational domain names that don't resolve for > that TLD. > > So, for example, let's consider an email seemingly sent from > [email protected] . A query to the domain iamareal.bank returns an > NXDOMAIN, as does the a TXT query to the corresponding DMARC record > _dmarc.iamareal.bank domain. So there's no DMARC policy in place. So a > receiver may wind up delivering this email to the inbox, especially if it > passes SPF and DKIM in an unaligned fashion. > > But to an end user it looks like this is an email from a '.bank' domain, > which undermines the .bank TLDs goal of providing a higher trust set of > domains. And it is therefore attractive to bad actors as a possible > channel of abuse. > > The question is whether the DMARC lookup scheme should somehow address this > issue. Alternately, we could simply say that this is a case that DMARC > itself doesn't handle, and that the registry owner may choose to modify > their DNS responses to ensure they always return a DMARC record for any > organizational domain on that TLD. My initial thought was that handling this in DMARC would be unnecessary, since mail from nonexistent domains can be rejected without needing an opt-in compliance record. However, that thought completely neglected the "R" portion of DMARC, and I can certainly see how including attempts from nonexistent domains in aggregate reports would be useful. Further, while the requirement that RFC5321.MailFrom domains be resolvable is codified in section 2.3.5 of that RFC, a similar explicit requirement for the RFC5322.From address was deliberately removed from the DMARC spec (see https://tools.ietf.org/html/rfc7489#appendix-A.4).
Absent a better way to determine domain ownership boundaries than the current heuristic, I don't think the resolution for domains that exist should be altered. Domains should retain the ability to opt out of DMARC by not publishing a DMARC record, rather than being unexpectedly affected by one that their TLD or other public suffix has chosen to publish. Requiring that pseudo-public suffixes like .google publish DMARC records for their valid Organizational Domains doesn't seem onerous. I would suggest that if there's no policy found for the two domains that are currently checked, the receiver should attempt to resolve those domains (checking for MX or address records, or a CNAME that points to a name with MX or address records), and only if they cannot be resolved move on to querying the name that matched from the public suffix list. This represents a significant increase in the number of DNS queries required to process a nonexistent domain, but I think it's the best balance between retaining the opt-in nature of DMARC and allowing public suffixes to publish DMARC policies for nonexistent domains in their namespace. -- Zeke Hendrickson ([email protected]) University of Michigan | Information and Technology Services Infrastructure | Application Operations | Application Delivery Support _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
