Re: [dmarc-ietf] Tree walk in -06
Couple of corrections and extensions to the previous note: The applies only if it is the first policy found, and the next lower name, which has no policy, is the organization domain. If an untagged policy immediately precedes the , then the cached domain is the organization domain and the cached policy is the default policy. If a gap exists between an untagged policy and the , then the results are ambiguous. - - - If an exact-match policy is found, and the organization domain is still needed for relaxed alignment, then the current domain is cached as a candidate organization domain. The default policy is not needed. If an exact-match policy is not found, then the cache begins empty. It will be initialized when the first untagged policy is found. If no policy is found at any level, then the domain does not participate in DMARC and the DMARC result is NULL. DF On Thu, Mar 24, 2022 at 6:04 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Since some of you have a default value, and I do not, we must not have a > shared understanding of the underlying algorithm. I will document mine, > perhaps one of you can explain your alternative. > > Since we lack consensus about psd=(y|n|u), I will use symbolic tokens, > with these equivalences: > > (psd=y) > > (psd=n) > > (psd=u) > > > > My Algorithm: > > > > Primary Tree Walk > > The primary tree walk searches for the Organization Domain of the From > address. > > When an untagged policy is found, the name and policy are cached as > candidates for the organizational domain and default policy. The walk > proceeds up the tree. > > If the next domain upward is untagged, it is ignored and the walk proceeds > up the tree with the cached information from previous steps. > > If the next policy found is also untagged, the previous policy is > interpreted as a and therefore not of interest. > The current domain and policy are cached as the new candidates for > organizational domain and default policy. The walk proceeds. > > If the next policy found is tagged as , > then the cached domain and policy are interpreted as a policy> and therefore not of interest. The current domain and policy > become the confirmed organizational domain and default policy. The walk > terminates. > > After an untagged policy, if the next domain up the tree is tagged as a > , then the cached domain is the organization domain and > the current domain is the default policy. However, if there is > an intervening domain with no policy, the results are ambiguous. The > organization and its registrar are not compliant with DMARCbis. Either > way, the walk terminates. > > After an untagged policy, if the walk proceeds all the way to the TLD > without finding another policy, then the cached domain and policy are > selected as the organizational domain and policy. > > > > Secondary Tree Walk > > The secondary tree walk checks for presence or absence of a private > registrar between the candidate domain and the From address organizational > domain. Private registrations can only be detected if their policies are > explicitly tagged. > > Consequently, a domain without a policy, a domain tagged with a > policy, or a domain with an untagged policy are treated > equally. Alignment is not disproven, so the walk continues up the tree to > the termination point. > > If any domains are tagged as or policy>, then the domains are not aligned and the walk terminates so that > the next candidate domain can be evaluated. > > > > Doug Foster > > On Thu, Mar 24, 2022 at 1:45 PM Murray S. Kucherawy > wrote: > >> On Tue, Mar 22, 2022 at 10:35 AM Ken O'Driscoll > 40wemonitoremail@dmarc.ietf.org> wrote: >> >>> Having different behaviour for the absence of the tag and the default >>> value will be unnecessarily confusing and not intuitive. >>> >> >> I'm confused. In the absence of the tag, don't you apply the default? >> That is, aren't these necessarily the same thing? >> >> -MSK >> ___ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk in -06
Since some of you have a default value, and I do not, we must not have a shared understanding of the underlying algorithm. I will document mine, perhaps one of you can explain your alternative. Since we lack consensus about psd=(y|n|u), I will use symbolic tokens, with these equivalences: (psd=y) (psd=n) (psd=u) My Algorithm: Primary Tree Walk The primary tree walk searches for the Organization Domain of the From address. When an untagged policy is found, the name and policy are cached as candidates for the organizational domain and default policy. The walk proceeds up the tree. If the next domain upward is untagged, it is ignored and the walk proceeds up the tree with the cached information from previous steps. If the next policy found is also untagged, the previous policy is interpreted as a and therefore not of interest. The current domain and policy are cached as the new candidates for organizational domain and default policy. The walk proceeds. If the next policy found is tagged as , then the cached domain and policy are interpreted as a and therefore not of interest. The current domain and policy become the confirmed organizational domain and default policy. The walk terminates. After an untagged policy, if the next domain up the tree is tagged as a , then the cached domain is the organization domain and the current domain is the default policy. However, if there is an intervening domain with no policy, the results are ambiguous. The organization and its registrar are not compliant with DMARCbis. Either way, the walk terminates. After an untagged policy, if the walk proceeds all the way to the TLD without finding another policy, then the cached domain and policy are selected as the organizational domain and policy. Secondary Tree Walk The secondary tree walk checks for presence or absence of a private registrar between the candidate domain and the From address organizational domain. Private registrations can only be detected if their policies are explicitly tagged. Consequently, a domain without a policy, a domain tagged with a policy, or a domain with an untagged policy are treated equally. Alignment is not disproven, so the walk continues up the tree to the termination point. If any domains are tagged as or , then the domains are not aligned and the walk terminates so that the next candidate domain can be evaluated. Doug Foster On Thu, Mar 24, 2022 at 1:45 PM Murray S. Kucherawy wrote: > On Tue, Mar 22, 2022 at 10:35 AM Ken O'Driscoll 40wemonitoremail@dmarc.ietf.org> wrote: > >> Having different behaviour for the absence of the tag and the default >> value will be unnecessarily confusing and not intuitive. >> > > I'm confused. In the absence of the tag, don't you apply the default? > That is, aren't these necessarily the same thing? > > -MSK > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk in -06
It appears that Murray S. Kucherawy said: >-=-=-=-=-=- > >On Tue, Mar 22, 2022 at 10:35 AM Ken O'Driscoll 40wemonitoremail@dmarc.ietf.org> wrote: > >> Having different behaviour for the absence of the tag and the default >> value will be unnecessarily confusing and not intuitive. > >I'm confused. In the absence of the tag, don't you apply the default? >That is, aren't these necessarily the same thing? Currently, no. psd=n means one thing, psd=y means another thing, and no psd at all means a third. My suggestion is to allow explicit or default psd=u for the third thing. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk in -06
On Tue, Mar 22, 2022 at 10:35 AM Ken O'Driscoll wrote: > Having different behaviour for the absence of the tag and the default > value will be unnecessarily confusing and not intuitive. > I'm confused. In the absence of the tag, don't you apply the default? That is, aren't these necessarily the same thing? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk in -06
We know that DMARC Fail is a weak result because in-transit changes may cause a message that was verifiable at first hop to be unverifiable at last hop. Consequently, it is desirable to distinguish between Fail and Never-sends-mail. We should not assume that a domain sends mail simply because a message arrives with their name on it. Real PSOs never send mail, and I suspect that many private registries do not send mail from the specific subdomain used for client registration. So my default expectation for registrars is that they do not send mail, but we need a way for private registrars to announce that they are an exception On Thu, Mar 24, 2022, 8:02 AM Alessandro Vesely wrote: > On Wed 23/Mar/2022 12:08:16 +0100 Douglas Foster wrote: > > But we do have a difference between PSOs, which never send mail, and > private > > registrars, which may or may not send mail from the domain or subdomain > used as > > a private registration point. It seems desirable to resolve this > ambiguity so > > that we can reliably know that a true PSO cannot be impersonated, while > > allowing private registrars to document their configuration. > > > > A "sendsmail=(y,n)" indicator would accomplish this purpose. > > > For documentation purposes, although I'd have preferred meaningful, > explicit > tokens, if people much more experienced than me insist that obscurity is > advisable in this case, I don't agree but I accept it. > > For security, a private registrar should set psd=y. If it sets psd=n, it > forces all registrants below that point to do the same. If the From: > domain > has psd=y, you know that they send mail because you received it. In that > case, > it can only authenticate by strict alignment. > > Perhaps, we could advise private registrars that they had better use an > intermediate label with psd=y as a registration point if they want more > DMARC > flexibility at their base domain. > > > Best > Ale > -- > > > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk in -06
On Wed 23/Mar/2022 12:08:16 +0100 Douglas Foster wrote: But we do have a difference between PSOs, which never send mail, and private registrars, which may or may not send mail from the domain or subdomain used as a private registration point. It seems desirable to resolve this ambiguity so that we can reliably know that a true PSO cannot be impersonated, while allowing private registrars to document their configuration. A "sendsmail=(y,n)" indicator would accomplish this purpose. For documentation purposes, although I'd have preferred meaningful, explicit tokens, if people much more experienced than me insist that obscurity is advisable in this case, I don't agree but I accept it. For security, a private registrar should set psd=y. If it sets psd=n, it forces all registrants below that point to do the same. If the From: domain has psd=y, you know that they send mail because you received it. In that case, it can only authenticate by strict alignment. Perhaps, we could advise private registrars that they had better use an intermediate label with psd=y as a registration point if they want more DMARC flexibility at their base domain. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
