On Friday, February 11, 2022 1:25:15 PM EST John Levine wrote: > It appears that Alessandro Vesely <[email protected]> said: > >I think it is already clear to the WG that the tree walk is screwed up. > > Yes, we know we have to rewrite sections 4.5 and 4.6. > > I think there are 2 1/2 situations we need to look at. > > The first is finding the policy record for a domain that does not have its > own DMARC record. That seems easy, walk up five levels and stop at the > first DMARC record, which is your policy record. For this purpose it > doesn't matter whether the domain says psd=y. I suppose that it if doesn't > have psd=y, you can call the domain with the record the org domain. > > The second is deciding whether two diffent domains are in relaxed alignment. > This has an easier case and a harder one. > > The easier case is when one domain is a subdomain of the other. You look at > the domains between the two and they are in relaxed alignment if one of > these is true but I'm not sure which one: > > a. there are no DMARC records at all > b. there are no DMARC records witn psd=y > > I don't think there is a lot of practical difference between the two. If > you don't find a record, there is no policy and no org domain. > > The harder case when the domains are siblings, or maybe a great aunt. > Possibilities: > > a. they are never aligned. This would be the easiest, but would in > principle be a significant change from the current spec. Does anyone know > in practice how often mail uses sibling alignment? > > b. walk up from both, stop at the first DMARC record. If they're at > the same name and it's not a PSD, they are aligned and that's the org domain > > b+. walk up from both, if the DMARC records are at the same name, it has > psd=y, and they have the same name below the PSD, they are aligned and the > name below the PSD is the org domain > > c and c+. like b or b+ but allow other non-PSD DMARC records below the org > domain. > > I lean toward "a" if we believe that sibling alignment is rarely used, > otherwise b. I don't like b+ or c+ because I think it is reasonable to > expect mailers who depend on an org domain to publish a record there, > although I do not think an org=y flag would be useful, since it would break > existing org domain records that don't have the flag.
I think "a" would be cleanest, but I think it would cause too much backward compatibility trouble and should not be further considered. In previous working group discussions on this I recall specific suggestions that this would be problematic and this is supported by the short survey that Elizabeth Zwicky reported on. I think a challenge with your definition for "b" and "c" is that there aren't necessarily two domains at issue. It could be three. If you take the DKIM signing domain and the 5322.From domains as an input that might yield a different "org domain' than is yielded by the 5321.Mailfrom domain and the 5322.From domain (for SPF). I'm not sure it matters in practice for relaxed alignment since if either DKIM or SPF passes and is aligned it's a DMARC pass. >From a protocol specification perspective it's different from RFC 7489. In >RFC 7489, organization domain is determined from a single input and the results (do they have the same organizational domain) are compared. In RFC 7489, you can determine the org domain from any single domain. I think it would be useful to preserve this property. I think we can do this either by walking up to the last domain with a non-PSD DMARC record or by walking down to the first domain with a non-PSD DMARC record (I made an admittedly poor first attempt at this that's in the current draft). I don't think it matters much which direction the lookup goes, so I'm fine with whatever the group prefers. I do think though that we should preserve the concept of organizational domain as something that can be determined from a single input. If we preserve that property of organizational domain, I think the risk of backward compatibility issues is lower. Also, we could, if the group supports it, outsource this definition to a separate draft as Dave Crocker has suggested. In that case, DMARCbis would only have to say to determine the organizational domain and the rest is external to that document. I support the idea of a separate draft, but I don't think it's essential to making progress on DMARCbis. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
