On Saturday, July 16, 2022 7:50:04 AM EDT Alessandro Vesely wrote: > Alleluia! > > Couple of notes below: > > On Sat 16/Jul/2022 09:17:54 +0200 Scott Kitterman wrote: > > When I have implemented RFCs in the past, I have found the examples to be > > critical to making sure I understand the RFC correctly. Generally, among > > my first goals is to ensure I can replicate the examples. There has been > > enough back and forth on the list about how the tree walk does/does not > > work (with examples) that I think we should have specific examples for > > this. > > > > I think that it would best fit in B.3. Mail Receiver Example as a new > > B.3.2. Here's an initial shot at it: > > > > B.3.2 Organizational and Policy Domain Examples > > > > B.3.2.1 Simple Organizational and Policy Example > > > > A mail receiver receives an email with 5322.From domain = example.com, > > 5322.MailFrom domain = example.com, and a DKIM signature with d = > > signing.example.com. _dmarc.example.com and _dmarc.signing.example.com > > both have DMARC records (_dmarc.com does not). If SPF or DKIM yield pass > > results, they still have to be aligned to support a DMARC pass. Since > > not all domains are the same, if the alignment is relaxed then the tree > > walk is performed to > > determine the organizational domain for each: > Perhaps a table would be more readable? > > > 5322.From: query _dmarc.example.com and _dmarc.com; example.com is the > > last > > element of the DNS tree with a DMARC record, so it is the organizational > > domain for example.com. > > > > 5322.MailFrom: Already determined organizational domain for example.com is > > example. com. SPF is aligned. > > > > DKIM d= domain: query _dmarc.signing.example.com, _dmarc.example.com, and > > _dmarc.com. Both signing.example.com and example.com have DMARC records, > > but example.com is the highest element in the tree with a DMARC record, > > so example.com is the organizational domain. Since this is also the > > organizational domain for 5322.From, DKIM is aligned for relaxed > > alignment. > > > > Since both SPF and DKIM are aligned, they can be used to determine if the > > message has a DMARC pass result. If the result is not pass, then the > > policy domain's DMARC record is used to determine the appropriate policy. > > In this case, since the 5322.From domain has a DMARC record, that is the > > policy domain. > > I'd assume all identifiers are validated, so you can simply say > "pass". There is nothing to do with failed DKIM/SPF results. > > > B.3.2.2 Deep Tree Walk Example > > > > A mail receiver receives an email with 5322.From domain = > > a.b.c.d.e.f.g.h.i.j.k.example.com, 5322.MailFrom domain = example.com, and > > a DKIM signature with d = signing.example.com. _dmarc.example.com and > > _dmarc.signing.example.com both have DMARC records (_dmarc.com does not). > > If SPF or DKIM yield pass results, they still have to be aligned to > > support a DMARC pass. Since not all domains are the same, if the > > alignment is relaxed then the tree walk is performed to determine the > > organizational domain for each: > > > > 5322.From: query _dmarc.a.b.c.d.e.f.g.h.i.j.k.example.com, skip to > > _dmarc.j.k.example.com, then query _dmarc.k.example.com, > > _dmarc.example.com, and _dmarc.com. None of > > a.b.c.d.e.f.g.h.i.j.k.example.com, j.k.example.com, or k.example.com have > > a DMARC record. example.com is the last element of the DNS tree with a > > DMARC record, so it is the organizational domain for example.com. > > > > 5322.MailFrom: Already determined organizational domain for example.com is > > example. com. SPF is aligned. > > > > DKIM d= domain: query _dmarc.signing.example.com, _dmarc.example.com, and > > _dmarc.com. Both signing.example.com and example.com have DMARC records, > > but example.com is the highest element in the tree with a DMARC record, > > so example.com is the organizational domain. Since this is also the > > organizational domain for 5322.From, DKIM is aligned for relaxed > > alignment. > > d=signing.example.com was already discussed. > > > Since both SPF and DKIM are aligned, they can be used to determine if the > > message has a DMARC pass result. If the result is not pass, then the > > policy domain's DMARC record is used to determine the appropriate policy. > > In this case, the 5322.From domain does not have a DMARC record, so the > > policy domain is the highest element in the DNS tree with a DMARC record, > > example.com. > > > > B.3.2.3 PSD Example > > > > A mail receiver receives an email with 5322.From domain = > > notyourbank.example, 5322.MailFrom domain = notyourbank.example, and a > > DKIM signature with d = notyourbank.example. _dmarc.notyourbank.example > > does not have a DMARC record. and _dmarc.example has a DMARC record which > > includes the psd=y tag/value. Since all three domains are the same, they > > are aligned (strict or relaxed). > > > > Since both SPF and DKIM are aligned, they can be used to determine if the > > message has a DMARC pass result. If the result is not pass, then the > > policy domain's DMARC record is used to determine the appropriate policy. > > In this case, the 5322.From domain does not have a DMARC record, so the > > policy domain is the highest element in the DNS tree with a DMARC record, > > example. > > > > Because the _dmarc.example record has psd=y it is only used for > > determining > > the policy domain, not for organizational domain determination. > > > > How's that? > > I'd try and expose the cases more synoptically, to ease reading. > > The more cases the better. Mail.notyourbank.example, "private" PSDs, > d=. and other corner cases?
Regarding a table, I don't have a strong opinion on format. If someone wants to rework these into a different format that might be more readable, I'd say go for it and we'll see what the WG thinks. Regarding failed SPF/DKIM, I don't think you can assume for purposes of the example that both pass, since it's only in the failure case that DMARC policy is relevant. Finally, I disagree that more examples is unequivocally better. I think that an example for every single case we can think of would lead to more confusion. I selected the examples I included to demonstrate: 1. Most common case with a bit of subdomain usage added to demonstrate the basics of the tree walk. 2. A deep tree case to show the jump. This is an important concept for DoS resistance, since I can easily see attackers trying a large number of sub- labels to see if that causes the DMARC check to be skipped. 3. A PSD example, since that's a new concept relative to RFC 7489. By d=, I expect you mean a DKIM signature with an empty d=? I don't think that has anything to do with DMARC. To be relevant for DMARC a DKIM signature has to verify. With no signing domain, that won't happen. I think examples should be illustrative without being overwhelming. If someone wants to work out the examples for every single case they can think of and publish on a web site somewhere, I think that would be great. I don't think it belongs in the RFC. In addition to the potential for confusion with too many examples, I also think it's likely if we attempt to be comprehensive we'll miss something so an attempt at being comprehensive is better located somewhere that it can be revised. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
