Under RFC 7489, the organizational domain provides the default policy for subdomains and the upper bound for relaxed alignment. The organizational domain is needed when (a) the From domain does not have a DMARC policy, or (b) the From domain policy allows relaxed alignment.
Scott's proposal seems to involve a walk up to determine the policy when an exact-match does not exist, and a second walk to determine the alignment boundary. Only one walk is needed, because they need to converge on the same point. I have argued that the one walk needs to be a walk up because we need to be concerned about both PSO registration boundaries and Private registration boundaries. John's proposal seems to ignore the problem of getting the organizational domain correct, and simply treat the first policy found as if it was reliably known to be the correct one. I can see many situations where this is unlikely to be the correct result, so I see no reason to believe that the proposal can or should survive the review process. To accurately identify PSD policies, we have two choices: - assume that PSDs will add the "psd=y" flag to their policies prior to publication, or - declare that the "NP" clause is the PSD indicator, meaning (a) it indicates that the first child domain without an NP term is an organizational domain, and that organization must pass an existence test to verify registration. (b) that the organizational domain is an upper bound for alignment. (c) that the SP clause of the PSD's DMARC record applies to the organization. We can create a different term, such as "NX=disposition", to be used on organizational DMARC records, with the interpretation that the FROM domain must pass an existence test. I think that separating the organizational existence test from the From domain existence test is desirable. The PSD non-existence test should not be used to impose a From domain existence test on registered organizations. Given John's concerns about getting PSDs to accurately publish the PSD flag, using NP as our PSD indicator seems preferable, because it is already deployed. The existence of private registries means that we also need to be concerned about a lower bound for relaxed alignment. This must also be addressed as part of the tree walks. Doug On Mon, Feb 21, 2022 at 1:07 PM John Levine <[email protected]> wrote: > It appears that Scott Kitterman <[email protected]> said: > >> I don't remember, perhaps someone else can remind us. In the situation > >> Mike's been warning about, the topmost record fails dangerously. > > > >As I understand it, yes, but I don't 100% agree that it's a protocol > problem. > >Typically if a company you have hired to do a job does so poorly, then > you > >hire someone else. I don't think it's possible to write protocol to > avoid > >problems like this entirely. > > In general I agree, but in the world of standards we have a very long tail > of > software that is updated very slowly. So I think our goal has to be that > the > results we get from the tree walk should be close to and no worse than what > came before. That has to apply to poorly configured systems, too, much > though > we'd prefer otherwise. (I would really like to require that every domain > that > receives mail has an MX, now that we've had a 40 year transition period, > but > it's not happening.) > > >Walking up the tree one would look for DMARC records in: > >_dmarc.sales.cust.us.com > >_dmarc.cust.us.com > > > >and then potentially: > > > >_dmarc.us.com > >_dmarc.com > > > >If us.com had published a DMARC record with psd=y, then we would know > for sure > >that cust.us.com is the org domain. I think when walking up you want > the first > >record for policy domain and the last non-PSD record for org domain. > > Now I'm confused. The policy and org domain used to be the same, but now > they > seem to be different. That's not necessarily wrong, but if we're going to > separate them, then we need to be crystal clear what the function of each > is. > > >In your example both the first DMARC record and the org domain are the > same, > >but imagine that later cust.us.com decided that for their sales > subdomain they > >needed a different handling policy, so a new DMARC record appears at > >_dmarc.sales.cust.us.com. If we take the first DMARC record as the org > domain, > >then it changes from cust.us.com to sales.cust.us.com. If they had been > using > >dkim.cust.us.com it would suddenly fail to align. I think this would be > a > >very surprising property of the system and not really what we are after. > > Conversely, as it stands now, us.com does not have a PSD flag so if we > take > your approach, foo.us.com and bar.us.com are aligned and there is nothing > either can do about it other than ask Centralnic to change their DMARC > record. > > Either way some people will be surprised. We need to consider both how > many > will be surprised, and the consequences of the surprise. Which is worse, > having > some currently aligned mail fail, or allowing a new class of phishes? > Neither > is great but the latter seems worse. > > >I do think that an exact match should always be used. For example, let's > >imagine the operators of us.com decide to use it in email for their own > email > >and publish a DMARC record, but they use psd=y so as to not disturb the > >alignment of their customer's mail. > > Yes, that seems right, although there is a surprisingly long set of 2LDs > that are PSDs and also have regular DMARC records now. > > R's, > John > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
