Re: [dmarc-ietf] Tree walk in -06
On March 24, 2022 12:01:39 PM UTC, 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. Based on the current draft, this is not correct. An exact match is the org domain, even if PSD=y, so even if the policy uses the relaxed alignment approach, it will still be aligned. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk in -06
On March 24, 2022 6:53:13 PM UTC, John Levine wrote: >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. I've revised my opinion based on the discussion. I agree this is the way to go. I'll put together some words in the next day or three. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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
Re: [dmarc-ietf] Tree walk in -06
At one point, Ale had suggested a fourth state, for "Both", when an organization boundary exists above (to a PSO) and below (for private registrations.) We can finesse that by ignoring the "boundary below" indicator when the evaluation does not move up from below. 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 configuraion. A "sendsmail=(y,n)" indicator would accomplish this purpose. For "psd=y" records, the default will be "sendsmail=n", while for other records the default will be "sendsmail=y". This ensures that most participants do not need to publish the indicator. It has two expected uses: - "sendsmail=y" For private registrars to indicate that they also send mail from the "psd=y" domain name, and - "sendsmail=n" For an organization that only sends mail from subdomains, and wants to strongly protect the organizational domain from impersonation. Doug On Wed, Mar 23, 2022 at 6:37 AM Alessandro Vesely wrote: > On Tue 22/Mar/2022 18:35:03 +0100 Ken O'Driscoll wrote: > >> > >> I don't think there is any other place where the default is not one of > >> the explicit options. The benefit of psd=u, such as it might be, is to > >> make it more consistent, and to be clear that we really mean it when we > >> say that psd=y, psd=n. and psd=u mean three different things. > >> > >> This is not a big deal but I do think I've seen confusion, e.g., people > >> wrongly concluding that all existing DMARC records will have to have > >> psd=n added. (I suppose those people will now demand psd=u, so you can't > >> win.) > > > > +1 > > > > Having different behaviour for the absence of the tag and the default > value will be unnecessarily confusing and not intuitive. > > > +1, I don't agree so much on obscuring the actual meaning, but since there > are > (at least) three states, enumerating three values is clear-headed. > > > 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 Tue 22/Mar/2022 18:35:03 +0100 Ken O'Driscoll wrote: I don't think there is any other place where the default is not one of the explicit options. The benefit of psd=u, such as it might be, is to make it more consistent, and to be clear that we really mean it when we say that psd=y, psd=n. and psd=u mean three different things. This is not a big deal but I do think I've seen confusion, e.g., people wrongly concluding that all existing DMARC records will have to have psd=n added. (I suppose those people will now demand psd=u, so you can't win.) +1 Having different behaviour for the absence of the tag and the default value will be unnecessarily confusing and not intuitive. +1, I don't agree so much on obscuring the actual meaning, but since there are (at least) three states, enumerating three values is clear-headed. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk in -06
This is not a new question, nor should it be a difficult one. Absence of an indicator means only one of these possibilities: that the DMARC policy was implemented before DMARCbis was published, or implemented without reading DMARCbis, or implemented by a lazy domain owner. If the specification says that absence of an indicator means that the domain owner chose to communicate a non-boundary status for the policy, then the specification is lying. The only way a domain owner communicates intent is by publishing information. Missing data is always NULL. You can guess intent from other clues, but not from the missing data. There is no default value, only missing data. Doug On Tue, Mar 22, 2022 at 7:28 AM Barry Leiba wrote: > Yes, I thought about that too: just omit psd rather than explicit > psd=u. Is there a reason not to do that? What's the value of > explicit psd=u, as long as the spec says what absent psd means? > > b > > On Tue, Mar 22, 2022 at 5:20 AM Scott Kitterman > wrote: > > > > > > > > On March 22, 2022 2:47:37 AM UTC, John Levine wrote: > > >I took a look and I think we're pretty close. I have two related > > >suggestions. > > > > > >It is confusing that the default for psd is psd=n but an explicit > > >psd=n isn't the same as no psd. So I suggest allowing threee values > > >for psd=y/n/u with "u" for unspecified being the default. > > > > > >In the three numbered steps in sec 4.8 it says first to look for any > psd=n, > > >then any for psd=y. Consider this somewhat contrived case: > > > > > >x.a.b.c.d.e v=DMARC1; > > >b.c.d.e v=DMARC1; psd=y > > >c.d.e(nothing) > > >d.e v=DMARC1; psd=n > > >e(nothing) > > > > > >The current text says the org domain would be d.e but I think we want > > >it to be a.b.c.d.e. > > > > > >The fix is simple, combine the first two steps so you stop at the > > >longest label with psd=y OR psd=n, and it's that label if psd=n or > > >the one below if it's psd=y. Arcane sort of special case, if the > > >original domain has a psd=y/n, that's the org domain and no tree walk > > >is needed. > > > > Thanks. I agree that's the right answer. I'll take another shot at it. > > > > I had considered just saying there's no default, but I guess using "u" > works too if you think that's better. > > > > Scott K > > > > ___ > > 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 > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk in -06
> > I don't think there is any other place where the default is not one of > the explicit options. The benefit of psd=u, such as it might be, is to > make it more consistent, and to be clear that we really mean it when we > say that psd=y, psd=n. and psd=u mean three different things. > > This is not a big deal but I do think I've seen confusion, e.g., people > wrongly concluding that all existing DMARC records will have to have > psd=n added. (I suppose those people will now demand psd=u, so you can't > win.) +1 Having different behaviour for the absence of the tag and the default value will be unnecessarily confusing and not intuitive. Ken. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk in -06
It appears that Barry Leiba said: >Yes, I thought about that too: just omit psd rather than explicit >psd=u. Is there a reason not to do that? What's the value of >explicit psd=u, as long as the spec says what absent psd means? I don't think there is any other place where the default is not one of the explicit options. The benefit of psd=u, such as it might be, is to make it more consistent, and to be clear that we really mean it when we say that psd=y, psd=n. and psd=u mean three different things. This is not a big deal but I do think I've seen confusion, e.g., people wrongly concluding that all existing DMARC records will have to have psd=n added. (I suppose those people will now demand psd=u, so you can't win.) R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk in -06
I haven't come up with anything. Anyone? Scott K On March 22, 2022 11:27:46 AM UTC, Barry Leiba wrote: >Yes, I thought about that too: just omit psd rather than explicit >psd=u. Is there a reason not to do that? What's the value of >explicit psd=u, as long as the spec says what absent psd means? > >b > >On Tue, Mar 22, 2022 at 5:20 AM Scott Kitterman wrote: >> >> >> >> On March 22, 2022 2:47:37 AM UTC, John Levine wrote: >> >I took a look and I think we're pretty close. I have two related >> >suggestions. >> > >> >It is confusing that the default for psd is psd=n but an explicit >> >psd=n isn't the same as no psd. So I suggest allowing threee values >> >for psd=y/n/u with "u" for unspecified being the default. >> > >> >In the three numbered steps in sec 4.8 it says first to look for any psd=n, >> >then any for psd=y. Consider this somewhat contrived case: >> > >> >x.a.b.c.d.e v=DMARC1; >> >b.c.d.e v=DMARC1; psd=y >> >c.d.e(nothing) >> >d.e v=DMARC1; psd=n >> >e(nothing) >> > >> >The current text says the org domain would be d.e but I think we want >> >it to be a.b.c.d.e. >> > >> >The fix is simple, combine the first two steps so you stop at the >> >longest label with psd=y OR psd=n, and it's that label if psd=n or >> >the one below if it's psd=y. Arcane sort of special case, if the >> >original domain has a psd=y/n, that's the org domain and no tree walk >> >is needed. >> >> Thanks. I agree that's the right answer. I'll take another shot at it. >> >> I had considered just saying there's no default, but I guess using "u" works >> too if you think that's better. >> >> Scott K >> >> ___ >> 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk in -06
Yes, I thought about that too: just omit psd rather than explicit psd=u. Is there a reason not to do that? What's the value of explicit psd=u, as long as the spec says what absent psd means? b On Tue, Mar 22, 2022 at 5:20 AM Scott Kitterman wrote: > > > > On March 22, 2022 2:47:37 AM UTC, John Levine wrote: > >I took a look and I think we're pretty close. I have two related > >suggestions. > > > >It is confusing that the default for psd is psd=n but an explicit > >psd=n isn't the same as no psd. So I suggest allowing threee values > >for psd=y/n/u with "u" for unspecified being the default. > > > >In the three numbered steps in sec 4.8 it says first to look for any psd=n, > >then any for psd=y. Consider this somewhat contrived case: > > > >x.a.b.c.d.e v=DMARC1; > >b.c.d.e v=DMARC1; psd=y > >c.d.e(nothing) > >d.e v=DMARC1; psd=n > >e(nothing) > > > >The current text says the org domain would be d.e but I think we want > >it to be a.b.c.d.e. > > > >The fix is simple, combine the first two steps so you stop at the > >longest label with psd=y OR psd=n, and it's that label if psd=n or > >the one below if it's psd=y. Arcane sort of special case, if the > >original domain has a psd=y/n, that's the org domain and no tree walk > >is needed. > > Thanks. I agree that's the right answer. I'll take another shot at it. > > I had considered just saying there's no default, but I guess using "u" works > too if you think that's better. > > Scott K > > ___ > 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 March 22, 2022 2:47:37 AM UTC, John Levine wrote: >I took a look and I think we're pretty close. I have two related >suggestions. > >It is confusing that the default for psd is psd=n but an explicit >psd=n isn't the same as no psd. So I suggest allowing threee values >for psd=y/n/u with "u" for unspecified being the default. > >In the three numbered steps in sec 4.8 it says first to look for any psd=n, >then any for psd=y. Consider this somewhat contrived case: > >x.a.b.c.d.e v=DMARC1; >b.c.d.e v=DMARC1; psd=y >c.d.e(nothing) >d.e v=DMARC1; psd=n >e(nothing) > >The current text says the org domain would be d.e but I think we want >it to be a.b.c.d.e. > >The fix is simple, combine the first two steps so you stop at the >longest label with psd=y OR psd=n, and it's that label if psd=n or >the one below if it's psd=y. Arcane sort of special case, if the >original domain has a psd=y/n, that's the org domain and no tree walk >is needed. Thanks. I agree that's the right answer. I'll take another shot at it. I had considered just saying there's no default, but I guess using "u" works too if you think that's better. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk in -06
I took a look and I think we're pretty close. I have two related suggestions. It is confusing that the default for psd is psd=n but an explicit psd=n isn't the same as no psd. So I suggest allowing threee values for psd=y/n/u with "u" for unspecified being the default. In the three numbered steps in sec 4.8 it says first to look for any psd=n, then any for psd=y. Consider this somewhat contrived case: x.a.b.c.d.e v=DMARC1; b.c.d.e v=DMARC1; psd=y c.d.e(nothing) d.e v=DMARC1; psd=n e(nothing) The current text says the org domain would be d.e but I think we want it to be a.b.c.d.e. The fix is simple, combine the first two steps so you stop at the longest label with psd=y OR psd=n, and it's that label if psd=n or the one below if it's psd=y. Arcane sort of special case, if the original domain has a psd=y/n, that's the org domain and no tree walk is needed. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
