Re: [dmarc-ietf] Bridging the gap
It appears that Scott Kitterman said: >I had been thinking M3AAWG would be a good venue. fTLD (who runs .bank and . >insurance) recently gave a presentation about PSD DMARC at an ICANN tech >day. I think there are multiple avenues of approach that we can use without >having to invoke the IETF directly. Hi, I just got back from the London M3AAWG meeting yesterday. I think it'd be a reasonable thing to suggest that they do along with some current work getting people to better deploy DKIM. Barry and Seth were both there so I don't think we need any further liasing. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Bridging the gap
On June 18, 2022 10:35:11 PM UTC, Dotzero wrote: >On Sat, Jun 18, 2022 at 11:45 AM Barry Leiba >wrote: > >> I don't know... I would say that if the working group has rough >> consensus to reach out and asks someone(s) to do it, they could then >> say that they're calling on behalf of the working group. No? >> >> Barry >> > >Personally, if this is implemented, I think it would be better if a group >like M3AAWG were to volunteer or take on such a role. Murray has pointed >out some of the issues with someone reaching out on behalf of the working >group. The only people I can think of who could remotely claim to represent >the working group would be the chairs. Do we really want to go there? I had been thinking M3AAWG would be a good venue. fTLD (who runs .bank and . insurance) recently gave a presentation about PSD DMARC at an ICANN tech day. I think there are multiple avenues of approach that we can use without having to invoke the IETF directly. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Bridging the gap
On Sat, Jun 18, 2022 at 11:45 AM Barry Leiba wrote: > I don't know... I would say that if the working group has rough > consensus to reach out and asks someone(s) to do it, they could then > say that they're calling on behalf of the working group. No? > > Barry > Personally, if this is implemented, I think it would be better if a group like M3AAWG were to volunteer or take on such a role. Murray has pointed out some of the issues with someone reaching out on behalf of the working group. The only people I can think of who could remotely claim to represent the working group would be the chairs. Do we really want to go there? Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Bridging the gap
I don't know... I would say that if the working group has rough consensus to reach out and asks someone(s) to do it, they could then say that they're calling on behalf of the working group. No? Barry On Sat, Jun 18, 2022 at 4:28 PM Murray S. Kucherawy wrote: > > On Sat, Jun 18, 2022 at 4:26 AM Alessandro Vesely wrote: >> >> Actually sending those messages would sound more credible if done From: >> some...@ietf.org. Does such a role exist? > > > No. We participate here as individuals, so whoever does this will be doing > it as herself or himself. You probably can't claim to represent the working > group either, though you could say you're a participant in it. > > -MSK, ART AD > ___ > 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] Bridging the gap
On Sat, Jun 18, 2022 at 4:26 AM Alessandro Vesely wrote: > Actually sending those messages would sound more credible if done From: > some...@ietf.org. Does such a role exist? > No. We participate here as individuals, so whoever does this will be doing it as herself or himself. You probably can't claim to represent the working group either, though you could say you're a participant in it. -MSK, ART AD ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Bridging the gap
On Saturday, June 18, 2022 7:25:28 AM EDT Alessandro Vesely wrote: > On Sat 18/Jun/2022 02:40:49 +0200 Scott Kitterman wrote: > > On Thursday, June 16, 2022 11:57:08 AM EDT Alessandro Vesely wrote: > >> On Wed 15/Jun/2022 19:47:42 +0200 John Levine wrote: > >>> It appears that Alessandro Vesely said: > I think we found the few critical domains which need a flag. > >>> > >>> We may have found some domains that need a psd flag, but it's silly to > >>> assert we have found all or even most of them. > >>> > >>> The PSL has 9300 entries and there are surely far more places in the DNS > >>> than that where you want sibling domains to be separate. > >> > >> Is there someone who is going to contact, on behalf of the WG, the > >> domains > >> that were found in order to have their owners publish psd= flags before > >> the > >> RFC is published? > > > > It is a project I intend to work on once the psd= tag has been assigned. > > Until the working group has settled on it more definitively than "it's in > > the current draft" I think it would be premature to bother them. > > Agreed, we can wait until RFC queue. I don't think we need to wait that long. I have heard the designated expert for the registry is open to early registration if the chairs determine there is rough consensus for psd=. > I think many of the required tasks can be discussed here. Namely: > > * Listing relevant domains, > * finding contacts for listed domains, > * composing the text of an email to send them. > > Actually sending those messages would sound more credible if done From: > some...@ietf.org. Does such a role exist? I don't think so. In my experience it's external groups that are interested in a new technology that deal with evangelizing it once developed by the IETF. Since RFCs don't write themselves, there's generally someone. > > From your list further down the thread, why do you think having a psd=y > > tag on gov.uk, police.uk, and mil will have? While it would be more > > descriptively correct, I don't think there's any operational difference > > if it's there or not since sub-domains of those PSDs are controlled by > > one organization. > I don't know how much control do parent domains exercise downwards. It > probably varies widely in each case. Anyway, the tree walk needs those > flags in order to work properly. > > > If us.com had a DMARC record, that would be worth a discussion, but they > > don't. > > Why does uk.com differ? They do have a DMARC record. I have no idea why they are different, but that's the best example I've seen so far of a record for which psd=y would be important. Once the tag is assigned, someone should definitely discuss this with CentralNic. If no one on the list knows someone there, my guess is that it's almost a certainty that someone on the list knows someone who does. > > It's not even the ~500 domains on the PSL that have DMARC records > > published > > that we need to concern ourselves with, it's a small subset of them. > > I counted 238 of them, discarding the ones with '*'s. Many can be grouped, > for example blogspots and all Google stuff. The PSL refers contacts in > comments. > > I don't know how to better select the domains which need to set the flag. > Presumably, the mail will say something such that each domain owner can > understand which domains are involved. I'm willing to work on this at the appropriate time and i know others who are as well. I think, for now, we should proceed on the assumption that the evangelization of the psd= tag will get done. It needn't be done overnight as it will have no effect until mail receivers implement the associated processing. That will be the bigger lift in my opinion. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Bridging the gap
On Sat 18/Jun/2022 02:40:49 +0200 Scott Kitterman wrote: On Thursday, June 16, 2022 11:57:08 AM EDT Alessandro Vesely wrote: On Wed 15/Jun/2022 19:47:42 +0200 John Levine wrote: It appears that Alessandro Vesely said: I think we found the few critical domains which need a flag. We may have found some domains that need a psd flag, but it's silly to assert we have found all or even most of them. The PSL has 9300 entries and there are surely far more places in the DNS than that where you want sibling domains to be separate. Is there someone who is going to contact, on behalf of the WG, the domains that were found in order to have their owners publish psd= flags before the RFC is published? It is a project I intend to work on once the psd= tag has been assigned. Until the working group has settled on it more definitively than "it's in the current draft" I think it would be premature to bother them. Agreed, we can wait until RFC queue. I think many of the required tasks can be discussed here. Namely: * Listing relevant domains, * finding contacts for listed domains, * composing the text of an email to send them. Actually sending those messages would sound more credible if done From: some...@ietf.org. Does such a role exist? From your list further down the thread, why do you think having a psd=y tag on gov.uk, police.uk, and mil will have? While it would be more descriptively correct, I don't think there's any operational difference if it's there or not since sub-domains of those PSDs are controlled by one organization. I don't know how much control do parent domains exercise downwards. It probably varies widely in each case. Anyway, the tree walk needs those flags in order to work properly. If us.com had a DMARC record, that would be worth a discussion, but they don't. Why does uk.com differ? They do have a DMARC record. It's not even the ~500 domains on the PSL that have DMARC records published that we need to concern ourselves with, it's a small subset of them. I counted 238 of them, discarding the ones with '*'s. Many can be grouped, for example blogspots and all Google stuff. The PSL refers contacts in comments. I don't know how to better select the domains which need to set the flag. Presumably, the mail will say something such that each domain owner can understand which domains are involved. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Bridging the gap
On Fri, 17 Jun 2022, Alessandro Vesely wrote: If you think that's important, why don't you do it? Is that a mandate? We'll have to check with the Network Police and see what they say. As we have discussed ad nauseam, even without adding any PSD tags the tree walk will usually give results at least as good as the PSL. And as we have also discussed, for any domain that cares, it's a whole lot easier to publish a DMARC record or two than to get an entry in the PSL 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] Bridging the gap
On Thursday, June 16, 2022 11:57:08 AM EDT Alessandro Vesely wrote: > On Wed 15/Jun/2022 19:47:42 +0200 John Levine wrote: > > It appears that Alessandro Vesely said: > >>I think we found the few critical domains which need a flag. > >> > > We may have found some domains that need a psd flag, but it's silly to > > assert we have found all or even most of them. > > > > The PSL has 9300 entries and there are surely far more places in the DNS > > than that where you want sibling domains to be separate. > > Is there someone who is going to contact, on behalf of the WG, the domains > that were found in order to have their owners publish psd= flags before the > RFC is published? It is a project I intend to work on once the psd= tag has been assigned. Until the working group has settled on it more definitively than "it's in the current draft" I think it would be premature to bother them. >From your list further down the thread, why do you think having a psd=y tag on gov.uk, police.uk, and mil will have? While it would be more descriptively correct, I don't think there's any operational difference if it's there or not since sub-domains of those PSDs are controlled by one organization. If us.com had a DMARC record, that would be worth a discussion, but they don't. It's not even the ~500 domains on the PSL that have DMARC records published that we need to concern ourselves with, it's a small subset of them. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Bridging the gap
On Wed 15/Jun/2022 19:47:42 +0200 John Levine wrote: Is there someone who is going to contact, on behalf of the WG, the domains that were found in order to have their owners publish psd= flags before the RFC is published? If you think that's important, why don't you do it? 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] Bridging the gap
On Wed 15/Jun/2022 19:47:42 +0200 John Levine wrote: It appears that Alessandro Vesely said: I think we found the few critical domains which need a flag. We may have found some domains that need a psd flag, but it's silly to assert we have found all or even most of them. The PSL has 9300 entries and there are surely far more places in the DNS than that where you want sibling domains to be separate. Is there someone who is going to contact, on behalf of the WG, the domains that were found in order to have their owners publish psd= flags before the RFC is published? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Bridging the gap
It appears that Alessandro Vesely said: >I think we found the few critical domains which need a flag. We may have found some domains that need a psd flag, but it's silly to assert we have found all or even most of them. The PSL has 9300 entries and there are surely far more places in the DNS than that where you want sibling domains to be separate. The PSL only cares about web cookies, which do not always separate at the same places that DMARC does. The PSL is often wrong for DMARC and I see no reason to assume that even without PSD that a tree walk would produce less accurate results than the PSL does. On the other hand, it is a whole lot easier to publish a psd=y DMARC record than to get an entry into the PSL so for anyone who cares about this, they have a straightforward way to fix their problems. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Bridging the gap
On Wed 15/Jun/2022 04:40:31 +0200 Douglas Foster wrote: The problem seems rooted in our different attitudes toward the PSL. If one assumes that the Tree Walk must displace the PSL completely and quickly, then it becomes necessary to “make do” with incomplete information about organizational boundaries, even though this introduces unwanted risk to evaluators. I believe that the assumption is unnecessary, because the Tree Walk and the PSL can coexist without harm. We simply specify that the Tree Walk algorithm MUST be used when organizational boundary information is known to be complete and certain, as indicated by specific policy tags, while the PSL MAY be used when boundary information is uncertain or incomplete. I think we found the few critical domains which need a flag. I agree we should monitor the publishing of those flags before publishing the RFC, and possibly also afterwards. At that point, the tree walk should be safe to use for all DMARC filters. Yet, not all DMARC filters will be upgraded overnight. Use of the PSL is going to persist for some time. Mail filters which use the PSL also for other reasons may continue to do so even after upgrading to the tree walk for DMARC purposes. They may also compare tree walk and PSL results. I think that implementing a standard always leaves some leeway to the programmer. As long as the correct result is the outcome of the tree walk, programmers are free to decide how to manage data. They are not forced to throw away PSL lookups. The “Must-use-Tree-Walk” indicator provides the domain owner with a remedy to correct PSL errors, as well as a strategy for avoiding them. The MUST indicator also means that DMARCbis-compliant implementations MUST implement the Tree Walk algorithm, ensuring that the new algorithm becomes deployed with critical mass. I'd be skeptical about user defined “Must-use-Tree-Walk” indicators. The psd= flag (or whatever we'll call it when we'll ask the owners of critical domains to set it) is functional and should be monitored. Any additional flag, statically set and forgotten by the domain owner, would always be questionable. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Bridging the gap
I have done a lot of thinking about the current confrontation and how to bridge it. The problem seems rooted in our different attitudes toward the PSL. If one assumes that the Tree Walk must displace the PSL completely and quickly, then it becomes necessary to “make do” with incomplete information about organizational boundaries, even though this introduces unwanted risk to evaluators. I believe that the assumption is unnecessary, because the Tree Walk and the PSL can coexist without harm. We simply specify that the Tree Walk algorithm MUST be used when organizational boundary information is known to be complete and certain, as indicated by specific policy tags, while the PSL MAY be used when boundary information is uncertain or incomplete. The “Must-use-Tree-Walk” indicator provides the domain owner with a remedy to correct PSL errors, as well as a strategy for avoiding them.The MUST indicator also means that DMARCbis-compliant implementations MUST implement the Tree Walk algorithm, ensuring that the new algorithm becomes deployed with critical mass. The “MUST-use-Tree-Walk” assertion is accomplished with a DMARC policy tag on the organizational domain record, supplemented by DMARC policy tags to indicate the boundaries of any contained sub-organizations. Some processing guidelines will need to be provided to ensure that the Must-use-Tree-Walk indicator is always found when it is present. Doug ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
