On Saturday, July 16, 2022 11:39:31 AM EDT Alessandro Vesely wrote: > On Sat 16/Jul/2022 16:43:02 +0200 Scott Kitterman wrote: > > On Saturday, July 16, 2022 7:50:04 AM EDT Alessandro Vesely wrote>> > > > >> [...] > >> > >>> 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? > >> > >>> [...] > >>> > >>> 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. > >> > >>> [...] > >>> > >>> 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. > > Albeit the examples differ, consider my attempt in the last part of message: > https://mailarchive.ietf.org/arch/msg/dmarc/L9kHlE_zre3sOKn-m6p400yJDuw It > features an initial description of the DNS landscape and a synoptic table > for each case.
I'll leave the formatting to the document authors. I don't have a real opinion on it. What I provided makes sense to me, but then it would since I wrote it. > Those tables could be bettered by adding the alignment status of each > identifier. > > 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. > > Right, but here we're exemplifying the tree walk, not policy application. > (More in the d= case below.) > > 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. > What if you're developing the spec and are dealing with a dubious case? The > ability to find the right example is key. > > 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. > > Consider Case 2 in the examples I made in the aforementioned message. > Cannot one find it dubious? One might, but the point of it is that unlike a d= domain from a signature that passes DKIM verification of a 5321.MailFrom domain that passes SPF, the 5322.From domain is entirely under the control of the sender, who might be malicious. I felt it was worth pointing out that the design is such that this sort of approach will not cause problems for the protocol. If others feel it's a corner case we don't need, I have no problem with dropping it. > > 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. > > Correct. (Hence you can assume SPF and DKIM verification passed.) > > However, if you're coding the tree walk, d=; forces you to consider the > assumptions you need to put on the input domain. Namely, it must neither > be the root nor a PSD. Right? No. It doesn't come up. In 4.8, the input to the tree walk is "Any DKIM d= domain if there is a DKIM pass result for the message for that domain." A null d= can never verify, so it should never be used for the tree walk. > > 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. > > Hm.. maybe. In any case, it'd be preferable to draft many examples and > eventually eliminate the ones which are obviously bad. In the mean time, > they might be useful for the WG to better focus on the tree walk, until we > all stop switching between ducks and rabbits. Personally, I think it's done and has been for awhile. I'd like to see these examples (or a subset of them if people don't like example 2) get into the document in some form so we have some examples and then move on to the next topic. There's no shortage of stuff to do. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
