Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
On July 20, 2022 2:49:47 AM UTC, John Levine wrote:
>It appears that Scott Kitterman said:
>>The PSD definition is probably overlong already:
>>
>>> 3.2.8. Public Suffix Domain (PSD)
>>>
>>>The global Internet Domain Name System (DNS) is documented in
>>>numerous RFCs. It defines a tree of names starting with root, ".",
>>>immediately below which are Top-Level Domain names such as ".com" and
>>>".us". The domain name structure consists of a tree of names, each
>>>of which is made of a sequence of words ("labels") separated by
>>>period characters. The root of the tree is simply called ".". The
>>>Internet community at large, through processes and policies external
>>>to this work, selects points in this tree at which to register domain
>>>names "owned" by independent organizations. Real-world examples of
>>>these points are ".com", ".org", ".us", and ".gov.uk". Names at
>>>which such registrations occur are called "Public Suffix Domains
>>>(PSDs)", and a registration consists of a label selected by the
>>>registrant to which a desirable PSD is appended. For example,
>>>"ietf.org" is a registered domain name, and ".org" is its PSD.
>
>I would chop a lot of that out. If people don't already know how DNS names
>work, they're not going to be able to use DMARC.
I agree.
>>My thought is to add text based on the above mail to the paragraph:
>>
>>PSDs are important to DMARC because subdomains of a PSD are different
>>organizations and subdomains of non-PSDs are part of the same organization.
>
>That seems OK.
Great. How about adding that and I'll take another look at the overall
definition later in the week.
Scott K
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
It appears that Scott Kitterman said:
>The PSD definition is probably overlong already:
>
>> 3.2.8. Public Suffix Domain (PSD)
>>
>>The global Internet Domain Name System (DNS) is documented in
>>numerous RFCs. It defines a tree of names starting with root, ".",
>>immediately below which are Top-Level Domain names such as ".com" and
>>".us". The domain name structure consists of a tree of names, each
>>of which is made of a sequence of words ("labels") separated by
>>period characters. The root of the tree is simply called ".". The
>>Internet community at large, through processes and policies external
>>to this work, selects points in this tree at which to register domain
>>names "owned" by independent organizations. Real-world examples of
>>these points are ".com", ".org", ".us", and ".gov.uk". Names at
>>which such registrations occur are called "Public Suffix Domains
>>(PSDs)", and a registration consists of a label selected by the
>>registrant to which a desirable PSD is appended. For example,
>>"ietf.org" is a registered domain name, and ".org" is its PSD.
I would chop a lot of that out. If people don't already know how DNS names
work, they're not going to be able to use DMARC.
>My thought is to add text based on the above mail to the paragraph:
>
>PSDs are important to DMARC because subdomains of a PSD are different
>organizations and subdomains of non-PSDs are part of the same organization.
That seems OK.
R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
On Tuesday, June 28, 2022 12:46:18 PM EDT Scott Kitterman wrote:
...
> The operational distinction between a PSD and a non-PSD is that subdomains
> of a PSD are different organizations and subdomains of non-PSDs are part of
> the same organization. I believe that's the correct distinction.
Looking back, I think this is a distinction worth adding to the draft as I
think it will help provide clarity for future readers to resolve any
ambiguities they find in the text correctly.
The PSD definition is probably overlong already:
> 3.2.8. Public Suffix Domain (PSD)
>
>The global Internet Domain Name System (DNS) is documented in
>numerous RFCs. It defines a tree of names starting with root, ".",
>immediately below which are Top-Level Domain names such as ".com" and
>".us". The domain name structure consists of a tree of names, each
>of which is made of a sequence of words ("labels") separated by
>period characters. The root of the tree is simply called ".". The
>Internet community at large, through processes and policies external
>to this work, selects points in this tree at which to register domain
>names "owned" by independent organizations. Real-world examples of
>these points are ".com", ".org", ".us", and ".gov.uk". Names at
>which such registrations occur are called "Public Suffix Domains
>(PSDs)", and a registration consists of a label selected by the
>registrant to which a desirable PSD is appended. For example,
>"ietf.org" is a registered domain name, and ".org" is its PSD.
My thought is to add text based on the above mail to the paragraph:
PSDs are important to DMARC because subdomains of a PSD are different
organizations and subdomains of non-PSDs are part of the same organization.
Scott K
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
On June 30, 2022 7:12:42 AM UTC, Alessandro Vesely wrote: >On Wed 29/Jun/2022 19:17:05 +0200 Scott Kitterman wrote: >> >>> Yes, the example is contrived, but since there are no rules limiting >>> delegation to third parties, we cannot be sure how subdomains are going to >>> evolve. >> >> My view is that we are in a case that is sufficiently obscure that the >> answer to complaints should be "then don't do that". We should move on to >> other critical topics like what to call the tag. > > >It is difficult to find the right names for the tags when we look at them and >still don't know whether we see rabbits or ducks. > >Perhaps there should be an appendix making examples of how to structure >cascades of private PSDs, also showing how the algorithm behaves in such >corner cases? I don't think it merits such a treatment. 99.9 (plus some number of additional nines) percent of domains, no one will even need to think about the psd= tag. For the likely no more than dozens of domains that really need psd=y it is relatively straightforward and I think we provide sufficient guidance already. It's possible that the multiple layer monstrosity we're discussing here exists, but I think it is unlikely. Adding a lot of text to explain this small a corner case at best slows down the working group and at worst creates an attractive nuisance that causes someone to overthink their situation and make a deployment error. Let's move on. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
On Wed 29/Jun/2022 19:17:05 +0200 Scott Kitterman wrote: Yes, the example is contrived, but since there are no rules limiting delegation to third parties, we cannot be sure how subdomains are going to evolve. My view is that we are in a case that is sufficiently obscure that the answer to complaints should be "then don't do that". We should move on to other critical topics like what to call the tag. It is difficult to find the right names for the tags when we look at them and still don't know whether we see rabbits or ducks. Perhaps there should be an appendix making examples of how to structure cascades of private PSDs, also showing how the algorithm behaves in such corner cases? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
On June 29, 2022 5:13:14 PM UTC, Alessandro Vesely wrote: >On Wed 29/Jun/2022 12:40:36 +0200 Scott Kitterman wrote: >> On June 29, 2022 10:16:00 AM UTC, Alessandro Vesely wrote: >>> On Tue 28/Jun/2022 18:46:18 +0200 Scott Kitterman wrote: On June 28, 2022 4:33:15 PM UTC, Alessandro Vesely wrote: > What can one find continuing the walk after psd=y? > > For example, let's consider an imaginary bank, com.bank, say. They use > that domain as corporate domain, and have a DMARC record. They also > delegate zones to local subsidiaries. One of them, uk.com.bank in turn > delegates to other banks in the UK and sends mail like uk.com. So you > may end up having a DMARC record at each level: > > bank -> psd=y, > com.bank -> psd=n or psd=u (for private use), > uk.com.bank -> psd=y. > > Does our model support that? How else should they set their records up? I think that's sufficiently obscure that I doubt we care, but I think it is supported just fine. The only nuance is that in this scenario, mail that is 5322.from uk.com.bank would have to use 5321.mailfrom and DKIM d= uk.com.bank. Subdomains wouldn't align, which I think is fine. >>> >>> >>> However, if you continue the tree walk after uk.com.bank, you'll find the >>> org domain is com.bank. That way, d=whatever.com.bank in a signature would >>> be aligned, which is not correct. >> >> Why is it not correct? If it shouldn't be used for alignment, then >> come.bank should have psd=y. > > >Hm... not sure. Say you want full usage for your domain, including alignment. > Then you publish psd=n or u. Delegations are done from subdomains which >publish psd=y. This is a logic similar to that sometimes used by mailing >lists hosted at a domain --using @lists.example.com rather than @example.com >directly. > >The point is that there can be a domain with a DMARC record with psd!=y after >one with psd=y. > > The operational distinction between a PSD and a non-PSD is that subdomains of a PSD are different organizations and subdomains of non-PSDs are part of the same organization. I believe that's the correct distinction. >>> >>> Yes. >> >> If uk.com.bank is a part of com.bank as an organization, then alignment with >> other subdomains within com.bank is appropriate. If they aren't, then >> come.bank's record is wrong. > > >Uk.com.bank should've been just the base domain for UK branches of the >commercial bank, perhaps london.uk.com.bank and the like, each one >administratively independent of the central com.bank. Uk.com.bank weren't >supposed to use their domain to send mail, but they did. This is similar to >uk.com restricted to bank subjects. > >Recall that sites like uk.com are the reason why we cannot just assume that >PSDs cannot have MX records. > > >> I think you have answered the question you asked John regarding why not stop >> if psd=y in step 2. The current process produces a more logically >> consistent result than if that constraint were added (in this admittedly >> contrived case). > > >Did I? I don't understand John's pet example. Why would cats.petlovers.com >set psd=y, by mistake? If cats and dogs have antagonistic instincts toward >each other, perhaps they shouldn't be associated under the same administration. > >Yes, the example is contrived, but since there are no rules limiting >delegation to third parties, we cannot be sure how subdomains are going to >evolve. My view is that we are in a case that is sufficiently obscure that the answer to complaints should be "then don't do that". We should move on to other critical topics like what to call the tag. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
On Wed 29/Jun/2022 12:40:36 +0200 Scott Kitterman wrote: On June 29, 2022 10:16:00 AM UTC, Alessandro Vesely wrote: On Tue 28/Jun/2022 18:46:18 +0200 Scott Kitterman wrote: On June 28, 2022 4:33:15 PM UTC, Alessandro Vesely wrote: What can one find continuing the walk after psd=y? For example, let's consider an imaginary bank, com.bank, say. They use that domain as corporate domain, and have a DMARC record. They also delegate zones to local subsidiaries. One of them, uk.com.bank in turn delegates to other banks in the UK and sends mail like uk.com. So you may end up having a DMARC record at each level: bank -> psd=y, com.bank -> psd=n or psd=u (for private use), uk.com.bank -> psd=y. Does our model support that? How else should they set their records up? I think that's sufficiently obscure that I doubt we care, but I think it is supported just fine. The only nuance is that in this scenario, mail that is 5322.from uk.com.bank would have to use 5321.mailfrom and DKIM d= uk.com.bank. Subdomains wouldn't align, which I think is fine. However, if you continue the tree walk after uk.com.bank, you'll find the org domain is com.bank. That way, d=whatever.com.bank in a signature would be aligned, which is not correct. Why is it not correct? If it shouldn't be used for alignment, then come.bank should have psd=y. Hm... not sure. Say you want full usage for your domain, including alignment. Then you publish psd=n or u. Delegations are done from subdomains which publish psd=y. This is a logic similar to that sometimes used by mailing lists hosted at a domain --using @lists.example.com rather than @example.com directly. The point is that there can be a domain with a DMARC record with psd!=y after one with psd=y. The operational distinction between a PSD and a non-PSD is that subdomains of a PSD are different organizations and subdomains of non-PSDs are part of the same organization. I believe that's the correct distinction. Yes. If uk.com.bank is a part of com.bank as an organization, then alignment with other subdomains within com.bank is appropriate. If they aren't, then come.bank's record is wrong. Uk.com.bank should've been just the base domain for UK branches of the commercial bank, perhaps london.uk.com.bank and the like, each one administratively independent of the central com.bank. Uk.com.bank weren't supposed to use their domain to send mail, but they did. This is similar to uk.com restricted to bank subjects. Recall that sites like uk.com are the reason why we cannot just assume that PSDs cannot have MX records. I think you have answered the question you asked John regarding why not stop if psd=y in step 2. The current process produces a more logically consistent result than if that constraint were added (in this admittedly contrived case). Did I? I don't understand John's pet example. Why would cats.petlovers.com set psd=y, by mistake? If cats and dogs have antagonistic instincts toward each other, perhaps they shouldn't be associated under the same administration. Yes, the example is contrived, but since there are no rules limiting delegation to third parties, we cannot be sure how subdomains are going to evolve. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
On Wed, 29 Jun 2022, Alessandro Vesely wrote: Would you please show an example, realistic or not, where not stopping for psd=y in step 2 leads to a useful result? Keeping in mind that this is an arcane corner case that affects perhaps a few hundred of the 100,000 domains that are likely to publish DMARC records, and it doesn't matter in practice: A site for aficionados of various kinds of pets: _dmarc.petlovers.com p=reject psd=u _dmarc.cats.petlovers.com psd=y _dmarc.dogs.petlovers.com psd=y A message from management: From: fe...@cats.petlovers.com DKIM-Signature: d=petlovers.com Subject: Dogs are bad etc. I'm not saying this is particularly likely, but it's no less likely than any other contrived psd=y scenario so I hope we can stop now and move on to something more important. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
On June 29, 2022 10:16:00 AM UTC, Alessandro Vesely wrote: >On Tue 28/Jun/2022 18:46:18 +0200 Scott Kitterman wrote: >> On June 28, 2022 4:33:15 PM UTC, Alessandro Vesely wrote: >> >>> What can one find continuing the walk after psd=y? >>> >>> For example, let's consider an imaginary bank, com.bank, say. They use >>> that domain as corporate domain, and have a DMARC record. They also >>> delegate zones to local subsidiaries. One of them, uk.com.bank in turn >>> delegates to other banks in the UK and sends mail like uk.com. So you may >>> end up having a DMARC record at each level: >>> >>> bank -> psd=y, >>> com.bank -> psd=n or psd=u (for private use), >>> uk.com.bank -> psd=y. >>> >>> Does our model support that? How else should they set their records up? >> >> I think that's sufficiently obscure that I doubt we care, but I think it is >> supported just fine. >> >> The only nuance is that in this scenario, mail that is 5322.from uk.com.bank >> would have to use 5321.mailfrom and DKIM d= uk.com.bank. Subdomains >> wouldn't align, which I think is fine. > > >However, if you continue the tree walk after uk.com.bank, you'll find the org >domain is com.bank. That way, d=whatever.com.bank in a signature would be >aligned, which is not correct. Why is it not correct? If it shouldn't be used for alignment, then come.bank should have psd=y. >> The operational distinction between a PSD and a non-PSD is that subdomains >> of a PSD are different organizations and subdomains of non-PSDs are part of >> the same organization. I believe that's the correct distinction. > >Yes. If uk.com.bank is a part of com.bank as an organization, then alignment with other subdomains within com.bank is appropriate. If they aren't, then come.bank's record is wrong. I think you have answered the question you asked John regarding why not stop if psd=y in step 2. The current process produces a more logically consistent result than if that constraint were added (in this admittedly contrived case). Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
On Tue 28/Jun/2022 18:46:18 +0200 Scott Kitterman wrote: On June 28, 2022 4:33:15 PM UTC, Alessandro Vesely wrote: What can one find continuing the walk after psd=y? For example, let's consider an imaginary bank, com.bank, say. They use that domain as corporate domain, and have a DMARC record. They also delegate zones to local subsidiaries. One of them, uk.com.bank in turn delegates to other banks in the UK and sends mail like uk.com. So you may end up having a DMARC record at each level: bank -> psd=y, com.bank -> psd=n or psd=u (for private use), uk.com.bank -> psd=y. Does our model support that? How else should they set their records up? I think that's sufficiently obscure that I doubt we care, but I think it is supported just fine. The only nuance is that in this scenario, mail that is 5322.from uk.com.bank would have to use 5321.mailfrom and DKIM d= uk.com.bank. Subdomains wouldn't align, which I think is fine. However, if you continue the tree walk after uk.com.bank, you'll find the org domain is com.bank. That way, d=whatever.com.bank in a signature would be aligned, which is not correct. The operational distinction between a PSD and a non-PSD is that subdomains of a PSD are different organizations and subdomains of non-PSDs are part of the same organization. I believe that's the correct distinction. Yes. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
On Wed 29/Jun/2022 00:23:08 +0200 John R Levine wrote: What can one find continuing the walk after psd=y? I have looked at every domain in the PSL that publishes a DMARC record and other than the three that are in Scott's PSD list, what I found was totally random. Some looked reasonable, some looked broken. In practice I think the details are unlikely to matter because if they send mail at all, the SPF and DKIM identities are going to be the same as the From so they'll be aligned no matter what rule we use. Indeed, in realistic cases walking the tree beyond psd=y results in just a useless query. I have shown an unrealistic case where not stopping at psd=y results in a wrong determination. Would you please show an example, realistic or not, where not stopping for psd=y in step 2 leads to a useful result? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
What can one find continuing the walk after psd=y? I have looked at every domain in the PSL that publishes a DMARC record and other than the three that are in Scott's PSD list, what I found was totally random. Some looked reasonable, some looked broken. In practice I think the details are unlikely to matter because if they send mail at all, the SPF and DKIM identities are going to be the same as the From so they'll be aligned no matter what rule we use. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
On June 28, 2022 4:33:15 PM UTC, Alessandro Vesely wrote: >On Mon 27/Jun/2022 15:54:51 +0200 John R Levine wrote: >>> Please recall what you said in April: >>> >>> How about if we say that if the initial domain has psd=y, that's the org >>> domain and you don't look anywhere else. That is easy to explain and I >>> don't think we are likely to find anything that better matches the >>> expectations of people who send mail from PSDs. >>> https://mailarchive.ietf.org/arch/msg/dmarc/UEwREV5oDD0BoyNpaUB9GN6ixtI >> >> I thought about it some more and changed my mind. That occasionally happens. > > >Right, but how about discussing the merit of it? > >What can one find continuing the walk after psd=y? > >For example, let's consider an imaginary bank, com.bank, say. They use that >domain as corporate domain, and have a DMARC record. They also delegate zones >to local subsidiaries. One of them, uk.com.bank in turn delegates to other >banks in the UK and sends mail like uk.com. So you may end up having a DMARC >record at each level: > >bank -> psd=y, >com.bank -> psd=n or psd=u (for private use), >uk.com.bank -> psd=y. > >Does our model support that? How else should they set their records up? I think that's sufficiently obscure that I doubt we care, but I think it is supported just fine. The only nuance is that in this scenario, mail that is 5322.from uk.com.bank would have to use 5321.mailfrom and DKIM d= uk.com.bank. Subdomains wouldn't align, which I think is fine. The operational distinction between a PSD and a non-PSD is that subdomains of a PSD are different organizations and subdomains of non-PSDs are part of the same organization. I believe that's the correct distinction. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
On Mon 27/Jun/2022 15:54:51 +0200 John R Levine wrote: Please recall what you said in April: How about if we say that if the initial domain has psd=y, that's the org domain and you don't look anywhere else. That is easy to explain and I don't think we are likely to find anything that better matches the expectations of people who send mail from PSDs. https://mailarchive.ietf.org/arch/msg/dmarc/UEwREV5oDD0BoyNpaUB9GN6ixtI I thought about it some more and changed my mind. That occasionally happens. Right, but how about discussing the merit of it? What can one find continuing the walk after psd=y? For example, let's consider an imaginary bank, com.bank, say. They use that domain as corporate domain, and have a DMARC record. They also delegate zones to local subsidiaries. One of them, uk.com.bank in turn delegates to other banks in the UK and sends mail like uk.com. So you may end up having a DMARC record at each level: bank -> psd=y, com.bank -> psd=n or psd=u (for private use), uk.com.bank -> psd=y. Does our model support that? How else should they set their records up? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
Please recall what you said in April: How about if we say that if the initial domain has psd=y, that's the org domain and you don't look anywhere else. That is easy to explain and I don't think we are likely to find anything that better matches the expectations of people who send mail from PSDs. https://mailarchive.ietf.org/arch/msg/dmarc/UEwREV5oDD0BoyNpaUB9GN6ixtI I thought about it some more and changed my mind. That occasionally happens. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
On Sun 26/Jun/2022 17:42:10 +0200 John Levine wrote: It appears that Alessandro Vesely said: One question is what do you do if the DMARC record for your original From: domain has psd=y. My text says you ignore it since if you're sending mail, you're not really a PSD. I disagree. If a PSD sends messages, e.g. uk.com, it should still set psd=y, and there's no reason to ignore it. ... You might want to look at the draft and see what it says. In this case it says if the From domain's DMARC record has psd=y, you ignore it in that case. If you find psd=y waslking up from a subdomain you handle it normally. Please recall what you said in April: How about if we say that if the initial domain has psd=y, that's the org domain and you don't look anywhere else. That is easy to explain and I don't think we are likely to find anything that better matches the expectations of people who send mail from PSDs. https://mailarchive.ietf.org/arch/msg/dmarc/UEwREV5oDD0BoyNpaUB9GN6ixtI Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
It appears that Alessandro Vesely said: >> One question is what do you do if the DMARC record for your original From: >> domain has psd=y. My text says you ignore it since if you're sending mail, >> you're not really a PSD. >I disagree. If a PSD sends messages, e.g. uk.com, it should still set psd=y, >and there's no reason to ignore it. ... You might want to look at the draft and see what it says. In this case it says if the From domain's DMARC record has psd=y, you ignore it in that case. If you find psd=y waslking up from a subdomain you handle it normally. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
On Sun 26/Jun/2022 02:42:31 +0200 John R. Levine wrote: I made a pull requests with a few tweaks to the tree walk so it will get the right answer even with psd tags at multiple levels. https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/pull/47 One question is what do you do if the DMARC record for your original From: domain has psd=y. My text says you ignore it since if you're sending mail, you're not really a PSD. I disagree. If a PSD sends messages, e.g. uk.com, it should still set psd=y, and there's no reason to ignore it. We said that, in such cases, they practically have an implicit adkim=s. Thus, it makes no sense to look for an org domain toward the root. Taken off this bit, I re-propose the shorter (6 step) algorithm I posted in April: Forwarded Message Subject: Re: [dmarc-ietf] 5.5.4. Publish a DMARC Policy for the Author Domain - dmarcbis-06 Date: Tue, 5 Apr 2022 10:43:49 +0200 From: Alessandro Vesely To: dmarc@ietf.org On Mon 04/Apr/2022 15:29:40 +0200 Scott Kitterman wrote: > > The diff is relative the last text I posted. Section 5 has to stay before Section 4. It makes no sense to exemplify _dmarc.example.com if we haven't yet said that: Domain Owner and PSO DMARC preferences are stored as DNS TXT records in subdomains named "_dmarc". [Current Section 5.1] Then, let's make a statement like so: Retrieving the DMARC record of a domain implies the following steps: 1. Prepend the label "_dmarc" to the domain name and issue a DNS Query for a TXT record at the resulting domain. For example, if the domain is example.com, query _dmarc.example.com. 2. Collate any string returned, in the order returned. 3. Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded. If multiple DMARC records are returned, they are all discarded. At this point, the algorithm can be expressed in a shorter form like so: 1. Set the current target to the identifier at hand, which is one of the domain(s) described above. 2. Retrieve the DMARC record of the current target. 3. If the record exists and contains either psd=y or psd=n, stop. 4. Break the current target name into a set of "n" ordered labels. Number these labels from right to left; e.g., for "a.mail.example.com", "com" would be label 1, "example" would be label 2, "mail.example.com" would be label 3, and so forth. 5. Count the number of labels in the current target. Let that number be "x". If x = 1, stop. If x < 5, remove the left-most (highest- numbered) label from the subject domain. If x >= 5, remove the left-most (highest-numbered) labels from the subject domain until 4 labels remain. The resulting DNS domain name is the new target for subsequent lookups. 6. Go to 2. Better? 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] Final, I hope, tweaks to the tree walk
On Saturday, June 25, 2022 8:42:31 PM EDT John R. Levine wrote: > I made a pull requests with a few tweaks to the tree walk so it will > get the right answer even with psd tags at multiple levels. > > https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/pull/47 > > One question is what do you do if the DMARC record for your original From: > domain has psd=y. My text says you ignore it since if you're sending > mail, you're not really a PSD. I think this is correct, although I think it doesn't quite do that (and I think it's good the way it is. As I read it, let's say gov.example where gov.example sends mail, but has psd=y in its record (and example either has no record or it also has psd=y) 5322.From = gov.example 5321.MailFrom = gov.example d= signing domain = gov.example In this case, in trying to determine the organizational domain we would look at Section 4.8, Organizational Domain Discovery, and the first item under the note regarding when a Tree Walk is required: >* The RFC5322.From domain and the RFC5321.MailFrom domain (if SPF > > authenticated), and/or the DKIM d= domain (if present and > authenticated) are all the same and that domain has a DMARC > record. In this case, this common domain is treated as the > Organizational Domain. Since the domains are all the same, they all have the same organizational domain and align. Even if this note wasn't present, you would still get the same result if you did the Tree Walk anyway. Looking to Section 4.6, DNS Tree Walk, you would do the query for _dmarc.gov.example in step 1 and get a result. With step 2, as modified by your pull request, the single record that was retrieved does not contain psd=n, so we continue and check DMARC for _dmarc.example and find either that it has a psd=y record and previous record is the org domain or that it has no DMARC record and then the last record retrieved is the org domain. Either way, gov.example is the org domain for the message. I think this is fine. I don't think there's an inherent reason why we shouldn't allow for PSDs to send mail and this is also the way RFC 9091 would parse it. What won't work for PSDs is to use a mix of the PSD domain and a subdomain in the different identities. In that case the identities using the subdomain would have one level below gov.example as their org domain, so they wouldn't align. I think it's a reasonable constraint that a domain can either be a PSD or use subdomains, not both. My suggestion is we put your changes into the next revision and then move on to the next problem. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
