Re: [dmarc-ietf] Tree walk is screwed up
On Tue, Jan 25, 2022 at 3:31 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Overall, I doubt that we can replace the PSL without moving to DMARCv2, > and I don't think we have a standards-worthy document unless the PSL is > replaced. > I don't think such an opinion is going to ruffle any feathers in here. The PSL has been non-ideal since the beginning, but it's all we had to work with at the time. RFC 7489 anticipated its replacement someday with something better. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-04 feedback
Richard, Thanks for the notes. I'll file a few trac issues to get these resolved, and try to get a new version released soon-ish. If you're okay with it, I may send you a preview version to ensure it resolves the items noted below. Thanks again -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -Original Message- > From: dmarc On Behalf Of Richard Gray > Sent: Tuesday, January 25, 2022 5:03 AM > To: dmarc@ietf.org > Subject: [dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-04 feedback > > Hi, > > I've been reading over the DMARC Aggregate Reporting draft and have some > feedback on the schema and sample report. > > * The ActionDispositionType type definition in the schema is missing a closing > tag > > * The schema has the DMARC report version element () specified > immediately under the root element and not under > as stated in section 2.1 > > * The draft states that has mandatory fields domain, p, and > sp, and optional fields fo, adkim, aspf, and testing. > The schema for PolicyPublishedType has mandatory fields domain and > version_published, with all other fields optional. Should version_published be > mandatory or optional? > > * The schema for IdentifierType has header_from and envelope_from as > mandatory fields, and envelope_to as an optional field. The sample report > includes only header_from. The draft text in section 2.1 says "In most cases, > this > will be a header_from element, which will contain the 5322.From domain from > the message". Is it the intention of the draft that envelope_to should be > mandatory? > > * The schema for SPFAuthResultType has scope (mfrom/helo) as a mandatory > attribute but the sample report does not include a scope section. Should the > SPF > scope be a mandatory field? > > * The schema does not currently permit report extensions as described in the > draft (section 4). I am not sure if it is possible to define a schema > allowing an > arbitrary element name with a required definition attribute (pointing to the > extension spec). > > As an alternative, would it be better to have a standard element name > representing an arbitrary extension, with an attribute (even just the > definition > URI) to identify the specific extension in use? E.g. > > > definition="https://urldefense.com/v3/__https://www.example.com/dmarc- > extension/0.1__;!!CQl3mcHX2A!SZyg4CQrLEXm4I_qOm-N9qEMlEx- > YkNnYRm5_S0C6L9rYHWuDoTGAMToQF8p5wahviZ7N-gj3w$ "> > ... > > > > * Lastly, the draft states that reports have two primary sections, one with > descriptive information and the other with row-data for the report. The > "informative" section is broken into two sub-sections, which are > report_metadata and policy_published. Would it perhaps be clearer to say that > there are three main sections rather than two? > report_metadata and policy_published are subsections of the main feedback > element along with the record elements holding the row data. > The schema is clear in this instance, I just wondered if the wording in the > draft > might be improved. > > Regards, > Richard > > ___ > dmarc mailing list > dmarc@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;! > !CQl3mcHX2A!SZyg4CQrLEXm4I_qOm-N9qEMlEx- > YkNnYRm5_S0C6L9rYHWuDoTGAMToQF8p5wahvibu5fFB5w$ ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Timeline for Release of draft-ietf-dmarc-dmarcbis-5
On Tuesday, January 25, 2022 2:48:24 PM EST Todd Herr wrote: > Greetings. > > I've been monitoring the on-list discussion and I would like to take a stab > at incorporating it into the next draft. > > My plan is to get a next draft released either Monday, January 31 > or Tuesday, February 1, but that will depend on whether or not list > discussion reaches a point where it makes sense to release a new draft. > > If anyone thinks that timeline is too aggressive, please let me know. I'm definitely in favor of a new draft. Also, as I mentioned earlier today, I think the dns-tree-walk needs to additional words for the reverse walk to find the organizational domain. Patch attached. I think this, with the other patch I sent last night gives us a complete, if still somewhat rough description of what's needed to complete the org domain discovery part of the document. I'm sure the words can be improved (and will be), but it'd be nice to get these in so we have something that works in the latest draft. Thanks, Scott Kdiff --git a/draft-ietf-dmarc-dmarcbis-05.xml b/draft-ietf-dmarc-dmarcbis-05.xml index 9dd68a3..6b8f578 100644 --- a/draft-ietf-dmarc-dmarcbis-05.xml +++ b/draft-ietf-dmarc-dmarcbis-05.xml @@ -490,9 +490,17 @@ labels remaining or a valid DMARC record containing the information sought has been retrieved. +For determining the organizational domain used for determining relaxed +alignment, the same process is followed, except in the reverse order. +Starting at the top of the DNS tree with a single label, query the DNS for a +DMARC TXT record until a DMARC record not containing a psd tag with a value of +'y' is found, the domain to query is the RFC5322.From domain, or the number of +labels exceeds 4. If an appropriate DMARC record was found, that domain is +the Organizational Domain, otherwise the RFC5322.From domain is the +Organizational Domain. To illustrate, for a message with the arbitrary RFC5322.From domain of "a.b.c.d.e.mail.example.com", a full DNS Tree Walk would require the following -five queries, in order: +five queries, in order to locate the policy domain: _dmarc.a.b.c.d.e.mail.example.com draft-ietf-dmarc-dmarcbis-05.txt-from-.findorg.diff.html Description: application/xhtml ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is screwed up
> > > DMARC for PSD is based on the rule that the PSD is one segment above the > organization domain, and the organization domain is assumed to be known > with confidence from the PSL. > When we switch directions, we cannot as easily assume that the > organization domain is one segment below PSD=Y.For this to be true, > PSDs MUST populate their DMARC records from the lowest-level leaf nodes > up. For example, if "c.b.a" is a PSD, and "z.b.a" is an organization, > then "c.b.a" must be flagged before "b.a" is flagged.If "b.a" is > flagged first, then "c.b.a" will be treated as an organization domain, > incorrectly, because "c.b.a" is below the flagged "b.a" record. The > requirement to work bottom-up is contrary to the way that I expect people > to address a problem like this. In some cases tagging all of the leaf > nodes may be especially problematic, such as when the PSL record says that > "*.something" is a PSD, except for "www.something". If we provide an org=y flag as Ale suggests, the problem can be mitigated if organizations choose to document the top of their alignment structure using the org flag. But this mitigation cannot help the situation where the PSD policy is being applied because an organization does not have a policy of its own. > An overarching problem is that the PSD structure is not latent in the current DNS, waiting for us to draw it out. We have to make assumptions that the DNS will contain data that can support our objectives, and that organizations will choose to migrate their configuration to match our assumptions. For example, we want to assume that every DMARC-using domain will have an existing policy record at the organization level. This is probably typical, but it is certainly not required by the design of RFC 7489.Overall, I doubt that we can replace the PSL without moving to DMARCv2, and I don't think we have a standards-worthy document unless the PSL is replaced. Doug (aka gloomy Eeyore today) > . > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is screwed up
It appears that Alessandro Vesely said: >As John said, the gap is that PSD domains are not going to publish >psd=y. No, that is not at all what I said. Most PSDs will publish no DMARC record at all. Based on what Scott has said, the handful that do publish a DMARC record will indeed include psd=y. My point is that our tree walk has to have reasonable defaults in the likely case that org and PSD domains won't have a DMARC record. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Timeline for Release of draft-ietf-dmarc-dmarcbis-5
On 1/25/2022 11:55 AM, Barry Leiba wrote: I think that draft revisions are cheap, and that it's better to put a revision out than to hold it for more changes. +1 d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Timeline for Release of draft-ietf-dmarc-dmarcbis-5
I think that draft revisions are cheap, and that it's better to put a revision out than to hold it for more changes. Barry On Tue, Jan 25, 2022 at 2:49 PM Todd Herr wrote: > Greetings. > > I've been monitoring the on-list discussion and I would like to take a > stab at incorporating it into the next draft. > > My plan is to get a next draft released either Monday, January 31 > or Tuesday, February 1, but that will depend on whether or not list > discussion reaches a point where it makes sense to release a new draft. > > If anyone thinks that timeline is too aggressive, please let me know. > > -- > > *Todd Herr * | Technical Director, Standards and Ecosystem > *e:* todd.h...@valimail.com > *m:* 703.220.4153 > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > ___ > 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-ietf] Timeline for Release of draft-ietf-dmarc-dmarcbis-5
Greetings. I've been monitoring the on-list discussion and I would like to take a stab at incorporating it into the next draft. My plan is to get a next draft released either Monday, January 31 or Tuesday, February 1, but that will depend on whether or not list discussion reaches a point where it makes sense to release a new draft. If anyone thinks that timeline is too aggressive, please let me know. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up
On Tue, Jan 25, 2022 at 11:26 AM John R Levine wrote: > On Tue, 25 Jan 2022, Murray S. Kucherawy wrote: > >> will get the same result. It also occurs to me that in the absence of > >> a PSL-like thing, the idea of an organizational domain is no longer > >> useful. > > > > Aren't we basically trying to identify the same thing, just in a > different > > (and more robust) way? > > Yes, but that leads to the question of whether the org domain is useful on > its own or it's just a way to figure out alignment. I think it's the > latter, dunno what other people think. > It's an interesting thought exercise at least. We should be sure to give a decent treatment to this in the "differences since RFC 7489" part of the document. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up
On Tue, 25 Jan 2022, Murray S. Kucherawy wrote: will get the same result. It also occurs to me that in the absence of a PSL-like thing, the idea of an organizational domain is no longer useful. Aren't we basically trying to identify the same thing, just in a different (and more robust) way? Yes, but that leads to the question of whether the org domain is useful on its own or it's just a way to figure out alignment. I think it's the latter, dunno what other people think. 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] Tree walk is not a heuristic, was screwed up
On Tue, Jan 25, 2022 at 9:40 AM John Levine wrote: > It appears that Scott Kitterman said: > >My impression is that the group is generally okay with PSD=y. I prefer > it over your suggestion. My strongest preference is that we pick > something, stick with it, and move on. > > I think I see where Ale's confusion is coming from. If we switch to a > tree walk, we will have an algorithm rather than a heuristic, so > anyone looking at the same domains and the same set of DMARC records > will get the same result. It also occurs to me that in the absence of > a PSL-like thing, the idea of an organizational domain is no longer > useful. > Aren't we basically trying to identify the same thing, just in a different (and more robust) way? I'd be careful about saying "no longer useful"; doing so implies a much bigger change than we might be aiming to "sell" here. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up
On Tue, 25 Jan 2022, Dotzero wrote: If they are cousin domains, walk up the tree from each until you find a policy record. If you find the same policy record and it's not a PSD and it allows relaxed alignment, they're in relaxed alignment. If you find different records, or only one record, or no records, they aren't. I think a better term is sibling domains. The phrase "cousin domains" has typically been used for look alike domains rather than the subdomain issue. Agreed, sibling is better, although of course they could be great-aunts, too. It actually does allow malicious, not accidental, alignment. I'm done reminding. This allows an attack vector which can be useful for BEC attacks, hostile governments targeting NGOs, journalists, etc. and other targeted attacks. I don't have strong opinions about whether to continue to allow great-aunt alignment other than to note this is such a well known problem that it is exactly the problem the PSL was invented to address, and we can argue about how well the PSL and other widely available mitigation techniques work and how reasonable it is to expect people to use them. Do we have any stats on how often real mail depends on sibling alignment? If nobody actually uses it, the spec would be simpler if we could take it out. 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] Tree walk is not a heuristic, was screwed up
On Tue, Jan 25, 2022 at 12:40 PM John Levine wrote: > It appears that Scott Kitterman said: > >My impression is that the group is generally okay with PSD=y. I prefer > it over your suggestion. My strongest preference is that we pick > something, stick with it, and move on. > > I think I see where Ale's confusion is coming from. If we switch to a > tree walk, we will have an algorithm rather than a heuristic, so > anyone looking at the same domains and the same set of DMARC records > will get the same result. It also occurs to me that in the absence of > a PSL-like thing, the idea of an organizational domain is no longer > useful. > > There's two questions to answer: what is the policy for a domain, and are > two domains in relaxed alignment. > > The answer to the first one is straightforward: start at the domain, walk > up the tree, and the first DMARC record > you find is the policy record. If you don't find one, there's no policy. > > The answer to the second has two cases: > > If one domain is a subdomain of the other, and there is no policy record > (or maybe no PSD policy record) between > them, they're in relaxed alignment. > I have no problem with this. Those of us who originally created DMARC considered this the use case for relaxed. > > If they are cousin domains, walk up the tree from each until you find a > policy record. If you find the same policy > record and it's not a PSD and it allows relaxed alignment, they're in > relaxed alignment. If you find different > records, or only one record, or no records, they aren't. > > I think a better term is sibling domains. The phrase "cousin domains" has typically been used for look alike domains rather than the subdomain issue. > As a special case, a domain with a PSD record is never aligned with > anything but itself. > (I realize .bank will never send mail, but us.com might.) > > The cousin domain rule doesn't exactly reproduce what the PSL is intended > to do, but I think it covers > the useful cases and is unlikely to allow accidental cousin alignment > which Mike keeps reminding us about. > It actually does allow malicious, not accidental, alignment. I'm done reminding. This allows an attack vector which can be useful for BEC attacks, hostile governments targeting NGOs, journalists, etc. and other targeted attacks. It is not a particularly useful attack vector for large scale opportunistic abuse such as spam or widespread attempts to spread malware. The group will address it or not as it chooses. I've been working on developing real world attack example (defanged) and have just started discussing the issue with various (red team) security folks I know and reaching out to some .gov folks I know. bSidesLV may be held this year and I may present on this there or at other venues. If allowing alignment and a pass based on a sibling domain is allowed in DMARC then the best defense is for people to understand that there are potential real world risks in relying on a DMARC pass in relaxed mode. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up
On January 25, 2022 5:40:09 PM UTC, John Levine wrote: >It appears that Scott Kitterman said: >>My impression is that the group is generally okay with PSD=y. I prefer it >>over your suggestion. My strongest preference is that we pick something, >>stick with it, and move on. > >I think I see where Ale's confusion is coming from. If we switch to a >tree walk, we will have an algorithm rather than a heuristic, so >anyone looking at the same domains and the same set of DMARC records >will get the same result. It also occurs to me that in the absence of >a PSL-like thing, the idea of an organizational domain is no longer >useful. > >There's two questions to answer: what is the policy for a domain, and are two >domains in relaxed alignment. > >The answer to the first one is straightforward: start at the domain, walk up >the tree, and the first DMARC record >you find is the policy record. If you don't find one, there's no policy. > >The answer to the second has two cases: > >If one domain is a subdomain of the other, and there is no policy record (or >maybe no PSD policy record) between >them, they're in relaxed alignment. > >If they are cousin domains, walk up the tree from each until you find a policy >record. If you find the same policy >record and it's not a PSD and it allows relaxed alignment, they're in relaxed >alignment. If you find different >records, or only one record, or no records, they aren't. > >As a special case, a domain with a PSD record is never aligned with anything >but itself. >(I realize .bank will never send mail, but us.com might.) > >The cousin domain rule doesn't exactly reproduce what the PSL is intended to >do, but I think it covers >the useful cases and is unlikely to allow accidental cousin alignment which >Mike keeps reminding us about. > >Suggestions and tweaks (with an explanation of what problem they fix) welcome. I think this is generally correct. Can be used for relaxed alignment was always the important thing for organizational domain anyway. I don't know that I'd bother to create the term now, but we already have it and people sort of know what it means, so I think we might as well keep it. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is screwed up
On January 25, 2022 5:36:23 PM UTC, Alessandro Vesely wrote: >On Tue 25/Jan/2022 12:47:21 +0100 Scott Kitterman wrote: >> On January 25, 2022 11:30:51 AM UTC, Alessandro Vesely >> wrote: >>> On Tue 25/Jan/2022 06:56:26 +0100 Scott Kitterman wrote: On Monday, January 24, 2022 10:15:49 PM EST Scott Kitterman wrote: > On January 25, 2022 12:46:48 AM UTC, John Levine wrote: >> It appears that Scott Kitterman said: >>> What I implemented is roughly: >>> >>> For policy determination, first check the From domain, if that has a >>> DMARC >>> record, then that's the policy domain. Otherwise, tree walk up to the >>> apex >>> looking for DMARC records. First domain you find with a record is >>> policy >>> domain, use the policy (p=, sp=, np=) from that domain's DMARC record. >>> This matches my interpretation of dmarcbis-04. >>> >>> For org domain determination (for alignment), if any of the records >>> retrieved during the policy search have psd=y, then add one more label >>> and that's the org domain (as written). From there it's anyone's guess. >>> Unlike John, I continued down the tree and made the first match the org >>> domain. >> >> Seems reasonable. What's the point of going more than one level below >> the >> PSD? Make it look more like a pure tree walk? > > Yes. For consistency. You'd walk down until you hit a non-psd record or > the limit. Stopping at one more after the psd=y record is an optimization > for a relatively rare case of a PSD record. Other than that case you have > to keep going until you find a DMARC record or hit the limit, since > there's > no knowing what's a PSD otherwise. The attached change would solve the problem, at least to a first approximation. The wording could be tightened up, but this is at least a complete description. >>> >>> I don't think "in the reverse order" makes much sense. Usually, I >>> don't walk downward on a DNS, so the meaning of "reverse" is not clear >>> to me. Phrases like "toward the root" or similar might be clearer. >>> >>> Then, may I insist on having role=psd rather than psd=y? It can >>> better the heuristic. >> >> I agree it needs work. I think the tree walk section needs to be updated to >> be bidirectional. Walk up to find policy and walk down to find org. I'm >> only suggesting that this be added for now as an interim step to fix a clear >> gap in -04. > > >As John said, the gap is that PSD domains are not going to publish >psd=y. Maybe, eventually, the ones interested in DMARC will. >However, this is going to be a problem during rollout. > > >> My impression is that the group is generally okay with PSD=y. I prefer it >> over your suggestion. My strongest preference is that we pick something, >> stick with it, and move on. > > >Would you mind elaborating on why you prefer psd= over role=, apart >from the latter arriving late? > >Besides, do you agree that finding psd=n can save a lookup in some cases? I think psd is more precisely constrained to the need. Role is rather open ended. I have no idea what it covers. I think arriving late and not having a clear technical advantage is enough. If this WG is ever going to achieve its goals, we need to decide stuff and not keep revisiting things. Ideally, I'd like to get this nailed down so we can get an early (RFC 7120) assignment of the tag. This will help us with getting things moving forward. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up
It appears that Scott Kitterman said: >My impression is that the group is generally okay with PSD=y. I prefer it >over your suggestion. My strongest preference is that we pick something, >stick with it, and move on. I think I see where Ale's confusion is coming from. If we switch to a tree walk, we will have an algorithm rather than a heuristic, so anyone looking at the same domains and the same set of DMARC records will get the same result. It also occurs to me that in the absence of a PSL-like thing, the idea of an organizational domain is no longer useful. There's two questions to answer: what is the policy for a domain, and are two domains in relaxed alignment. The answer to the first one is straightforward: start at the domain, walk up the tree, and the first DMARC record you find is the policy record. If you don't find one, there's no policy. The answer to the second has two cases: If one domain is a subdomain of the other, and there is no policy record (or maybe no PSD policy record) between them, they're in relaxed alignment. If they are cousin domains, walk up the tree from each until you find a policy record. If you find the same policy record and it's not a PSD and it allows relaxed alignment, they're in relaxed alignment. If you find different records, or only one record, or no records, they aren't. As a special case, a domain with a PSD record is never aligned with anything but itself. (I realize .bank will never send mail, but us.com might.) The cousin domain rule doesn't exactly reproduce what the PSL is intended to do, but I think it covers the useful cases and is unlikely to allow accidental cousin alignment which Mike keeps reminding us about. Suggestions and tweaks (with an explanation of what problem they fix) welcome. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is screwed up
On Tue 25/Jan/2022 12:47:21 +0100 Scott Kitterman wrote: On January 25, 2022 11:30:51 AM UTC, Alessandro Vesely wrote: On Tue 25/Jan/2022 06:56:26 +0100 Scott Kitterman wrote: On Monday, January 24, 2022 10:15:49 PM EST Scott Kitterman wrote: On January 25, 2022 12:46:48 AM UTC, John Levine wrote: It appears that Scott Kitterman said: What I implemented is roughly: For policy determination, first check the From domain, if that has a DMARC record, then that's the policy domain. Otherwise, tree walk up to the apex looking for DMARC records. First domain you find with a record is policy domain, use the policy (p=, sp=, np=) from that domain's DMARC record. This matches my interpretation of dmarcbis-04. For org domain determination (for alignment), if any of the records retrieved during the policy search have psd=y, then add one more label and that's the org domain (as written). From there it's anyone's guess. Unlike John, I continued down the tree and made the first match the org domain. Seems reasonable. What's the point of going more than one level below the PSD? Make it look more like a pure tree walk? Yes. For consistency. You'd walk down until you hit a non-psd record or the limit. Stopping at one more after the psd=y record is an optimization for a relatively rare case of a PSD record. Other than that case you have to keep going until you find a DMARC record or hit the limit, since there's no knowing what's a PSD otherwise. The attached change would solve the problem, at least to a first approximation. The wording could be tightened up, but this is at least a complete description. I don't think "in the reverse order" makes much sense. Usually, I don't walk downward on a DNS, so the meaning of "reverse" is not clear to me. Phrases like "toward the root" or similar might be clearer. Then, may I insist on having role=psd rather than psd=y? It can better the heuristic. I agree it needs work. I think the tree walk section needs to be updated to be bidirectional. Walk up to find policy and walk down to find org. I'm only suggesting that this be added for now as an interim step to fix a clear gap in -04. As John said, the gap is that PSD domains are not going to publish psd=y. Maybe, eventually, the ones interested in DMARC will. However, this is going to be a problem during rollout. My impression is that the group is generally okay with PSD=y. I prefer it over your suggestion. My strongest preference is that we pick something, stick with it, and move on. Would you mind elaborating on why you prefer psd= over role=, apart from the latter arriving late? Besides, do you agree that finding psd=n can save a lookup in some cases? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is screwed up
On January 25, 2022 11:30:51 AM UTC, Alessandro Vesely wrote: >On Tue 25/Jan/2022 06:56:26 +0100 Scott Kitterman wrote: >> On Monday, January 24, 2022 10:15:49 PM EST Scott Kitterman wrote: >>> On January 25, 2022 12:46:48 AM UTC, John Levine wrote: It appears that Scott Kitterman said: > What I implemented is roughly: > > For policy determination, first check the From domain, if that has a DMARC > record, then that's the policy domain. Otherwise, tree walk up to the > apex > looking for DMARC records. First domain you find with a record is policy > domain, use the policy (p=, sp=, np=) from that domain's DMARC record. > This matches my interpretation of dmarcbis-04. > > For org domain determination (for alignment), if any of the records > retrieved during the policy search have psd=y, then add one more label > and that's the org domain (as written). From there it's anyone's guess. > Unlike John, I continued down the tree and made the first match the org > domain. Seems reasonable. What's the point of going more than one level below the PSD? Make it look more like a pure tree walk? >>> >>> Yes. For consistency. You'd walk down until you hit a non-psd record or >>> the limit. Stopping at one more after the psd=y record is an optimization >>> for a relatively rare case of a PSD record. Other than that case you have >>> to keep going until you find a DMARC record or hit the limit, since there's >>> no knowing what's a PSD otherwise. >> >> The attached change would solve the problem, at least to a first >> approximation. >> The wording could be tightened up, but this is at least a complete >> description. > > >I don't think "in the reverse order" makes much sense. Usually, I >don't walk downward on a DNS, so the meaning of "reverse" is not clear >to me. Phrases like "toward the root" or similar might be clearer. > >Then, may I insist on having role=psd rather than psd=y? It can >better the heuristic. I agree it needs work. I think the tree walk section needs to be updated to be bidirectional. Walk up to find policy and walk down to find org. I'm only suggesting that this be added for now as an interim step to fix a clear gap in -04. My impression is that the group is generally okay with PSD=y. I prefer it over your suggestion. My strongest preference is that we pick something, stick with it, and move on. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is screwed up
On Tue 25/Jan/2022 06:56:26 +0100 Scott Kitterman wrote: On Monday, January 24, 2022 10:15:49 PM EST Scott Kitterman wrote: On January 25, 2022 12:46:48 AM UTC, John Levine wrote: It appears that Scott Kitterman said: What I implemented is roughly: For policy determination, first check the From domain, if that has a DMARC record, then that's the policy domain. Otherwise, tree walk up to the apex looking for DMARC records. First domain you find with a record is policy domain, use the policy (p=, sp=, np=) from that domain's DMARC record. This matches my interpretation of dmarcbis-04. For org domain determination (for alignment), if any of the records retrieved during the policy search have psd=y, then add one more label and that's the org domain (as written). From there it's anyone's guess. Unlike John, I continued down the tree and made the first match the org domain. Seems reasonable. What's the point of going more than one level below the PSD? Make it look more like a pure tree walk? Yes. For consistency. You'd walk down until you hit a non-psd record or the limit. Stopping at one more after the psd=y record is an optimization for a relatively rare case of a PSD record. Other than that case you have to keep going until you find a DMARC record or hit the limit, since there's no knowing what's a PSD otherwise. The attached change would solve the problem, at least to a first approximation. The wording could be tightened up, but this is at least a complete description. I don't think "in the reverse order" makes much sense. Usually, I don't walk downward on a DNS, so the meaning of "reverse" is not clear to me. Phrases like "toward the root" or similar might be clearer. Then, may I insist on having role=psd rather than psd=y? It can better the heuristic. Thanks Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is screwed up
On Mon 24/Jan/2022 15:40:01 +0100 John Levine wrote: On Mon, 24 Jan 2022, Alessandro Vesely wrote: This misses the point. It would be a good idea for a multi-tenant domain to publish a PSD record to keep the tenants apart, just as it would be a good idea to send a PSL pull request to keep them from spoofing browser cookies, but I don't think it is a good idea to depend on that. We know that at the TLD level, most TLDs won't ever publish a PSD. If we fear that some TLDs won't qualify their role, then it is wrong to discourage setting psd=n for organizational domains. Setting role=org is even more expressive, because it provides for role=sub as well. I think you're also missing the point -- most TLDs will never publish any DMARC record at all. In that case, how could it make any difference what tags they don't put in the records they don't publish? For the time being, TLDs with a DMARC record can be counted on the fingers of one hand, so they could be checked on a list. Still, finding role=psd (or psd=y) adds more confidence to the heuristic. The last domain with a DMARC record should be the org domain. Still, finding role=org (or psd=n) adds more confidence to the heuristic. I'm not opposed to the decision to switch from a PSL based heuristic to a tree walk based one. I'm opposed to specifying an heuristic which is worse than the previous one. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-04 feedback
Hi, I've been reading over the DMARC Aggregate Reporting draft and have some feedback on the schema and sample report. * The ActionDispositionType type definition in the schema is missing a closing tag * The schema has the DMARC report version element () specified immediately under the root element and not under as stated in section 2.1 * The draft states that has mandatory fields domain, p, and sp, and optional fields fo, adkim, aspf, and testing. The schema for PolicyPublishedType has mandatory fields domain and version_published, with all other fields optional. Should version_published be mandatory or optional? * The schema for IdentifierType has header_from and envelope_from as mandatory fields, and envelope_to as an optional field. The sample report includes only header_from. The draft text in section 2.1 says "In most cases, this will be a header_from element, which will contain the 5322.From domain from the message". Is it the intention of the draft that envelope_to should be mandatory? * The schema for SPFAuthResultType has scope (mfrom/helo) as a mandatory attribute but the sample report does not include a scope section. Should the SPF scope be a mandatory field? * The schema does not currently permit report extensions as described in the draft (section 4). I am not sure if it is possible to define a schema allowing an arbitrary element name with a required definition attribute (pointing to the extension spec). As an alternative, would it be better to have a standard element name representing an arbitrary extension, with an attribute (even just the definition URI) to identify the specific extension in use? E.g. https://www.example.com/dmarc-extension/0.1";> ... * Lastly, the draft states that reports have two primary sections, one with descriptive information and the other with row-data for the report. The "informative" section is broken into two sub-sections, which are report_metadata and policy_published. Would it perhaps be clearer to say that there are three main sections rather than two? report_metadata and policy_published are subsections of the main feedback element along with the record elements holding the row data. The schema is clear in this instance, I just wondered if the wording in the draft might be improved. Regards, Richard ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
