Re: [dmarc-ietf] Friends of Email dinner in Philadelphia, Thursday July 28 at 7:30pm
We don't have a table yet, but we have a bar tab :) come find me in my Fastmail tshirt and say hi! On Wed, Jul 6, 2022, at 18:07, Bron Gondwana wrote: > Hopefully I've hit the key working groups where those who are friends of > email (or email-adjacent stuff like calendars and contacts) are lurking. > > This coming IETF just happens to be in one of the very few cities where > Fastmail has a presence (actually, it's something about this year! We have > someone in Vienna as well - and we have a whole office full of them in > Philly). We'd love to host a dinner for friends of email while you're all in > town. Also, to persuade you to agitate for IETF to come to Melbourne some > day - but that's another topic. > > We're thinking that Thursday is best, since Monday is newcomers, Tuesday the > social, Wednesday the plenary and on Friday everybody already has one leg in > the chaos at the airport. The final session on Thursday finishes at 6:30pm, > so thinking 7:30pm for dinner. > > If you could let me know if you're interested in coming by next Wednesday, > July 13th, that gives us plenty of time to book a restaurant. Also if you > have dietary requirements that could be useful to know, so we can make sure > we go somewhere that can accommodate. I don't need a "yes I'm definitely > coming", just an indication of approximate numbers so we choose somewhere > suitable for the size of party. > > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > br...@fastmailteam.com > > -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On July 28, 2022 9:10:06 PM UTC, Alessandro Vesely wrote: >On Thu 28/Jul/2022 20:24:35 +0200 Scott Kitterman wrote: >>>If this process does not determine the Organizational Domain, then >>>the Organizational Domain is the starting domain. >>> >>> >>> The last paragraph is a puzzle. If a tree walk retrieved a DMARC record, >>> then there must exist a domain with a record with the fewest number of >>> labels. It is not needed any more. Let's replace it with: >>> >>> >>>For Tree Walks that retrieved no DMARC record, the Organizational Domain >>> is >>>undefined. No alignment can be established in such cases. >>> >> No. That's incorrect. We have discussed this exact point multiple times in >> the last several weeks. I conclude that I'm incapable of communicating this >> adequately and will leave it to someone else. > > >Yes, I remember the discussions, and some example cases where it happened. >Yet, reading again step 3: > > 3. Otherwise select the record for the domain with the fewest number > of labels. This is the Organizational Domain and the selection > process is complete. > >How can it possibly happen, in real or imaginary cases, that the org domain is >not selected after this step? > >The examples were something like psd.example.com, whose record with psd=y was >discarded on step 2. If example.com and com have no records, the record for >the domain with the fewest number of labels is still psd.example.com, so the >process concludes by step 3. > >I don't recall other examples, except the invalid ones, like .com, which I >imagined before getting that having retrieved a DMARC record was a requirement >for the input tree walk. Okay. I see what you are saying and I think it's correct, but I think it's still a good idea to keep it there to cover anything we didn't think of. I could live with removing it if that's the group's preference. This was more clearly needed before "other than the one for the domain where the tree walk started" was added in -11. I think that addressed the specific use case I had in mind. My apologies for letting my personal frustrations over the pace of the work spill over on you. Thank you for taking another shot at it. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Thu 28/Jul/2022 20:24:35 +0200 Scott Kitterman wrote: If this process does not determine the Organizational Domain, then the Organizational Domain is the starting domain. The last paragraph is a puzzle. If a tree walk retrieved a DMARC record, then there must exist a domain with a record with the fewest number of labels. It is not needed any more. Let's replace it with: For Tree Walks that retrieved no DMARC record, the Organizational Domain is undefined. No alignment can be established in such cases. No. That's incorrect. We have discussed this exact point multiple times in the last several weeks. I conclude that I'm incapable of communicating this adequately and will leave it to someone else. Yes, I remember the discussions, and some example cases where it happened. Yet, reading again step 3: 3. Otherwise select the record for the domain with the fewest number of labels. This is the Organizational Domain and the selection process is complete. How can it possibly happen, in real or imaginary cases, that the org domain is not selected after this step? The examples were something like psd.example.com, whose record with psd=y was discarded on step 2. If example.com and com have no records, the record for the domain with the fewest number of labels is still psd.example.com, so the process concludes by step 3. I don't recall other examples, except the invalid ones, like .com, which I imagined before getting that having retrieved a DMARC record was a requirement for the input tree walk. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On July 28, 2022 4:03:12 PM UTC, Alessandro Vesely wrote: >On Thu 28/Jul/2022 13:23:45 +0200 Scott Kitterman wrote: >> On Wednesday, July 27, 2022 4:05:27 AM EDT Alessandro Vesely wrote: >>> On Mon 25/Jul/2022 17:15:34 +0200 Scott Kitterman wrote: On Monday, July 25, 2022 9:59:02 AM EDT Alessandro Vesely wrote: >> ... >> Here's what's currently in Git between the shortcuts and the numbered steps (it's in Markdown, vice final RFC text, but I think it's clear enough): > To discover the Organizational Domain for a domain, perform the DNS Tree > Walk described in (#dns-tree-walk) as needed for any of the domains in > question. >>> >>> What are the "domains in question"? >>> > For each Tree Walk that retrieved valid DMARC records, select the > Organizational Domain from the domains for which valid DMARC records were > retrieved from the longest to the shortest: If we change this to: > To discover the Organizational Domain for these domains, perform the DNS > Tree Walk described in (#dns-tree-walk) as needed for the domains in > question. For each Tree Walk that retrieved valid DMARC records, select > the Organizational Domain from the domains for which valid DMARC records > were retrieved from the longest to the shortest: Does that resolve your concern? I changed "for a domain" to "for these domains" to address your concern about relaxing requirements. I think you're wrong and it makes absolutely no difference, but if you think it's better, believe it would do. I do think the two sentences would better be in one paragraph as they are not really separate ideas. >>> >>> How about moving the reference to the Tree Walk right to the first >>> sentence at the beginning of the section, for example like so: >>> >>> >>> For Organizational Domain discovery, in general it is necessary to >>> perform two DNS Tree Walks (#dns-tree-walk)" in order to determine >>> if any two domains are in alignment. Noteworthy exceptions are >>> described in (#shortcuts). A DNS Tree Walk to discover an >>> Organizational Domain can start only at one of the following >>> locations: >>> >>> * The domain in the RFC5322.From header of the message. >>> * The RFC5321.MailFrom domain if there is an SPF pass result for >>>the message. >>> * Any DKIM d= domain if there is a DKIM pass result for the >>>message for that domain. >>> >>> For each Tree Walk that retrieved valid DMARC records, select the >>> Organizational Domain from the domains for which valid DMARC >>> records were retrieved from the longest to the shortest: >>> >>> 1 ... >> >> Let's focus on this part, as I think it's most important. >> >> In general, I think that's reasonable, but I think it needs work yet. How >> about this (and I'm fine with moving the note to the end): >> >>> For Organizational Domain discovery, it will be necessary to perform one or >>> more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are in >>> alignment. This means that a DNS Tree Walk to discover an Organizational >>> Domain will start at one of the following locations: > > >We are trying to stuff two sentences in one. It is not clear if we're >discovering the org domain or establishing alignment. > > >>> * The domain in the RFC5322.From header of the message. >>> * The RFC5321.MailFrom domain if there is an SPF pass result for the >>> message. >>> * Any DKIM d= domain if there is a DKIM pass result for the message for >>> that domain. >> >>> To determine the Organizational Domain for any of these domains, perform the >>> DNS Tree Walk as needed the selected domain. > > >Splitting the first sentence, this becomes one of its parts. > > >>> For each Tree Walk that >>> retrieved valid DMARC records, select the Organizational Domain from the >>> domains for which valid DMARC records were retrieved from the longest to the >>> shortest: > > >Could that be shortened? Each step requires a DMARC record, so the domains >w/o record don't play. > >Here's another wording. I repeat the numbered steps but only change the >paragraph after them: > > >To discover the Organizational Domain of a domain, it is necessary to >analyze the DNS Tree Walk (#dns-tree-walk)" which starts from it. That may >be necessary in order to establish alignment between two domains. This >means that the starting domain is one of the following: > > * The domain in the RFC5322.From header of the message. > * The RFC5321.MailFrom domain if there is an SPF pass result for >the message. > * Any DKIM d= domain if there is a DKIM pass result for the >message for that domain. > >For a Tree Walk that retrieved a valid DMARC record, select the >Organizational Domain from its domains, from the longest toward the >shortest: > > 1. If a valid
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On July 28, 2022 3:26:45 PM UTC, Todd Herr wrote: >On Thu, Jul 28, 2022 at 10:49 AM Murray S. Kucherawy >wrote: > >> A couple of tweaks to suggest, edited in-place: >> >> On Thu, Jul 28, 2022 at 7:24 AM Scott Kitterman >> wrote: >> >>> For Organizational Domain discovery, it will be necessary to perform one >>> or >>> more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are >>> in >>> alignment. This means that each DNS Tree Walk to discover an >>> Organizational >>> Domain will start at one of the following locations: >>> >>> > * The domain in the RFC5322.From header field of the message. >>> > * The RFC5321.MailFrom domain if there is an SPF pass result for the >>> > message. >>> > * Any DKIM d= domain for which there is a DKIM pass result on the >>> message. >>> >>> > To determine the Organizational Domain for any of these domains, >>> perform the >>> > DNS Tree Walk as needed the selected domain. For each Tree Walk that >>> > retrieved valid DMARC records, select the Organizational Domain from the >>> > domains for which valid DMARC records were retrieved from the longest >>> to the >>> > shortest: >>> >> >> I just corrected a couple of typos, changed "header" to "header field", >> and accounted for the fact that a message might have multiple signatures in >> varying result combinations. >> >> >It's not clear to me from the thread whether or not the Note parts (see >below) should be kept, and if so where they should be located (end of >section 4.8?) > >Note: There is no need to perform Tree Walk searches for Organizational >Domains under any of the following conditions: <#section-4.8-3> > > - 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. <#section-4.8-4.1> > - No applicable DMARC policy is discovered for the RFC5322.From domain > during the tree walk for that domain. In this case, the DMARC mechanism > does not apply to the message in question. <#section-4.8-4.2> > - The record for the RFC5322.From domain indicates strict alignment. In > this case, a simple string compare between the RFC5322.From domain and the > RFC5321.MailFrom domain (if SPF authenticated), and/or the DKIM d= domain > (if present and authenticated) is all that is required. > My view is kept and moved to the end of the section. I actually prefer it where it is, but in the interest of moving forward, I can live with it at the end. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Thu 28/Jul/2022 13:23:45 +0200 Scott Kitterman wrote: On Wednesday, July 27, 2022 4:05:27 AM EDT Alessandro Vesely wrote: On Mon 25/Jul/2022 17:15:34 +0200 Scott Kitterman wrote: On Monday, July 25, 2022 9:59:02 AM EDT Alessandro Vesely wrote: ... Here's what's currently in Git between the shortcuts and the numbered steps (it's in Markdown, vice final RFC text, but I think it's clear enough): To discover the Organizational Domain for a domain, perform the DNS Tree Walk described in (#dns-tree-walk) as needed for any of the domains in question. What are the "domains in question"? For each Tree Walk that retrieved valid DMARC records, select the Organizational Domain from the domains for which valid DMARC records were retrieved from the longest to the shortest: If we change this to: To discover the Organizational Domain for these domains, perform the DNS Tree Walk described in (#dns-tree-walk) as needed for the domains in question. For each Tree Walk that retrieved valid DMARC records, select the Organizational Domain from the domains for which valid DMARC records were retrieved from the longest to the shortest: Does that resolve your concern? I changed "for a domain" to "for these domains" to address your concern about relaxing requirements. I think you're wrong and it makes absolutely no difference, but if you think it's better, believe it would do. I do think the two sentences would better be in one paragraph as they are not really separate ideas. How about moving the reference to the Tree Walk right to the first sentence at the beginning of the section, for example like so: For Organizational Domain discovery, in general it is necessary to perform two DNS Tree Walks (#dns-tree-walk)" in order to determine if any two domains are in alignment. Noteworthy exceptions are described in (#shortcuts). A DNS Tree Walk to discover an Organizational Domain can start only at one of the following locations: * The domain in the RFC5322.From header of the message. * The RFC5321.MailFrom domain if there is an SPF pass result for the message. * Any DKIM d= domain if there is a DKIM pass result for the message for that domain. For each Tree Walk that retrieved valid DMARC records, select the Organizational Domain from the domains for which valid DMARC records were retrieved from the longest to the shortest: 1 ... Let's focus on this part, as I think it's most important. In general, I think that's reasonable, but I think it needs work yet. How about this (and I'm fine with moving the note to the end): For Organizational Domain discovery, it will be necessary to perform one or more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are in alignment. This means that a DNS Tree Walk to discover an Organizational Domain will start at one of the following locations: We are trying to stuff two sentences in one. It is not clear if we're discovering the org domain or establishing alignment. * The domain in the RFC5322.From header of the message. * The RFC5321.MailFrom domain if there is an SPF pass result for the message. * Any DKIM d= domain if there is a DKIM pass result for the message for that domain. To determine the Organizational Domain for any of these domains, perform the DNS Tree Walk as needed the selected domain. Splitting the first sentence, this becomes one of its parts. For each Tree Walk that retrieved valid DMARC records, select the Organizational Domain from the domains for which valid DMARC records were retrieved from the longest to the shortest: Could that be shortened? Each step requires a DMARC record, so the domains w/o record don't play. Here's another wording. I repeat the numbered steps but only change the paragraph after them: To discover the Organizational Domain of a domain, it is necessary to analyze the DNS Tree Walk (#dns-tree-walk)" which starts from it. That may be necessary in order to establish alignment between two domains. This means that the starting domain is one of the following: * The domain in the RFC5322.From header of the message. * The RFC5321.MailFrom domain if there is an SPF pass result for the message. * Any DKIM d= domain if there is a DKIM pass result for the message for that domain. For a Tree Walk that retrieved a valid DMARC record, select the Organizational Domain from its domains, from the longest toward the shortest: 1. If a valid DMARC record contains the psd= tag set to 'n' (psd=n), this is the Organizational Domain and the selection process is complete. 2. If a valid DMARC record, other than the one for the domain where the tree walk started, contains the psd= tag set to 'y' (psd=y), the Organizational Domain is the domain one label below this one in the DNS hierarchy, and the
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-15.txt
This rev was generated from the pull request John submitted with the Updated PSD Example. On Thu, Jul 28, 2022 at 11:32 AM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance WG of the IETF. > > Title : Domain-based Message Authentication, Reporting, > and Conformance (DMARC) > Authors : Todd M. Herr > John Levine > Filename: draft-ietf-dmarc-dmarcbis-15.txt > Pages : 69 > Date: 2022-07-28 > > Abstract: >This document describes the Domain-based Message Authentication, >Reporting, and Conformance (DMARC) protocol. > >DMARC permits the owner of an email author's domain name to enable >verification of the domain's use, to indicate the Domain Owner's or >Public Suffix Operator's message handling preference regarding failed >verification, and to request reports about use of the domain name. >Mail receiving organizations can use this information when evaluating >handling choices for incoming mail. > >This document obsoletes RFC 7489. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-15.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-15 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *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-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-15.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Domain-based Message Authentication, Reporting, and Conformance (DMARC) Authors : Todd M. Herr John Levine Filename: draft-ietf-dmarc-dmarcbis-15.txt Pages : 69 Date: 2022-07-28 Abstract: This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email author's domain name to enable verification of the domain's use, to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed verification, and to request reports about use of the domain name. Mail receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFC 7489. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-15.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-15 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Thu, Jul 28, 2022 at 10:49 AM Murray S. Kucherawy wrote: > A couple of tweaks to suggest, edited in-place: > > On Thu, Jul 28, 2022 at 7:24 AM Scott Kitterman > wrote: > >> For Organizational Domain discovery, it will be necessary to perform one >> or >> more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are >> in >> alignment. This means that each DNS Tree Walk to discover an >> Organizational >> Domain will start at one of the following locations: >> >> > * The domain in the RFC5322.From header field of the message. >> > * The RFC5321.MailFrom domain if there is an SPF pass result for the >> > message. >> > * Any DKIM d= domain for which there is a DKIM pass result on the >> message. >> >> > To determine the Organizational Domain for any of these domains, >> perform the >> > DNS Tree Walk as needed the selected domain. For each Tree Walk that >> > retrieved valid DMARC records, select the Organizational Domain from the >> > domains for which valid DMARC records were retrieved from the longest >> to the >> > shortest: >> > > I just corrected a couple of typos, changed "header" to "header field", > and accounted for the fact that a message might have multiple signatures in > varying result combinations. > > It's not clear to me from the thread whether or not the Note parts (see below) should be kept, and if so where they should be located (end of section 4.8?) Note: There is no need to perform Tree Walk searches for Organizational Domains under any of the following conditions: <#section-4.8-3> - 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. <#section-4.8-4.1> - No applicable DMARC policy is discovered for the RFC5322.From domain during the tree walk for that domain. In this case, the DMARC mechanism does not apply to the message in question. <#section-4.8-4.2> - The record for the RFC5322.From domain indicates strict alignment. In this case, a simple string compare between the RFC5322.From domain and the RFC5321.MailFrom domain (if SPF authenticated), and/or the DKIM d= domain (if present and authenticated) is all that is required. -- *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] Shortcuts: parent-child allows shorter tree walks
A couple of tweaks to suggest, edited in-place: On Thu, Jul 28, 2022 at 7:24 AM Scott Kitterman wrote: > For Organizational Domain discovery, it will be necessary to perform one > or > more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are > in > alignment. This means that each DNS Tree Walk to discover an > Organizational > Domain will start at one of the following locations: > > > * The domain in the RFC5322.From header field of the message. > > * The RFC5321.MailFrom domain if there is an SPF pass result for the > > message. > > * Any DKIM d= domain for which there is a DKIM pass result on the > message. > > > To determine the Organizational Domain for any of these domains, perform > the > > DNS Tree Walk as needed the selected domain. For each Tree Walk that > > retrieved valid DMARC records, select the Organizational Domain from the > > domains for which valid DMARC records were retrieved from the longest to > the > > shortest: > I just corrected a couple of typos, changed "header" to "header field", and accounted for the fact that a message might have multiple signatures in varying result combinations. -MSK -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Updated PSD example
I made a pull request that changes the PSD example to show how names under a PSD are and aren't aligned, It uses giant.bank.example and mega.bank.example, with bank.example having psd=y. https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/pull/95 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] Shortcuts: parent-child allows shorter tree walks
On Wednesday, July 27, 2022 4:05:27 AM EDT Alessandro Vesely wrote: > On Mon 25/Jul/2022 17:15:34 +0200 Scott Kitterman wrote: > > On Monday, July 25, 2022 9:59:02 AM EDT Alessandro Vesely wrote: ... > > Here's what's currently in Git between the shortcuts and the numbered > > steps > > > > (it's in Markdown, vice final RFC text, but I think it's clear enough): > >> To discover the Organizational Domain for a domain, perform the DNS Tree > >> Walk described in (#dns-tree-walk) as needed for any of the domains in > >> question. > > What are the "domains in question"? > > >> For each Tree Walk that retrieved valid DMARC records, select the > >> Organizational Domain from the domains for which valid DMARC records were > > > >> retrieved from the longest to the shortest: > > If we change this to: > >> To discover the Organizational Domain for these domains, perform the DNS > >> Tree Walk described in (#dns-tree-walk) as needed for the domains in > >> question. For each Tree Walk that retrieved valid DMARC records, select > >> the Organizational Domain from the domains for which valid DMARC records > >> were> > >> retrieved from the longest to the shortest: > > Does that resolve your concern? I changed "for a domain" to "for these > > domains" to address your concern about relaxing requirements. I think > > you're wrong and it makes absolutely no difference, but if you think it's > > better, believe it would do. I do think the two sentences would better > > be in one paragraph as they are not really separate ideas. > > How about moving the reference to the Tree Walk right to the first > sentence at the beginning of the section, for example like so: > > > For Organizational Domain discovery, in general it is necessary to > perform two DNS Tree Walks (#dns-tree-walk)" in order to determine > if any two domains are in alignment. Noteworthy exceptions are > described in (#shortcuts). A DNS Tree Walk to discover an > Organizational Domain can start only at one of the following > locations: > > * The domain in the RFC5322.From header of the message. > * The RFC5321.MailFrom domain if there is an SPF pass result for >the message. > * Any DKIM d= domain if there is a DKIM pass result for the >message for that domain. > > For each Tree Walk that retrieved valid DMARC records, select the > Organizational Domain from the domains for which valid DMARC > records were retrieved from the longest to the shortest: > > 1 ... Let's focus on this part, as I think it's most important. In general, I think that's reasonable, but I think it needs work yet. How about this (and I'm fine with moving the note to the end): > For Organizational Domain discovery, it will be necessary to perform one or more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are in alignment. This means that a DNS Tree Walk to discover an Organizational Domain will start at once of the following locations: > > * The domain in the RFC5322.From header of the message. > * The RFC5321.MailFrom domain if there is an SPF pass result for the > message. > * Any DKIM d= domain if there is a DKIM pass result for the message for > that domain. > To determine the Organizational Domain for any of thes domains, perform the > DNS Tree Walk as needed the selected domain. For each Tree Walk that > retrieved valid DMARC records, select the Organizational Domain from the > domains for which valid DMARC records were retrieved from the longest to the > shortest: > > 1. If a Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
