Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
That might do it. Scott K On November 1, 2021 10:03:06 PM UTC, Joe Humphreys wrote: >Sorry, I missed that. But I disagree with this statement: > >I think that if we changed the relaxed definition to the same as or a >sub-domain of the From domain it would avoid potential issues like that >without practical impact. I don't think I have ever seen legitimate mail >where Mail From or DKIM signing domain wasn't either the same or a >sub-domain of From that were in the same org domain. > > >We send tens of millions of such messages daily. These are messages where >the From address is nore...@application.organization.com, and the DKIM >signing domain is just organization.com. > >I suggest again that the simple answer is for the DMARC record itself to >specify the organizational domain. This is orthogonal to how you discover >the DMARC record. > >Regards, >Joe Humphreys > > >On Mon, Nov 1, 2021 at 4:26 PM Scott Kitterman wrote: > >> That was addressed in Message-ID: >> <7ca0f341-7a14-46ee-8be6-66e3f2537...@kitterman.com>. >> >> Scott K >> >> On Monday, November 1, 2021 3:30:13 PM EDT Joe Humphreys wrote: >> > Scott, your proposal says to remove any reference to organizational >> domain, >> > but you don't explain how you will define DKIM and SPF alignment without >> > reference to organizational domain. >> > >> > In your proposal, if the query at step 1 does return a record, and the >> > record specifies relaxed alignment, then the receiver does not have >> enough >> > information to evaluate alignment. >> > >> > This is not an academic point. The organization I work for relies on >> > relaxed alignment, and we sometimes create DMARC records for subdomains >> > (usually because we've identified a subdomain that we're not yet ready to >> > apply p=none to). I don't see how this will work under your proposal. >> > >> > Regards, >> > Joe Humphreys >> > >> > >> > On Sun, Oct 31, 2021 at 10:46 PM Scott Kitterman >> > >> > wrote: >> > > On November 1, 2021 2:19:02 AM UTC, Douglas Foster < >> > > >> > > dougfoster.emailstanda...@gmail.com> wrote: >> > > >Currently, the Publicssuffix.org list protects the PSL names. >> Although >> > > >I >> > > >don't believe it is covered anywhere in the DMARC v1 document, any >> DMARC >> > > >implementer will have to notice that a PSL name must produce DMARC >> FAIL, >> > > >because it cannot be authenticated itself, and it cannot be >> authenticated >> > > >by alignment with any other domain name. >> > > > >> > > >If we could publish a rule which limits alignment to only work from an >> > > >authenticated domain name downward to a child subdomain, we would >> have a >> > > >secure design, because we would not need to worry about leaving the >> > > >authenticated organization. But as long as upward alignment is >> > > >necessitated by current practice, we need to be concerned about >> leaving >> > > >> > > the >> > > >> > > >authenticated organization in the upward direction into the PSL. >> > > > >> > > >A specific example: >> > > >MailFrom is "spam...@example.com" and From is "trustme@com". >> > > >Any acceptable replacement for the PSL must ensure that this >> identifier >> > > >configuration is rejected. >> > > > >> > > >When moving up the domain tree, the only way to avoid transiting from >> an >> > > >authenticated organization into the PSL, is to know what names are in >> the >> > > >PSL.The alternatives seem to be (a) an externally obtained list, >> no >> > > >matter how imperfect, or (b) DNS entries, no matter how imperfect. >> The >> > > >list seems the best option in the near term, but the DNS option might >> > > >> > > prove >> > > >> > > >valuable over time. >> > > >> > > What's wrong with what I already proposed? >> > > >> > > Your analysis is backwards. Modulo the few PSDs that have published >> > > records for PSD DMARC and for receivers that check for it, the DMARC >> > > results for mail to such domains is none, not fail. >> > > >> > > Scott K >> > > >> > > ___ >> > > dmarc mailing list >> > > dmarc@ietf.org >> > > https://www.ietf.org/mailman/listinfo/dmarc >> >> >> >> >> ___ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
Sorry, I missed that. But I disagree with this statement: I think that if we changed the relaxed definition to the same as or a sub-domain of the From domain it would avoid potential issues like that without practical impact. I don't think I have ever seen legitimate mail where Mail From or DKIM signing domain wasn't either the same or a sub-domain of From that were in the same org domain. We send tens of millions of such messages daily. These are messages where the From address is nore...@application.organization.com, and the DKIM signing domain is just organization.com. I suggest again that the simple answer is for the DMARC record itself to specify the organizational domain. This is orthogonal to how you discover the DMARC record. Regards, Joe Humphreys On Mon, Nov 1, 2021 at 4:26 PM Scott Kitterman wrote: > That was addressed in Message-ID: > <7ca0f341-7a14-46ee-8be6-66e3f2537...@kitterman.com>. > > Scott K > > On Monday, November 1, 2021 3:30:13 PM EDT Joe Humphreys wrote: > > Scott, your proposal says to remove any reference to organizational > domain, > > but you don't explain how you will define DKIM and SPF alignment without > > reference to organizational domain. > > > > In your proposal, if the query at step 1 does return a record, and the > > record specifies relaxed alignment, then the receiver does not have > enough > > information to evaluate alignment. > > > > This is not an academic point. The organization I work for relies on > > relaxed alignment, and we sometimes create DMARC records for subdomains > > (usually because we've identified a subdomain that we're not yet ready to > > apply p=none to). I don't see how this will work under your proposal. > > > > Regards, > > Joe Humphreys > > > > > > On Sun, Oct 31, 2021 at 10:46 PM Scott Kitterman > > > > wrote: > > > On November 1, 2021 2:19:02 AM UTC, Douglas Foster < > > > > > > dougfoster.emailstanda...@gmail.com> wrote: > > > >Currently, the Publicssuffix.org list protects the PSL names. > Although > > > >I > > > >don't believe it is covered anywhere in the DMARC v1 document, any > DMARC > > > >implementer will have to notice that a PSL name must produce DMARC > FAIL, > > > >because it cannot be authenticated itself, and it cannot be > authenticated > > > >by alignment with any other domain name. > > > > > > > >If we could publish a rule which limits alignment to only work from an > > > >authenticated domain name downward to a child subdomain, we would > have a > > > >secure design, because we would not need to worry about leaving the > > > >authenticated organization. But as long as upward alignment is > > > >necessitated by current practice, we need to be concerned about > leaving > > > > > > the > > > > > > >authenticated organization in the upward direction into the PSL. > > > > > > > >A specific example: > > > >MailFrom is "spam...@example.com" and From is "trustme@com". > > > >Any acceptable replacement for the PSL must ensure that this > identifier > > > >configuration is rejected. > > > > > > > >When moving up the domain tree, the only way to avoid transiting from > an > > > >authenticated organization into the PSL, is to know what names are in > the > > > >PSL.The alternatives seem to be (a) an externally obtained list, > no > > > >matter how imperfect, or (b) DNS entries, no matter how imperfect. > The > > > >list seems the best option in the near term, but the DNS option might > > > > > > prove > > > > > > >valuable over time. > > > > > > What's wrong with what I already proposed? > > > > > > Your analysis is backwards. Modulo the few PSDs that have published > > > records for PSD DMARC and for receivers that check for it, the DMARC > > > results for mail to such domains is none, not fail. > > > > > > Scott K > > > > > > ___ > > > dmarc mailing list > > > dmarc@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmarc > > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
That was addressed in Message-ID: <7ca0f341-7a14-46ee-8be6-66e3f2537...@kitterman.com>. Scott K On Monday, November 1, 2021 3:30:13 PM EDT Joe Humphreys wrote: > Scott, your proposal says to remove any reference to organizational domain, > but you don't explain how you will define DKIM and SPF alignment without > reference to organizational domain. > > In your proposal, if the query at step 1 does return a record, and the > record specifies relaxed alignment, then the receiver does not have enough > information to evaluate alignment. > > This is not an academic point. The organization I work for relies on > relaxed alignment, and we sometimes create DMARC records for subdomains > (usually because we've identified a subdomain that we're not yet ready to > apply p=none to). I don't see how this will work under your proposal. > > Regards, > Joe Humphreys > > > On Sun, Oct 31, 2021 at 10:46 PM Scott Kitterman > > wrote: > > On November 1, 2021 2:19:02 AM UTC, Douglas Foster < > > > > dougfoster.emailstanda...@gmail.com> wrote: > > >Currently, the Publicssuffix.org list protects the PSL names. Although > > >I > > >don't believe it is covered anywhere in the DMARC v1 document, any DMARC > > >implementer will have to notice that a PSL name must produce DMARC FAIL, > > >because it cannot be authenticated itself, and it cannot be authenticated > > >by alignment with any other domain name. > > > > > >If we could publish a rule which limits alignment to only work from an > > >authenticated domain name downward to a child subdomain, we would have a > > >secure design, because we would not need to worry about leaving the > > >authenticated organization. But as long as upward alignment is > > >necessitated by current practice, we need to be concerned about leaving > > > > the > > > > >authenticated organization in the upward direction into the PSL. > > > > > >A specific example: > > >MailFrom is "spam...@example.com" and From is "trustme@com". > > >Any acceptable replacement for the PSL must ensure that this identifier > > >configuration is rejected. > > > > > >When moving up the domain tree, the only way to avoid transiting from an > > >authenticated organization into the PSL, is to know what names are in the > > >PSL.The alternatives seem to be (a) an externally obtained list, no > > >matter how imperfect, or (b) DNS entries, no matter how imperfect.The > > >list seems the best option in the near term, but the DNS option might > > > > prove > > > > >valuable over time. > > > > What's wrong with what I already proposed? > > > > Your analysis is backwards. Modulo the few PSDs that have published > > records for PSD DMARC and for receivers that check for it, the DMARC > > results for mail to such domains is none, not fail. > > > > Scott K > > > > ___ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
Scott, your proposal says to remove any reference to organizational domain, but you don't explain how you will define DKIM and SPF alignment without reference to organizational domain. In your proposal, if the query at step 1 does return a record, and the record specifies relaxed alignment, then the receiver does not have enough information to evaluate alignment. This is not an academic point. The organization I work for relies on relaxed alignment, and we sometimes create DMARC records for subdomains (usually because we've identified a subdomain that we're not yet ready to apply p=none to). I don't see how this will work under your proposal. Regards, Joe Humphreys On Sun, Oct 31, 2021 at 10:46 PM Scott Kitterman wrote: > > > On November 1, 2021 2:19:02 AM UTC, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >Currently, the Publicssuffix.org list protects the PSL names. Although I > >don't believe it is covered anywhere in the DMARC v1 document, any DMARC > >implementer will have to notice that a PSL name must produce DMARC FAIL, > >because it cannot be authenticated itself, and it cannot be authenticated > >by alignment with any other domain name. > > > >If we could publish a rule which limits alignment to only work from an > >authenticated domain name downward to a child subdomain, we would have a > >secure design, because we would not need to worry about leaving the > >authenticated organization. But as long as upward alignment is > >necessitated by current practice, we need to be concerned about leaving > the > >authenticated organization in the upward direction into the PSL. > > > >A specific example: > >MailFrom is "spam...@example.com" and From is "trustme@com". > >Any acceptable replacement for the PSL must ensure that this identifier > >configuration is rejected. > > > >When moving up the domain tree, the only way to avoid transiting from an > >authenticated organization into the PSL, is to know what names are in the > >PSL.The alternatives seem to be (a) an externally obtained list, no > >matter how imperfect, or (b) DNS entries, no matter how imperfect.The > >list seems the best option in the near term, but the DNS option might > prove > >valuable over time. > > What's wrong with what I already proposed? > > Your analysis is backwards. Modulo the few PSDs that have published > records for PSD DMARC and for receivers that check for it, the DMARC > results for mail to such domains is none, not fail. > > Scott K > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On November 1, 2021 2:19:02 AM UTC, Douglas Foster wrote: >Currently, the Publicssuffix.org list protects the PSL names. Although I >don't believe it is covered anywhere in the DMARC v1 document, any DMARC >implementer will have to notice that a PSL name must produce DMARC FAIL, >because it cannot be authenticated itself, and it cannot be authenticated >by alignment with any other domain name. > >If we could publish a rule which limits alignment to only work from an >authenticated domain name downward to a child subdomain, we would have a >secure design, because we would not need to worry about leaving the >authenticated organization. But as long as upward alignment is >necessitated by current practice, we need to be concerned about leaving the >authenticated organization in the upward direction into the PSL. > >A specific example: >MailFrom is "spam...@example.com" and From is "trustme@com". >Any acceptable replacement for the PSL must ensure that this identifier >configuration is rejected. > >When moving up the domain tree, the only way to avoid transiting from an >authenticated organization into the PSL, is to know what names are in the >PSL.The alternatives seem to be (a) an externally obtained list, no >matter how imperfect, or (b) DNS entries, no matter how imperfect.The >list seems the best option in the near term, but the DNS option might prove >valuable over time. What's wrong with what I already proposed? Your analysis is backwards. Modulo the few PSDs that have published records for PSD DMARC and for receivers that check for it, the DMARC results for mail to such domains is none, not fail. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
Ad hominem dismissal of things that you disagree with as "crazy talk" is not an effective form of technical argument. Care to try again. Scott K On November 1, 2021 1:29:19 AM UTC, Douglas Foster wrote: >To my mind, it is crazy talk to assert that DMARC is not an authentication >method. > >My bank's phone app gives me the option of authenticating with either a >username+password or a fingerprint. For remote access to work computers, >I use two authentication methods together. Using two component methods to >accomplish an authentication process does not cause it to be something >other than an authentication process. > >Specific to DMARC: >The sender's policy suggestion is probably the least important part of >DMARC v1.The evidence given to this forum says that most senders do not >have a DMARC policy. Of those that do, the policy is most often NONE, and >therefore useless. Of all the mail that is blocked by >automation because of p=(reject | quarantine), a significant portion is >blocked for reasons that the recipient user considers incorrect.So the >proportion of mail which is properly blocked because of a DMARC policy >looks rather tiny. > >Nonetheless, about 85% of my incoming messages have FROM addresses that I >classify as "reliably identified". This is mostly because of DMARC PASS, >but I also use some local policies serve as alternatives to DMARC PASS. I >don't need a DMARC policy to produce DMARC PASS or FAIL. > >A sender's policy expression is only meaningful because DMARC invented an >algorithm for authenticating the FROM address, something that had never >been done before. Without an algorithm to generate PASS or FAIL, there is >nothing about which a sender can make a disposition suggestion. > >Doug Foster > >On Sun, Oct 31, 2021 at 1:50 PM Dotzero wrote: > >> >> >> On Sun, Oct 31, 2021 at 1:03 PM Scott Kitterman >> wrote: >> >>> Perhaps it's a pointless semantic distinction. I think of DMARC as a >>> mechanism for expressing policy about authentication, not an authentication >>> method. >>> >>> I still don't understand what you think is unprotected. >>> >>> Scott K >>> >> >> +1 >> >> DMARC allows the owners or administrators of a domain to express a policy >> for email messages which fail to pass aligned DKIM or SPF and request >> validators/receivers to act on that policy. In and of itself DMARC is not >> an authentication method. >> >> Michael Hammer >> ___ >> 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] Topic for IETF 112 - Policy Discovery
Currently, the Publicssuffix.org list protects the PSL names. Although I don't believe it is covered anywhere in the DMARC v1 document, any DMARC implementer will have to notice that a PSL name must produce DMARC FAIL, because it cannot be authenticated itself, and it cannot be authenticated by alignment with any other domain name. If we could publish a rule which limits alignment to only work from an authenticated domain name downward to a child subdomain, we would have a secure design, because we would not need to worry about leaving the authenticated organization. But as long as upward alignment is necessitated by current practice, we need to be concerned about leaving the authenticated organization in the upward direction into the PSL. A specific example: MailFrom is "spam...@example.com" and From is "trustme@com". Any acceptable replacement for the PSL must ensure that this identifier configuration is rejected. When moving up the domain tree, the only way to avoid transiting from an authenticated organization into the PSL, is to know what names are in the PSL.The alternatives seem to be (a) an externally obtained list, no matter how imperfect, or (b) DNS entries, no matter how imperfect.The list seems the best option in the near term, but the DNS option might prove valuable over time. Doug ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
To my mind, it is crazy talk to assert that DMARC is not an authentication method. My bank's phone app gives me the option of authenticating with either a username+password or a fingerprint. For remote access to work computers, I use two authentication methods together. Using two component methods to accomplish an authentication process does not cause it to be something other than an authentication process. Specific to DMARC: The sender's policy suggestion is probably the least important part of DMARC v1.The evidence given to this forum says that most senders do not have a DMARC policy. Of those that do, the policy is most often NONE, and therefore useless. Of all the mail that is blocked by automation because of p=(reject | quarantine), a significant portion is blocked for reasons that the recipient user considers incorrect.So the proportion of mail which is properly blocked because of a DMARC policy looks rather tiny. Nonetheless, about 85% of my incoming messages have FROM addresses that I classify as "reliably identified". This is mostly because of DMARC PASS, but I also use some local policies serve as alternatives to DMARC PASS. I don't need a DMARC policy to produce DMARC PASS or FAIL. A sender's policy expression is only meaningful because DMARC invented an algorithm for authenticating the FROM address, something that had never been done before. Without an algorithm to generate PASS or FAIL, there is nothing about which a sender can make a disposition suggestion. Doug Foster On Sun, Oct 31, 2021 at 1:50 PM Dotzero wrote: > > > On Sun, Oct 31, 2021 at 1:03 PM Scott Kitterman > wrote: > >> Perhaps it's a pointless semantic distinction. I think of DMARC as a >> mechanism for expressing policy about authentication, not an authentication >> method. >> >> I still don't understand what you think is unprotected. >> >> Scott K >> > > +1 > > DMARC allows the owners or administrators of a domain to express a policy > for email messages which fail to pass aligned DKIM or SPF and request > validators/receivers to act on that policy. In and of itself DMARC is not > an authentication method. > > Michael Hammer > ___ > 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] Topic for IETF 112 - Policy Discovery
On Sun, Oct 31, 2021 at 1:03 PM Scott Kitterman wrote: > Perhaps it's a pointless semantic distinction. I think of DMARC as a > mechanism for expressing policy about authentication, not an authentication > method. > > I still don't understand what you think is unprotected. > > Scott K > +1 DMARC allows the owners or administrators of a domain to express a policy for email messages which fail to pass aligned DKIM or SPF and request validators/receivers to act on that policy. In and of itself DMARC is not an authentication method. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
Perhaps it's a pointless semantic distinction. I think of DMARC as a mechanism for expressing policy about authentication, not an authentication method. I still don't understand what you think is unprotected. Scott K On October 31, 2021 4:48:10 PM UTC, Douglas Foster wrote: >DMARC is an authentication test also. The authentication of the first >identifier (SPF or DKIM) serves as a proxy to authenticate the second >identifer (FROM), which is conditioned on a satisfactory relationship >(equal or aligned) between the two domains. > >You began to address the issue in your recent post, which included this: > >I think that if we changed the relaxed definition to the same as or a >sub-domain of the From domain it would avoid potential issues like that >without practical impact. I don't think I have ever seen legitimate mail >where Mail From or DKIM signing domain wasn't either the same or a >sub-domain of From that were in the same org domain. > > >You still need a way to protect the PSL names themselves, and this >paragraph does not do so. > >Exact match to the authenticated domain is always sufficient to >authenticate the FROM domain. > >>From a trust standpoint, the greatest trust occurs when the authenticated >identifier (SPF or DKIM) is the parent of the second identifier (FROM). >Based on my observed data, I agree that the norm is for FROM to be the >parent or the equal, rarely the child. I should be able to provide some >data. I will not have data about cousin relationships (unit1.example.com >aligned with unit2.example.com). > >Doug > >On Sun, Oct 31, 2021 at 11:30 AM Scott Kitterman >wrote: > >> Neither SPF nor DKIM use the PSL, so I still don't understand. What do >> you mean by "authentication testing"? >> >> Scott K >> >> ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
DMARC is an authentication test also. The authentication of the first identifier (SPF or DKIM) serves as a proxy to authenticate the second identifer (FROM), which is conditioned on a satisfactory relationship (equal or aligned) between the two domains. You began to address the issue in your recent post, which included this: I think that if we changed the relaxed definition to the same as or a sub-domain of the From domain it would avoid potential issues like that without practical impact. I don't think I have ever seen legitimate mail where Mail From or DKIM signing domain wasn't either the same or a sub-domain of From that were in the same org domain. You still need a way to protect the PSL names themselves, and this paragraph does not do so. Exact match to the authenticated domain is always sufficient to authenticate the FROM domain. >From a trust standpoint, the greatest trust occurs when the authenticated identifier (SPF or DKIM) is the parent of the second identifier (FROM). Based on my observed data, I agree that the norm is for FROM to be the parent or the equal, rarely the child. I should be able to provide some data. I will not have data about cousin relationships (unit1.example.com aligned with unit2.example.com). Doug On Sun, Oct 31, 2021 at 11:30 AM Scott Kitterman wrote: > Neither SPF nor DKIM use the PSL, so I still don't understand. What do > you mean by "authentication testing"? > > Scott K > > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
Neither SPF nor DKIM use the PSL, so I still don't understand. What do you mean by "authentication testing"? Scott K On October 31, 2021 11:30:29 AM UTC, Douglas Foster wrote: >We have two issues floating here: >1) For policy lookup, replace the PSL with a constrained tree walk. >2) For authentication testing, replace the PSL with something based on the >policy lookup. > >Currently, the DMARC policy has nothing to do with the authentication >test. > >If the second idea is still on the table, we need a definition and a >defense of the algorithm. If the suggestion is withdrawn, please say so. > >Doug Foster > >On Sat, Oct 30, 2021 at 3:56 PM Scott Kitterman >wrote: > >> >> >> On October 30, 2021 6:20:19 PM UTC, Alessandro Vesely >> wrote: >> >On Fri 29/Oct/2021 23:29:13 +0200 Scott Kitterman wrote: >> >> On Tuesday, October 26, 2021 10:09:13 PM EDT John Levine wrote: >> >>> It appears that Scott Kitterman said: >> >> Until we understand what we want, overall, selecting a specific >> design to >> achieve that goal is premature. Both of those approaches will give a >> wrong answer (at least as I'd define it) for less usual cases. >> >>> >> >>> Yup. I think I was the first person to propose a tree-walk, so here is >> >>> roughly what I was thinking: >> >>> >> >>> The problem with organizational domain is that it is ill-defined. It >> waves >> >>> its hands and says to use something like the PSL, and in practice >> everyone >> >>> uses the PSL. >> > >> > >> >That usage has proven to work quite well. And some respect for the >> installed >> >base wouldn't hurt. >> >> The alternative I suggested is 100% compatible with the installed base. >> If a domain has published DMARC policy per RFC 7489, the proposed new >> approach will still find it. I agree that something which would require >> existing DMARC records to be changed would be a non-starter. >> >> I'm not sure how much more respectful we can manage to be. >> >> Scott K >> >> ___ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery -- PSL Replacement using DNS Flags
On Sat 30/Oct/2021 05:15:14 +0200 Scott Kitterman wrote: On October 30, 2021 1:58:00 AM UTC, Douglas Foster wrote: I enthusiastically endorse John's proposal for policy discovery. PSL replacement using DNS Flags This proposal specifies a resource record that can be used to distinguish between PSL names and organization-controlled names. The design also permits fine-tuning of organization-controlled names to obstruct misuse of those names. [...] IMHO, that design has the same flaw of SPF, of requiring an organization to define RRs for almost every host. DMARC overcame that hurdle using the PSL. None of that is needed for DMARC. Still, it could be possible to specify policy discovery so that if one day something like Doug's idea, or like Dbound, were going to be available, even partially, then it could be applicable without requiring a new spec. As long as there's semantic equivalence, that is. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
We have two issues floating here: 1) For policy lookup, replace the PSL with a constrained tree walk. 2) For authentication testing, replace the PSL with something based on the policy lookup. Currently, the DMARC policy has nothing to do with the authentication test. If the second idea is still on the table, we need a definition and a defense of the algorithm. If the suggestion is withdrawn, please say so. Doug Foster On Sat, Oct 30, 2021 at 3:56 PM Scott Kitterman wrote: > > > On October 30, 2021 6:20:19 PM UTC, Alessandro Vesely > wrote: > >On Fri 29/Oct/2021 23:29:13 +0200 Scott Kitterman wrote: > >> On Tuesday, October 26, 2021 10:09:13 PM EDT John Levine wrote: > >>> It appears that Scott Kitterman said: > > Until we understand what we want, overall, selecting a specific > design to > achieve that goal is premature. Both of those approaches will give a > wrong answer (at least as I'd define it) for less usual cases. > >>> > >>> Yup. I think I was the first person to propose a tree-walk, so here is > >>> roughly what I was thinking: > >>> > >>> The problem with organizational domain is that it is ill-defined. It > waves > >>> its hands and says to use something like the PSL, and in practice > everyone > >>> uses the PSL. > > > > > >That usage has proven to work quite well. And some respect for the > installed > >base wouldn't hurt. > > The alternative I suggested is 100% compatible with the installed base. > If a domain has published DMARC policy per RFC 7489, the proposed new > approach will still find it. I agree that something which would require > existing DMARC records to be changed would be a non-starter. > > I'm not sure how much more respectful we can manage to be. > > Scott K > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On October 30, 2021 6:20:19 PM UTC, Alessandro Vesely wrote: >On Fri 29/Oct/2021 23:29:13 +0200 Scott Kitterman wrote: >> On Tuesday, October 26, 2021 10:09:13 PM EDT John Levine wrote: >>> It appears that Scott Kitterman said: Until we understand what we want, overall, selecting a specific design to achieve that goal is premature. Both of those approaches will give a wrong answer (at least as I'd define it) for less usual cases. >>> >>> Yup. I think I was the first person to propose a tree-walk, so here is >>> roughly what I was thinking: >>> >>> The problem with organizational domain is that it is ill-defined. It waves >>> its hands and says to use something like the PSL, and in practice everyone >>> uses the PSL. > > >That usage has proven to work quite well. And some respect for the installed >base wouldn't hurt. The alternative I suggested is 100% compatible with the installed base. If a domain has published DMARC policy per RFC 7489, the proposed new approach will still find it. I agree that something which would require existing DMARC records to be changed would be a non-starter. I'm not sure how much more respectful we can manage to be. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On Fri 29/Oct/2021 23:29:13 +0200 Scott Kitterman wrote: On Tuesday, October 26, 2021 10:09:13 PM EDT John Levine wrote: It appears that Scott Kitterman said: Until we understand what we want, overall, selecting a specific design to achieve that goal is premature. Both of those approaches will give a wrong answer (at least as I'd define it) for less usual cases. Yup. I think I was the first person to propose a tree-walk, so here is roughly what I was thinking: The problem with organizational domain is that it is ill-defined. It waves its hands and says to use something like the PSL, and in practice everyone uses the PSL. That usage has proven to work quite well. And some respect for the installed base wouldn't hurt. But the PSL is a moving target, with entries added and deleted on a regular basis, so this month's organization domain may not be the same as last month's. The advantage of the tree walk is that the DMARC result now depends entirely on what is in the DNS, not on a volunteer maintained list whose volunteers keep reminding us that it's only intended to manage http cookies. The whole DNS is a moving target. Todd's stats confirm my intuition that the DNS is pretty flat, and the amount of mail that comes from addreses with more than, say, four labels is miniscule. So if you do a four level tree walk, you will find all of the DMARC records for all of the real mail. The question remains what to do about the fake mail with 12 label domains. My perhaps radical suggestion is to say that if the author domain does not exist, i.e., you look it up and get NXDOMAIN, then DMARC does not apply and you do whatever you do to mail with fake addresses. Or perhaps you only say that if it's NXDOMAIN and has more than four labels. That way if you really want to use 12 label addresses, you have to add a _dmarc record every four levels. Nobody will do that, but nobody sends mail like that other than to be perverse, so it doesn't matter. Based on the longest true PSL entry being 4 labels, we could also just jump to the 5th and walk up from there. It would give every domain that currently has the ability to express a domain policy the ability to do so and bound the total number of lookups you could get stuck with for the perverse case. Something like the attached. That sounds much like the poor man's do-it-yourself PSL. This shows the change from the current 6.6.3. It's largely a merge of text from the current 3.2 and 6.6.3 adjusted for the proposal. All of 3.2 and any reference to organizational domain would also be removed. I disagree. The concept of Organizational Domain has been a winning point of DMARC. We should keep it. Instead of the pragmatic definition given in Section 3.2 of RFC 7489, we can say something like the current Section 3.9, but turning the reference to Section 3.15 into an example rather than a normative algorithm. The spec should recall that the DNS is a hierarchy so that an affiliation between the parent zone and the delegated domain can be assumed, unless the parent is a public registry or similar entity. Situations like .BANK and .GOV.UK can be mentioned. A definition of Organizational Domain given in such abstract terms is semantically solid and makes for a good conceptual guidance. Suggestions about how to deal with corner cases like >5 labels or TLDs can be given. According to the above discussion, a programmer cannot code a behavior outside of the rules, irrespective of her decision to use (part of) the PSL or any other configuration file to assist tree walking. Configuration files avoid to hard code stuff like that ">5". Users can adjust those files instead of waiting for new software releases. And the PSL is just a kind of configuration file, albeit complex. It assists in walking up the tree at more than one label at a time. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On October 30, 2021 3:10:13 AM UTC, Dave Crocker wrote: >On 10/29/2021 7:56 PM, John Levine wrote: >> I asked for some examples of bad things that the PSL would prevent or fix. >> Don’t think we’ve seen any. > > >1. I've reviewed what I believe are all of your relevant postings on >this thread and managed to miss where you asked that. Please point to >the message. > >2. Though I admit it's a bit difficult to discern exactly what your >concern is, I read the motivating text as encouraging the development of >a thoughtful privacy and security considerations section. Oddly, you >appear to have objected to that point. Can't guess as to why. I didn't think he was objecting, I thought he was specifying the target audience. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery -- PSL Replacement using DNS Flags
On October 30, 2021 1:58:00 AM UTC, Douglas Foster wrote: >I enthusiastically endorse John's proposal for policy discovery. But as >stated previously, I do not see that it provides a viable mechanism for >eliminating the PSL as an alignment tool. To address that part of the >problem, I submit my proposal for migrating from the publicsuffix.org list >to DNS flags. > >Doug Foster > >PSL replacement using DNS Flags > >This proposal specifies a resource record that can be used to distinguish >between PSL names and organization-controlled names. The design also >permits fine-tuning of organization-controlled names to obstruct misuse of >those names. > >When this mechanism is available, it provides sufficient information to the >evaluator so that the Public Suffix List from publicsuffix.org does not >need to be checked. In the future, if participation becomes sufficiently >widespread, evaluators may choose to bypass the publicsuffix.org list >completely. >Resource Record Definition (type=TXT) > >All interpretations apply to the Resource Record’s DNS name. No cascading >of information is used. > >Label:DMARCFLAGS > >Version tag v=1 > >Tokens: > >· SMTPFROM=FALSE >Name is never used for SMTP MailFrom addresses. Stronger repudiation than >SPF FAIL. Equivalent to “SPF -ALL”, primarily included here for simplified >PSL configuration. Applicable if no SPF policy exists. If an SPF policy >exists, the policy takes precedence. When omitted, the default >interpretation is TRUE, the name may be used for SMTP MailFrom. > >· MSGFROM=(TRUE | FALSE ) >When this token is not used, the default depends on SPF. If SPF is “-ALL” >or SMTPFROM=FALSE, the MSGFROM defaults to FALSE. If any other SPF record >exists, defaults to TRUE. If no SPF record exists, default is UNKNOWN. > >o MSGFROM=FALSE >Name is never used for message FROM header address. Stronger repudiation >than DMARC FAIL. > >o MSGFROM=TRUE >Name may be used for message FROM header address. Primarily used to >ensure that From non-existence tests recognize that the name exists and is >valid for Email FROM addresses. > >· DKIM=FALSE >Stronger than DKIM verification failure. If name cannot be verified >because a public key is not found in DNS, treat the signature as a fake. >When not present, TRUE is assumed. > >· ALIGN=FALSE >Name is not usable for alignment of non-matching domain names. Primarily >used to indicate a PSL entry. When not present, TRUE is presumed. >Specifying ALIGN=FALSE implies that all parent domains are also >characterized by ALIGN=FALSE. To avoid inconsistent results, it should >only be published when parent domains have also published ALIGN=FALSE. >Use Cases PSL Name > >A PSL name is not usable for mail or for alignment, so the record has these >values: > >“DMARCFLAGS v=1 SMTPFROM=FALSE MSGFFROM=FALSE DKIM=FALSE ALIGN=FALSE” >Organization-owned Mail Server > >An organization-owned mail-sending server uses its own domain for both the >SMTP MailFrom and the message From header, and is also likely to use the >domain name to sign messages. So all defaults are applicable and the >MSGFROM clause is optional as long as an SPF record is present. To be >explicit, this record would be used. > >“DMARCFLAGS v=1 MSGFROM=TRUE” >Organization subdomain used only for Mailing Service messages > >Mailing services typical use one of their own subdomains for the SMTP >MailFrom address, to ensure SPF PASS. The client organization chooses the >message From address from the domain tree that it controls. If a From >address subdomain name is only used in this context, it may have no other >existence in DNS, without this clause, it might be considered >non-existent. This record documents the use of the name for the message >FROM header while repudiating its use for SMTP MailFrom. > >“DMARCFLAGS v=1 SMTPFROM=FALSE MSGFROM=TRUE” >Mailing service SMTP names used for client messages > >Mailing services typically use their own subdomain names for the SMTP >MailFrom address, to ensure SPF PASS. These subdomain names are typically >used only in this context, never for sending the service provider’s own >mail. The subdomain may or may not be used for DKIM signatures, so these >records are possible. > >“DMARCFLAGS v=1 MSGFROM=FALSE” >or >“DMARCFLAGS v=1 MSGFROM=FALSE DKIM=FALSE” >Holding Company with Isolation between Subsidiaries > >This is an unlikely situation, but is supported by the design. Assume that >Example.Com is a large conglomerate with subsidiaries involved in >activities as wide-ranging as oil exploration and home repair. >Example.Com does not want to allow subsidiaries to send on each other’s >behalf, so it does not want the corporate parent domain to be used for >alignment. Corporate messages will be sent using exact-match alignment, >while subsidiary companies will use normal alignment up to the subsidiary’s >parent domain. This record documents the holding company
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On 10/29/2021 7:56 PM, John Levine wrote: I asked for some examples of bad things that the PSL would prevent or fix. Don’t think we’ve seen any. 1. I've reviewed what I believe are all of your relevant postings on this thread and managed to miss where you asked that. Please point to the message. 2. Though I admit it's a bit difficult to discern exactly what your concern is, I read the motivating text as encouraging the development of a thoughtful privacy and security considerations section. Oddly, you appear to have objected to that point. Can't guess as to why. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
I asked for some examples of bad things that the PSL would prevent or fix. Don’t think we’ve seen any. Please consider the environment before reading this message. John Levine, jo...@taugh.com > On Oct 29, 2021, at 22:08, Dave Crocker wrote: > > On 10/29/2021 6:40 PM, John Levine wrote: >> It appears that Dave Crocker said: >>> Except that Alessandro's original reference was in the service of >>> explaining why a mechanism DMARC relies on, for establishing >>> organization authority, should not necessarily rely on everyone's being >>> a good actor. >> I take it you are agreeing that we should stop using the PSL. > > > Since I never said or implied anything of the sort, it's odd you would choose > to again introduce such a distraction, given the exercise we've just gone > through. Please stop. > > >> It's just >> a bunch of thinly funded volunteers and a github repo. Who knows what >> they might decide to do tomorrow? > > You mean, like the DNS root operators? > > But, again, this is, at best, only tenuously relevant to the original point. > > I will bet that, with some effort, you could find a way to make a relevant > response to Alessandro's original point. Please feel encouraged to try. > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On 10/29/2021 6:40 PM, John Levine wrote: It appears that Dave Crocker said: Except that Alessandro's original reference was in the service of explaining why a mechanism DMARC relies on, for establishing organization authority, should not necessarily rely on everyone's being a good actor. I take it you are agreeing that we should stop using the PSL. Since I never said or implied anything of the sort, it's odd you would choose to again introduce such a distraction, given the exercise we've just gone through. Please stop. It's just a bunch of thinly funded volunteers and a github repo. Who knows what they might decide to do tomorrow? You mean, like the DNS root operators? But, again, this is, at best, only tenuously relevant to the original point. I will bet that, with some effort, you could find a way to make a relevant response to Alessandro's original point. Please feel encouraged to try. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery -- PSL Replacement using DNS Flags
I enthusiastically endorse John's proposal for policy discovery. But as stated previously, I do not see that it provides a viable mechanism for eliminating the PSL as an alignment tool. To address that part of the problem, I submit my proposal for migrating from the publicsuffix.org list to DNS flags. Doug Foster PSL replacement using DNS Flags This proposal specifies a resource record that can be used to distinguish between PSL names and organization-controlled names. The design also permits fine-tuning of organization-controlled names to obstruct misuse of those names. When this mechanism is available, it provides sufficient information to the evaluator so that the Public Suffix List from publicsuffix.org does not need to be checked. In the future, if participation becomes sufficiently widespread, evaluators may choose to bypass the publicsuffix.org list completely. Resource Record Definition (type=TXT) All interpretations apply to the Resource Record’s DNS name. No cascading of information is used. Label:DMARCFLAGS Version tag v=1 Tokens: · SMTPFROM=FALSE Name is never used for SMTP MailFrom addresses. Stronger repudiation than SPF FAIL. Equivalent to “SPF -ALL”, primarily included here for simplified PSL configuration. Applicable if no SPF policy exists. If an SPF policy exists, the policy takes precedence. When omitted, the default interpretation is TRUE, the name may be used for SMTP MailFrom. · MSGFROM=(TRUE | FALSE ) When this token is not used, the default depends on SPF. If SPF is “-ALL” or SMTPFROM=FALSE, the MSGFROM defaults to FALSE. If any other SPF record exists, defaults to TRUE. If no SPF record exists, default is UNKNOWN. o MSGFROM=FALSE Name is never used for message FROM header address. Stronger repudiation than DMARC FAIL. o MSGFROM=TRUE Name may be used for message FROM header address. Primarily used to ensure that From non-existence tests recognize that the name exists and is valid for Email FROM addresses. · DKIM=FALSE Stronger than DKIM verification failure. If name cannot be verified because a public key is not found in DNS, treat the signature as a fake. When not present, TRUE is assumed. · ALIGN=FALSE Name is not usable for alignment of non-matching domain names. Primarily used to indicate a PSL entry. When not present, TRUE is presumed. Specifying ALIGN=FALSE implies that all parent domains are also characterized by ALIGN=FALSE. To avoid inconsistent results, it should only be published when parent domains have also published ALIGN=FALSE. Use Cases PSL Name A PSL name is not usable for mail or for alignment, so the record has these values: “DMARCFLAGS v=1 SMTPFROM=FALSE MSGFFROM=FALSE DKIM=FALSE ALIGN=FALSE” Organization-owned Mail Server An organization-owned mail-sending server uses its own domain for both the SMTP MailFrom and the message From header, and is also likely to use the domain name to sign messages. So all defaults are applicable and the MSGFROM clause is optional as long as an SPF record is present. To be explicit, this record would be used. “DMARCFLAGS v=1 MSGFROM=TRUE” Organization subdomain used only for Mailing Service messages Mailing services typical use one of their own subdomains for the SMTP MailFrom address, to ensure SPF PASS. The client organization chooses the message From address from the domain tree that it controls. If a From address subdomain name is only used in this context, it may have no other existence in DNS, without this clause, it might be considered non-existent. This record documents the use of the name for the message FROM header while repudiating its use for SMTP MailFrom. “DMARCFLAGS v=1 SMTPFROM=FALSE MSGFROM=TRUE” Mailing service SMTP names used for client messages Mailing services typically use their own subdomain names for the SMTP MailFrom address, to ensure SPF PASS. These subdomain names are typically used only in this context, never for sending the service provider’s own mail. The subdomain may or may not be used for DKIM signatures, so these records are possible. “DMARCFLAGS v=1 MSGFROM=FALSE” or “DMARCFLAGS v=1 MSGFROM=FALSE DKIM=FALSE” Holding Company with Isolation between Subsidiaries This is an unlikely situation, but is supported by the design. Assume that Example.Com is a large conglomerate with subsidiaries involved in activities as wide-ranging as oil exploration and home repair. Example.Com does not want to allow subsidiaries to send on each other’s behalf, so it does not want the corporate parent domain to be used for alignment. Corporate messages will be sent using exact-match alignment, while subsidiary companies will use normal alignment up to the subsidiary’s parent domain. This record documents the holding company policy: “DMARCFLAGS v=1 ALIGN=FALSE” Domain or Subdomain which is never used for sending email If a name is not used for either SMTP MailFrom or message FROM header, then
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
It appears that Dave Crocker said: >Except that Alessandro's original reference was in the service of >explaining why a mechanism DMARC relies on, for establishing >organization authority, should not necessarily rely on everyone's being >a good actor. I take it you are agreeing that we should stop using the PSL. It's just a bunch of thinly funded volunteers and a github repo. Who knows what they might decide to do tomorrow? Unlike the other parties we've been discussing, they have no contracts and no consequences if they decide to close up shop or do something strange and unexpected that we might not like. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On 10/29/2021 6:06 PM, John R Levine wrote: an you explain what this line of argument has to do with DMARC? I'm drawing a blank. If it's that any TLD operator might at any time do something horrible, even though they never have before, it seems to me that the only reasonable option is to abandon the DNS. Sorry you lost the thread. To review: Alessandro expressed concern about a particular company's demonstrated predilection for what was classed as abuse. You attempted to dismiss his concern with an irrelevant point about the particulars of the specific abuse he cited. I pointed out that you'd missed the point that he cited as issue with corporate culture. You again attempted to dismiss the point by claiming it was a single event, long ago. I point out that there was a pattern of behavior and concern about them. You are now claiming that all this is irrelevant to the current topic. Except that Alessandro's original reference was in the service of explaining why a mechanism DMARC relies on, for establishing organization authority, should not necessarily rely on everyone's being a good actor. A point that is entirely relevant and would have been easier to focus on, had you not chosen to distract from it. 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] Topic for IETF 112 - Policy Discovery
On Fri, 29 Oct 2021, Dave Crocker wrote: Every gTLD operator has a web of contracts with ICANN, and Verisign also with the US government, which severely constrain what they can do with their TLDs. Yes, yes. All of them are well-behaved, following all the rules, and the rules perfectly protect against misbehaviors, which they'd never think of finding a way around. Can you explain what this line of argument has to do with DMARC? I'm drawing a blank. If it's that any TLD operator might at any time do something horrible, even though they never have before, it seems to me that the only reasonable option is to abandon the DNS. 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] Topic for IETF 112 - Policy Discovery
It appears that Scott Kitterman said: >Based on the longest true PSL entry being 4 labels, we could also just jump to >the 5th and walk up from there. It would give every domain that currently has >the ability to express a domain policy the ability to do so and bound the >total number of lookups you could get stuck with for the perverse case. That's not a bad idea, deals with the real cases without a lot of wheel spinning for the silly ones. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On 10/29/2021 5:02 PM, John R Levine wrote: Oh, please. That was the sitefinder fiasco which led to lawsuits and convulsions at ICANN, and considerable contract revision. Nothing like that will happen again for reasons I can explain privately for anyone who cares. Except that repetition of the same action is not what was being suggested. Rather, a matter of corporate culture was. That was one event eighteen years ago. Since they haven't done anything else like that since then, perhaps they learned a lesson. When Jon Postel had half the root servers change where they took the master data from, it was not as a demonstration of his power, independent of the US government, as is often claimed. The same folk in question here ran that master DNS root and were threatening to go rogue and Jon wanted to make sure it would be possible to marginalize the damage if they did. cf, my above reference to corporate culture. A variant of trust-but-verify is trust-but-prevent. Every gTLD operator has a web of contracts with ICANN, and Verisign also with the US government, which severely constrain what they can do with their TLDs. Yes, yes. All of them are well-behaved, following all the rules, and the rules perfectly protect against misbehaviors, which they'd never think of finding a way around. 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] Topic for IETF 112 - Policy Discovery
Oh, please. That was the sitefinder fiasco which led to lawsuits and convulsions at ICANN, and considerable contract revision. Nothing like that will happen again for reasons I can explain privately for anyone who cares. Except that repetition of the same action is not what was being suggested. Rather, a matter of corporate culture was. That was one event eighteen years ago. Since they haven't done anything else like that since then, perhaps they learned a lesson. Every gTLD operator has a web of contracts with ICANN, and Verisign also with the US government, which severely constrain what they can do with their TLDs. If someone believes that Verisign or any other TLD operator might do something bad, and that using the PSL would fix the badness, we really need details about what the bad thing might be and what the fix would be. I am probably as involved with ICANN and TLD operators than anyone else here and I just don't see it. I'm not saying any of the operators are paragons of sweetness and light, but I am saying I do not see anything they could do that would affect the way DMARC works. 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] Topic for IETF 112 - Policy Discovery
On 10/29/2021 10:31 AM, John Levine wrote: Oh, please. That was the sitefinder fiasco which led to lawsuits and convulsions at ICANN, and considerable contract revision. Nothing like that will happen again for reasons I can explain privately for anyone who cares. Except that repetition of the same action is not what was being suggested. Rather, a matter of corporate culture was. I'm not commenting on the company, but do suggest that it helps more to respond to a point being made than to a point not being made. 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] Topic for IETF 112 - Policy Discovery
On Tuesday, October 26, 2021 10:09:13 PM EDT John Levine wrote: > It appears that Scott Kitterman said: > >For a 'normal' domain/sub-domain like eml.example.com where the domain has > >a DMARC policy, every single implementation approach gives the same > >answer, so it doesn't matter. The challenge is getting all the other > >cases right. > > > >Until we understand what we want, overall, selecting a specific design to > >achieve that goal is premature. Both of those approaches will give a > >wrong answer (at least as I'd define it) for less usual cases. > Yup. I think I was the first person to propose a tree-walk, so here is > roughly what I was thinking: > > The problem with organizational domain is that it is ill-defined. It waves > its hands and says to use something like the PSL, and in practice everyone > uses the PSL. But the PSL is a moving target, with entries added and > deleted on a regular basis, so this month's organization domain may not be > the same as last month's. The advantage of the tree walk is that the DMARC > result now depends entirely on what is in the DNS, not on a volunteer > maintained list whose volunteers keep reminding us that it's only intended > to manage http cookies. > > Todd's stats confirm my intuition that the DNS is pretty flat, and the > amount of mail that comes from addreses with more than, say, four labels is > miniscule. So if you do a four level tree walk, you will find all of the > DMARC records for all of the real mail. > > The question remains what to do about the fake mail with 12 label domains. > My perhaps radical suggestion is to say that if the author domain does not > exist, i.e., you look it up and get NXDOMAIN, then DMARC does not apply and > you do whatever you do to mail with fake addresses. Or perhaps you only > say that if it's NXDOMAIN and has more than four labels. That way if you > really want to use 12 label addresses, you have to add a _dmarc record > every four levels. Nobody will do that, but nobody sends mail like that > other than to be perverse, so it doesn't matter. Based on the longest true PSL entry being 4 labels, we could also just jump to the 5th and walk up from there. It would give every domain that currently has the ability to express a domain policy the ability to do so and bound the total number of lookups you could get stuck with for the perverse case. Something like the attached. This shows the change from the current 6.6.3. It's largely a merge of text from the current 3.2 and 6.6.3 adjusted for the proposal. All of 3.2 and any reference to organizational domain would also be removed. Scott K policy_discovery_no_psl-from-7489.diff.html Description: application/xhtml ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
It appears that Alessandro Vesely said: >Verisign is not new to abusive behavior. About 20 years ago they used to >reply >with one of their servers' IP addresses to any query like >www..com. ISC came out with the "root-delegation-only" hack >to counter that. Oh, please. That was the sitefinder fiasco which led to lawsuits and convulsions at ICANN, and considerable contract revision. Nothing like that will happen again for reasons I can explain privately for anyone who cares. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On Fri 29/Oct/2021 03:15:10 +0200 Scott Kitterman wrote: On October 29, 2021 12:58:12 AM UTC, John Levine wrote: It appears that Scott Kitterman said: The key is to get the security and privacy considerations documented so that ICANN and ccTLD operators are informed and can set their own rules appropriate. >> I would be pretty surprised if ICANN had any interest in this other than using their existing RSTEP process if some TLDs want to publish _dmarc.. Yes, and ccTLD operators for whatever processes they use. Verisign is not new to abusive behavior. About 20 years ago they used to reply with one of their servers' IP addresses to any query like www..com. ISC came out with the "root-delegation-only" hack to counter that. IMHO, we shouldn't throw away the PSL. Most importantly, we should stick to the concept of Organizational Domain. We can give an abstract definition of the latter in terms of affiliation of some kind. Then the spec can leave it to developers to decide how to find it: tree-walk, PSL, dbound or whatever thing like it will eventually come about, or even a mix of those. That way, code using the PSL wouldn't be obsoleted. For new code, some configuration stuff to skip useless queries to _dmarc.com would be useful anyway. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
PSL entries are imputed with four important characteristics: - name not valid for MAILFROM - name not valid for FROM - name not valid for DKIM - name not valid as an alignment point for mismatched names. For non-PSL names, the reverse is assumed by default - any name is valid for any of these purposes. It is important to note that the PSL covers all possible names -- if a name prefix is not in the PSL, we assume it is a fake name.Experience also indicates that it is trusted as accurate. We have not spent any time talking about a need for PSL override rules. Finding the first available DMARC policy, as John suggests, does not come close to replacing the PSL. - First, DMARC policies do not cover all possible names, which is a rather critical problem. - Secondly, even when they are present, the first-match DMARC policy does not define all valid alignment points. Consider unit2.example.com and unit1.example.com. Each unit may have its own DMARC policy, but the parent domain may still be a valid alignment point. I can test alignment without a DMARC policy, but I cannot test alignment without a PSL or a comparable replacement. We could define DNS flags to cover the four PSL characteristics listed above, and those flags have potential use cases outside of the PSL But we have already concluded that we cannot reliably expect every PSL to configure DNS entries to meet our needs, so the DNS-based PSL would lack the necessary trust that we have in the current PSL. Doug On Wed, Oct 27, 2021 at 3:29 PM John Levine wrote: > It appears that Scott Kitterman said: > >On Tuesday, October 26, 2021 10:09:13 PM EDT John Levine wrote: > >> The question remains what to do about the fake mail with 12 label > domains. > >> My perhaps radical suggestion is to say that if the author domain does > not > >> exist, i.e., you look it up and get NXDOMAIN, then DMARC does not apply > and > >> you do whatever you do to mail with fake addresses. Or perhaps you only > >> say that if it's NXDOMAIN and has more than four labels. That way if > you > >> really want to use 12 label addresses, you have to add a _dmarc record > >> every four levels. Nobody will do that, but nobody sends mail like that > >> other than to be perverse, so it doesn't matter. > > > >Thanks. From the bottom up, I think that seems reasonable, but my > concern > >(not surprisingly) is on the other end of the question. Should a policy > found > >at _dmarc.com be treated differently than _dmarc.example.com? If so, > then what > >about _dmarc.gov.uk versus _example.gov.uk and how do we distinguish > between > >the first set and the second? > > Since we are writing a technical spec, the only answer is that we don't. > The PSL, or anything like the PSL, is only someone's guess about > relationships > between various DNS subtrees. > > Let us not rehash the theological argument about who controls the DNS tree, > the technical faction saying that each zone controls all of its > descendants, > and the political faction saying we have rules about that not visible in > the DNS. One the one hand, zones like .BANK have real contracts that they > want to enforce, but on the other hand, we have overclever hosting > providers > who imagine that the PSL is a get out of jail card for dealing with sleazy > customers, and the PSL maintainers are not happy: > > https://github.com/publicsuffix/list/wiki/Third-Party-Diffusion > > I would say that if you have an issue with a DMARC record in the > tree above your domain, that's a business issue with whoever > controls that record, not a technical one. > > R's, > John > > ___ > 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] Topic for IETF 112 - Policy Discovery
On October 29, 2021 12:58:12 AM UTC, John Levine wrote: >It appears that Scott Kitterman said: >>It's growing on me. > >Ooh, cool. > >>There are, however privacy and security concern differences between >>processing >>a record for _dmarc.example.com and _dmarc.com. We can, and should explain >>those differences in the security and privacy considerations sections of the >>eventual DMARC RFC, but if com should publish a DMARC policy is really >>between >>the operator of com and ICANN and if ICANN were to allow it, it would be up >>to >>com domain registrants to decide how to deal with it (to be clear, I think it >> >>would be horrible if that happened, but that's not a technical, >>interoperability horror, it's about privacy and security). > >Right - it's not a problem with a technical solution. > >I know several of the people who run the PSL and while they try very >hard to do a good job, they are just volunteers and have no unique insight >into DNS policy truth. There are a few places where they have specifically >decided to punt, like not including the 15,000 2LDs in .name under which they >sell 3LDs. > >>Technically, the change is: >> >>Lookup policy and if not found, lookup up the next level (up to 4) instead of >>lookup policy and if not found, consult PSL and lookup the org domain. >> >>For the common case like eml.example.com where there is no DMARC record the >>trade is one extra DNS lookup in exchange for getting the PSL out of the >>equation. > >Sounds right. > >>Assuming I have that right, I think that is a reasonable path forward that >>would solve a number of problems. The key is to get the security and privacy >>considerations documented so that ICANN and ccTLD operators are informed and >>can set their own rules appropriate. > >I would be pretty surprised if ICANN had any interest in this other than using >their existing RSTEP process if some TLDs want to publish _dmarc.. Yes, and ccTLD operators for whatever processes they use. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
It appears that Scott Kitterman said: >It's growing on me. Ooh, cool. >There are, however privacy and security concern differences between processing >a record for _dmarc.example.com and _dmarc.com. We can, and should explain >those differences in the security and privacy considerations sections of the >eventual DMARC RFC, but if com should publish a DMARC policy is really between >the operator of com and ICANN and if ICANN were to allow it, it would be up to >com domain registrants to decide how to deal with it (to be clear, I think it >would be horrible if that happened, but that's not a technical, >interoperability horror, it's about privacy and security). Right - it's not a problem with a technical solution. I know several of the people who run the PSL and while they try very hard to do a good job, they are just volunteers and have no unique insight into DNS policy truth. There are a few places where they have specifically decided to punt, like not including the 15,000 2LDs in .name under which they sell 3LDs. >Technically, the change is: > >Lookup policy and if not found, lookup up the next level (up to 4) instead of >lookup policy and if not found, consult PSL and lookup the org domain. > >For the common case like eml.example.com where there is no DMARC record the >trade is one extra DNS lookup in exchange for getting the PSL out of the >equation. Sounds right. >Assuming I have that right, I think that is a reasonable path forward that >would solve a number of problems. The key is to get the security and privacy >considerations documented so that ICANN and ccTLD operators are informed and >can set their own rules appropriate. I would be pretty surprised if ICANN had any interest in this other than using their existing RSTEP process if some TLDs want to publish _dmarc.. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On Wednesday, October 27, 2021 3:28:53 PM EDT John Levine wrote: > It appears that Scott Kitterman said: > >On Tuesday, October 26, 2021 10:09:13 PM EDT John Levine wrote: > >> The question remains what to do about the fake mail with 12 label > >> domains. > >> My perhaps radical suggestion is to say that if the author domain does > >> not > >> exist, i.e., you look it up and get NXDOMAIN, then DMARC does not apply > >> and > >> you do whatever you do to mail with fake addresses. Or perhaps you only > >> say that if it's NXDOMAIN and has more than four labels. That way if you > >> really want to use 12 label addresses, you have to add a _dmarc record > >> every four levels. Nobody will do that, but nobody sends mail like that > >> other than to be perverse, so it doesn't matter. > > > >Thanks. From the bottom up, I think that seems reasonable, but my concern > >(not surprisingly) is on the other end of the question. Should a policy > >found at _dmarc.com be treated differently than _dmarc.example.com? If > >so, then what about _dmarc.gov.uk versus _example.gov.uk and how do we > >distinguish between the first set and the second? > > Since we are writing a technical spec, the only answer is that we don't. > The PSL, or anything like the PSL, is only someone's guess about > relationships between various DNS subtrees. > > Let us not rehash the theological argument about who controls the DNS tree, > the technical faction saying that each zone controls all of its descendants, > and the political faction saying we have rules about that not visible in > the DNS. One the one hand, zones like .BANK have real contracts that they > want to enforce, but on the other hand, we have overclever hosting > providers who imagine that the PSL is a get out of jail card for dealing > with sleazy customers, and the PSL maintainers are not happy: > > https://github.com/publicsuffix/list/wiki/Third-Party-Diffusion > > I would say that if you have an issue with a DMARC record in the > tree above your domain, that's a business issue with whoever > controls that record, not a technical one. I didn't like this when I first read it. Contrary to my usual practice, I didn't react immediately and sat on it to think about it instead. It's growing on me. If I understand correctly, there really isn't a technical difference between _dmarc.example.com and _dmarc.gov.uk and so from the point of view of an RFC that defines DMARC and DMARC interoperability we can't and shouldn't distinguish between them. There are, however privacy and security concern differences between processing a record for _dmarc.example.com and _dmarc.com. We can, and should explain those differences in the security and privacy considerations sections of the eventual DMARC RFC, but if com should publish a DMARC policy is really between the operator of com and ICANN and if ICANN were to allow it, it would be up to com domain registrants to decide how to deal with it (to be clear, I think it would be horrible if that happened, but that's not a technical, interoperability horror, it's about privacy and security). Technically, the change is: Lookup policy and if not found, lookup up the next level (up to 4) instead of lookup policy and if not found, consult PSL and lookup the org domain. For the common case like eml.example.com where there is no DMARC record the trade is one extra DNS lookup in exchange for getting the PSL out of the equation. Assuming I have that right, I think that is a reasonable path forward that would solve a number of problems. The key is to get the security and privacy considerations documented so that ICANN and ccTLD operators are informed and can set their own rules appropriate. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
If I understand your suggestion, then I think you lose some flexibility that way. Suppose you want to use relaxed alignment. Say you have some subdomains that you want to use p=reject for, but at the organizational level, you want p=none. _dmarc.sub.org.tld TXT "v=DMARC1;p=reject;aspf=r" _dmarc.org.tld TXT "v=DMARC1;p=none;aspf=r" You get a message with RFC5322.From domain sub.org.tld, and RFC5321.MailFrom domain other.tld. So the first record you find, at _dmarc.sub.org.tld doesn't give you enough information to judge alignment. Do you keep walking? I suppose you could jump to the longest common domain (tld in this case) and start walking again there. It's not that you lose flexibility, it's that it's different. A tree walk lets you put different policies at labels between the org domain and the leaf, while the current PSL approach doesn't. The question is whether it's different in a way that's better or worse or indifferent. Given the numbers that show how flat the DNS tree is, my guess is that it's indifferent. 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] Topic for IETF 112 - Policy Discovery
If I understand your suggestion, then I think you lose some flexibility that way. Suppose you want to use relaxed alignment. Say you have some subdomains that you want to use p=reject for, but at the organizational level, you want p=none. _dmarc.sub.org.tld TXT "v=DMARC1;p=reject;aspf=r" _dmarc.org.tld TXT "v=DMARC1;p=none;aspf=r" You get a message with RFC5322.From domain sub.org.tld, and RFC5321.MailFrom domain other.tld. So the first record you find, at _dmarc.sub.org.tld doesn't give you enough information to judge alignment. Do you keep walking? I suppose you could jump to the longest common domain (tld in this case) and start walking again there. Regards, Joe On Thu, Oct 28, 2021 at 2:47 PM John R Levine wrote: > > In your proposal, what happens if you find a record that specifies > aspf=r; > > the From header is aa.bb.cc.de.us, and the Envelope From is > ee.ff.gg.hi.us? > > How do you decide whether the common suffix .us is sufficient for relaxed > > alignment? > > Walk up from aa.bb.cc.de.us and stop when you find a _dmarc record. If > it's _dmarc.us, then ee.ff.gg.hi.us is OK for a relaxed match. If it's > below that, it isn't. > > 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] Topic for IETF 112 - Policy Discovery
In your proposal, what happens if you find a record that specifies aspf=r; the From header is aa.bb.cc.de.us, and the Envelope From is ee.ff.gg.hi.us? How do you decide whether the common suffix .us is sufficient for relaxed alignment? Walk up from aa.bb.cc.de.us and stop when you find a _dmarc record. If it's _dmarc.us, then ee.ff.gg.hi.us is OK for a relaxed match. If it's below that, it isn't. 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] Topic for IETF 112 - Policy Discovery
In your proposal, what happens if you find a record that specifies aspf=r; the From header is aa.bb.cc.de.us, and the Envelope From is ee.ff.gg.hi.us? How do you decide whether the common suffix .us is sufficient for relaxed alignment? Regards, Joe H On Thu, Oct 28, 2021 at 2:17 PM John R Levine wrote: > > Sorry, I should have made it clear that my suggestion was in the context > of > > the tree-walk proposal. Douglas Foster had pointed out that tree-walking > by > > itself doesn't eliminate the need for the PSL, because the relaxed > > alignment rules still require you to know the organizational domain. > > Doug misundersands my proposal. The tree walk is instead of the PSL. You > look up four levels in the tree and if you don't find anything, you're > done. > > 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] Topic for IETF 112 - Policy Discovery
Sorry, I should have made it clear that my suggestion was in the context of the tree-walk proposal. Douglas Foster had pointed out that tree-walking by itself doesn't eliminate the need for the PSL, because the relaxed alignment rules still require you to know the organizational domain. Doug misundersands my proposal. The tree walk is instead of the PSL. You look up four levels in the tree and if you don't find anything, you're done. 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] Topic for IETF 112 - Policy Discovery
Sorry, I should have made it clear that my suggestion was in the context of the tree-walk proposal. Douglas Foster had pointed out that tree-walking by itself doesn't eliminate the need for the PSL, because the relaxed alignment rules still require you to know the organizational domain. I believe my suggestion solves that problem, without requiring any new DNS records. Regards, Joe H On Thu, Oct 28, 2021 at 1:11 PM John Levine wrote: > It appears that Joe Humphreys said: > > > >Why not allow the DMARC record to specify what domain root the identifier > >must align with? Instead of adkim=r meaning "consult the PSL list", use > >adkim=example.com to mean "use relaxed alignment, and the organizational > >domain is example.com". > > Because first you have to figure out where to look for the DMARC record. > > If you have domains aa.bb.cc.de.us, or ee.ff.gg.hi.us, where do you > look for the org records if the domain itself doesn't have a DMARC > record? The PSL tells us that they're _dmarc..bb.cc.de.us and > _dmarc.gg.hi.us. > > R's, > John > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
It appears that Joe Humphreys said: > >Why not allow the DMARC record to specify what domain root the identifier >must align with? Instead of adkim=r meaning "consult the PSL list", use >adkim=example.com to mean "use relaxed alignment, and the organizational >domain is example.com". Because first you have to figure out where to look for the DMARC record. If you have domains aa.bb.cc.de.us, or ee.ff.gg.hi.us, where do you look for the org records if the domain itself doesn't have a DMARC record? The PSL tells us that they're _dmarc..bb.cc.de.us and _dmarc.gg.hi.us. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
Why not allow the DMARC record to specify what domain root the identifier must align with? Instead of adkim=r meaning "consult the PSL list", use adkim=example.com to mean "use relaxed alignment, and the organizational domain is example.com". On Thu, Oct 28, 2021 at 10:33 AM Barry Leiba wrote: > > The best result would be for IANA to maintain the PSL. It seems obvious > that this should be part of their job. > > Well, to be clear about what that would mean: IANA doesn't "manage" > any registries in the sense that they determine the contents. They > administer the registries under direction from the IETF and/or > designated experts. So, having IANA administer (or host) the PSL > would still mean that some designated expert or team of such would > have to tell them what changes to make when. > > The benefits we'd get from IANA would be a long-term well-known place > to find it, and a process to control the updates. But the mechanism > for making changes would be the same. > > Barry > > ___ > 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] Topic for IETF 112 - Policy Discovery
> The best result would be for IANA to maintain the PSL. It seems obvious that > this should be part of their job. Well, to be clear about what that would mean: IANA doesn't "manage" any registries in the sense that they determine the contents. They administer the registries under direction from the IETF and/or designated experts. So, having IANA administer (or host) the PSL would still mean that some designated expert or team of such would have to tell them what changes to make when. The benefits we'd get from IANA would be a long-term well-known place to find it, and a process to control the updates. But the mechanism for making changes would be the same. Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
John's idea is workable for policy lookup, but the PSL is also used for alignment and to protect the PSL names. Alignment starts by finding the longest shared DNS path between two addresses. The resulting string must be longer than any PSL entry, to verify that the names are in the same organization. Additionally, any email domain-part which exactly matches a PSL entry is fake (unless the PSL is wrong) and should be blocked. An alternative would require every organization to create a DNS token that says "ToipOfOrganization" at organization boundaires, but getting worldwide participation is unlikely. The best result would be for IANA to maintain the PSL. It seems obvious that this should be part of their job. But I assume that has been tried without success. On Tue, Oct 26, 2021 at 10:09 PM John Levine wrote: > It appears that Scott Kitterman said: > >For a 'normal' domain/sub-domain like eml.example.com where the domain > has a DMARC policy, every single implementation approach gives the > >same answer, so it doesn't matter. The challenge is getting all the > other cases right. > > > >Until we understand what we want, overall, selecting a specific design to > achieve that goal is premature. Both of those approaches will > >give a wrong answer (at least as I'd define it) for less usual cases. > > Yup. I think I was the first person to propose a tree-walk, so here is > roughly what I was thinking: > > The problem with organizational domain is that it is ill-defined. It > waves its hands and says to use something > like the PSL, and in practice everyone uses the PSL. But the PSL is a > moving target, with entries added and deleted > on a regular basis, so this month's organization domain may not be the > same as last month's. The advantage of the > tree walk is that the DMARC result now depends entirely on what is in the > DNS, not on a volunteer maintained list > whose volunteers keep reminding us that it's only intended to manage http > cookies. > > Todd's stats confirm my intuition that the DNS is pretty flat, and the > amount of mail that comes from addreses > with more than, say, four labels is miniscule. So if you do a four level > tree walk, you will find all of the > DMARC records for all of the real mail. > > The question remains what to do about the fake mail with 12 label > domains. My perhaps radical suggestion is to > say that if the author domain does not exist, i.e., you look it up and get > NXDOMAIN, then DMARC does not apply and > you do whatever you do to mail with fake addresses. Or perhaps you only > say that if it's NXDOMAIN and has more than > four labels. That way if you really want to use 12 label addresses, you > have to add a _dmarc record every four > levels. Nobody will do that, but nobody sends mail like that other than > to be perverse, so it doesn't matter. > > R's, > John > > ___ > 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] Topic for IETF 112 - Policy Discovery
It appears that Scott Kitterman said: >On Tuesday, October 26, 2021 10:09:13 PM EDT John Levine wrote: >> The question remains what to do about the fake mail with 12 label domains. >> My perhaps radical suggestion is to say that if the author domain does not >> exist, i.e., you look it up and get NXDOMAIN, then DMARC does not apply and >> you do whatever you do to mail with fake addresses. Or perhaps you only >> say that if it's NXDOMAIN and has more than four labels. That way if you >> really want to use 12 label addresses, you have to add a _dmarc record >> every four levels. Nobody will do that, but nobody sends mail like that >> other than to be perverse, so it doesn't matter. > >Thanks. From the bottom up, I think that seems reasonable, but my concern >(not surprisingly) is on the other end of the question. Should a policy found >at _dmarc.com be treated differently than _dmarc.example.com? If so, then >what >about _dmarc.gov.uk versus _example.gov.uk and how do we distinguish between >the first set and the second? Since we are writing a technical spec, the only answer is that we don't. The PSL, or anything like the PSL, is only someone's guess about relationships between various DNS subtrees. Let us not rehash the theological argument about who controls the DNS tree, the technical faction saying that each zone controls all of its descendants, and the political faction saying we have rules about that not visible in the DNS. One the one hand, zones like .BANK have real contracts that they want to enforce, but on the other hand, we have overclever hosting providers who imagine that the PSL is a get out of jail card for dealing with sleazy customers, and the PSL maintainers are not happy: https://github.com/publicsuffix/list/wiki/Third-Party-Diffusion I would say that if you have an issue with a DMARC record in the tree above your domain, that's a business issue with whoever controls that record, not a technical one. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On Tuesday, October 26, 2021 10:09:13 PM EDT John Levine wrote: > It appears that Scott Kitterman said: > >For a 'normal' domain/sub-domain like eml.example.com where the domain has > >a DMARC policy, every single implementation approach gives the same > >answer, so it doesn't matter. The challenge is getting all the other > >cases right. > > > >Until we understand what we want, overall, selecting a specific design to > >achieve that goal is premature. Both of those approaches will give a > >wrong answer (at least as I'd define it) for less usual cases. > Yup. I think I was the first person to propose a tree-walk, so here is > roughly what I was thinking: > > The problem with organizational domain is that it is ill-defined. It waves > its hands and says to use something like the PSL, and in practice everyone > uses the PSL. But the PSL is a moving target, with entries added and > deleted on a regular basis, so this month's organization domain may not be > the same as last month's. The advantage of the tree walk is that the DMARC > result now depends entirely on what is in the DNS, not on a volunteer > maintained list whose volunteers keep reminding us that it's only intended > to manage http cookies. > > Todd's stats confirm my intuition that the DNS is pretty flat, and the > amount of mail that comes from addreses with more than, say, four labels is > miniscule. So if you do a four level tree walk, you will find all of the > DMARC records for all of the real mail. > > The question remains what to do about the fake mail with 12 label domains. > My perhaps radical suggestion is to say that if the author domain does not > exist, i.e., you look it up and get NXDOMAIN, then DMARC does not apply and > you do whatever you do to mail with fake addresses. Or perhaps you only > say that if it's NXDOMAIN and has more than four labels. That way if you > really want to use 12 label addresses, you have to add a _dmarc record > every four levels. Nobody will do that, but nobody sends mail like that > other than to be perverse, so it doesn't matter. Thanks. From the bottom up, I think that seems reasonable, but my concern (not surprisingly) is on the other end of the question. Should a policy found at _dmarc.com be treated differently than _dmarc.example.com? If so, then what about _dmarc.gov.uk versus _example.gov.uk and how do we distinguish between the first set and the second? Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
It appears that Scott Kitterman said: >For a 'normal' domain/sub-domain like eml.example.com where the domain has a >DMARC policy, every single implementation approach gives the >same answer, so it doesn't matter. The challenge is getting all the other >cases right. > >Until we understand what we want, overall, selecting a specific design to >achieve that goal is premature. Both of those approaches will >give a wrong answer (at least as I'd define it) for less usual cases. Yup. I think I was the first person to propose a tree-walk, so here is roughly what I was thinking: The problem with organizational domain is that it is ill-defined. It waves its hands and says to use something like the PSL, and in practice everyone uses the PSL. But the PSL is a moving target, with entries added and deleted on a regular basis, so this month's organization domain may not be the same as last month's. The advantage of the tree walk is that the DMARC result now depends entirely on what is in the DNS, not on a volunteer maintained list whose volunteers keep reminding us that it's only intended to manage http cookies. Todd's stats confirm my intuition that the DNS is pretty flat, and the amount of mail that comes from addreses with more than, say, four labels is miniscule. So if you do a four level tree walk, you will find all of the DMARC records for all of the real mail. The question remains what to do about the fake mail with 12 label domains. My perhaps radical suggestion is to say that if the author domain does not exist, i.e., you look it up and get NXDOMAIN, then DMARC does not apply and you do whatever you do to mail with fake addresses. Or perhaps you only say that if it's NXDOMAIN and has more than four labels. That way if you really want to use 12 label addresses, you have to add a _dmarc record every four levels. Nobody will do that, but nobody sends mail like that other than to be perverse, so it doesn't matter. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
I was surprised to see that #111 and #112, about the definition of NP, survived to be included in this policy discussion. I remain strongly opposed to an NP policy based on A//MX.A brief recap: - A non-existent domain test should be based on a DNS query that returns NXDomain, not NODATA. - A non-existent domain test should be mutually exclusive with any existence test, but the A//MX allows for a message to be simultaneously authenticated by a domain DKIM signature and repudiated by absence of an A//MX record. - A non-existent domain test should allow for unpublished From addresses to become DNS-published without imputing behavior. This can be accomplished with a TXT record, but cannot be accomplished with an A, , or MX record. - A non-existence test based on NXDomain can be accomplished with one extra DNS query, while a test based on A//MX requires multiple additional queries. - A non-existence test based on NXDomain can definitively state that the name does not exist in DNS. A test based on A//MX says that the name might be used for email if found, and might not be used for email if not found., An ambiguous result is a useless result. But past attempts to get these problems addressed have been fruitless. I do not understand why. Doug Foster On Mon, Oct 25, 2021 at 3:33 PM Todd Herr wrote: > Greetings. > > There are, by my count, eleven tickets that are primarily focused on or at > least touch on the issue of policy discovery. A specialized query for them > is at this URL - https://trac.ietf.org/trac/dmarc/report/15 > > The question of policy discovery has a few options as its answer: > >- Leave things as they are (meaning look up the policy for the >RFC5322.From domain and the organizational domain of that domain if >different) >- Add a third lookup for a public suffix domain >- Walk the DNS tree from the RFC5322.From domain all the way to an >agreed-upon level in the DNS hierarchy >- Something other than what's listed here > > The topic of policy discovery has been proposed for the agenda for the > upcoming DMARC session at IETF 112, and so this message should serve to > kick off a discussion of the topic now, so that we can have a most > productive discussion on the 9th. > > Thank you. > > -- > > *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
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On October 26, 2021 9:03:15 PM UTC, Todd Herr wrote: >On Tue, Oct 26, 2021 at 4:07 PM Scott Kitterman >wrote: > >> >> What does "an agreed-upon level in the DNS hierarchy" mean? The >> organizational domain is the current "agreed-upon level". Is this the >> same or >> something different? We know you can't do this by counting dots in a >> domain >> name. If it's the same level as the current organizational domain, then >> I'm >> not sure why we would want to add more lookups. I'm not aware of a >> problem >> that would solve. If it's all the way to the top of the hierarchy, then >> I'm >> confident the answer is no. Regardless of exactly how the PSD experiment >> lands, the rules for a PSD level lookup need to be different than for an >> individual organization, so we still need to know where the break between >> the >> organizational level and the top level is (so still not sure why you would >> want to do more lookups). >> >> >There are two tickets of the eleven that advocate walking the tree. One, >ticket #60, suggests walking the entire DNS tree until a policy is >discovered. The other, ticket #121, champions a "one level tree walk". > >My use of the phrase "an agreed-upon level in the DNS hierarchy" was meant >to acknowledge that both tickets exist, and that both propose the same >method (tree walking) with different end points. > Thanks for the clarification. For a 'normal' domain/sub-domain like eml.example.com where the domain has a DMARC policy, every single implementation approach gives the same answer, so it doesn't matter. The challenge is getting all the other cases right. Until we understand what we want, overall, selecting a specific design to achieve that goal is premature. Both of those approaches will give a wrong answer (at least as I'd define it) for less usual cases. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On Tue, Oct 26, 2021 at 5:03 PM Todd Herr wrote: > On Tue, Oct 26, 2021 at 4:07 PM Scott Kitterman > wrote: > >> >> What does "an agreed-upon level in the DNS hierarchy" mean? The >> organizational domain is the current "agreed-upon level". Is this the >> same or >> something different? We know you can't do this by counting dots in a >> domain >> name. If it's the same level as the current organizational domain, then >> I'm >> not sure why we would want to add more lookups. I'm not aware of a >> problem >> that would solve. If it's all the way to the top of the hierarchy, then >> I'm >> confident the answer is no. Regardless of exactly how the PSD experiment >> lands, the rules for a PSD level lookup need to be different than for an >> individual organization, so we still need to know where the break between >> the >> organizational level and the top level is (so still not sure why you >> would >> want to do more lookups). >> >> > There are two tickets of the eleven that advocate walking the tree. One, > ticket #60, suggests walking the entire DNS tree until a policy is > discovered. The other, ticket #121, champions a "one level tree walk". > > My use of the phrase "an agreed-upon level in the DNS hierarchy" was meant > to acknowledge that both tickets exist, and that both propose the same > method (tree walking) with different end points. > > And when I wrote "ticket #60" above, I meant "ticket #68". https://trac.ietf.org/trac/dmarc/ticket/68 https://trac.ietf.org/trac/dmarc/ticket/121 -- *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] Topic for IETF 112 - Policy Discovery
On Tue, Oct 26, 2021 at 4:07 PM Scott Kitterman wrote: > > What does "an agreed-upon level in the DNS hierarchy" mean? The > organizational domain is the current "agreed-upon level". Is this the > same or > something different? We know you can't do this by counting dots in a > domain > name. If it's the same level as the current organizational domain, then > I'm > not sure why we would want to add more lookups. I'm not aware of a > problem > that would solve. If it's all the way to the top of the hierarchy, then > I'm > confident the answer is no. Regardless of exactly how the PSD experiment > lands, the rules for a PSD level lookup need to be different than for an > individual organization, so we still need to know where the break between > the > organizational level and the top level is (so still not sure why you would > want to do more lookups). > > There are two tickets of the eleven that advocate walking the tree. One, ticket #60, suggests walking the entire DNS tree until a policy is discovered. The other, ticket #121, champions a "one level tree walk". My use of the phrase "an agreed-upon level in the DNS hierarchy" was meant to acknowledge that both tickets exist, and that both propose the same method (tree walking) with different end points. -- *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] Topic for IETF 112 - Policy Discovery
On Monday, October 25, 2021 3:30:19 PM EDT Todd Herr wrote: > Greetings. > > There are, by my count, eleven tickets that are primarily focused on or at > least touch on the issue of policy discovery. A specialized query for them > is at this URL - https://trac.ietf.org/trac/dmarc/report/15 > > The question of policy discovery has a few options as its answer: > >- Leave things as they are (meaning look up the policy for the >RFC5322.From domain and the organizational domain of that domain if >different) >- Add a third lookup for a public suffix domain >- Walk the DNS tree from the RFC5322.From domain all the way to an >agreed-upon level in the DNS hierarchy >- Something other than what's listed here > > The topic of policy discovery has been proposed for the agenda for the > upcoming DMARC session at IETF 112, and so this message should serve to > kick off a discussion of the topic now, so that we can have a most > productive discussion on the 9th. I think you are getting ahead of yourself as I think we would need to understand a number of other things first. Here's some immediate things that I think would need to be considered. It wouldn't surprise me if I think of more later. What does "an agreed-upon level in the DNS hierarchy" mean? The organizational domain is the current "agreed-upon level". Is this the same or something different? We know you can't do this by counting dots in a domain name. If it's the same level as the current organizational domain, then I'm not sure why we would want to add more lookups. I'm not aware of a problem that would solve. If it's all the way to the top of the hierarchy, then I'm confident the answer is no. Regardless of exactly how the PSD experiment lands, the rules for a PSD level lookup need to be different than for an individual organization, so we still need to know where the break between the organizational level and the top level is (so still not sure why you would want to do more lookups). Before we have results from the PSD experiment it would be premature to decide either to included (add the third lookup) or exclude it (decide not to add the third lookup). I recall a strong preference to do away with the PSL to define the org domain, but we've continually foundered on coming up with a suitable replacement that can achieve consensus. I'd suggest coming to some agreement on an alternate method to define the org domain or that we don't care and we can identical policy discovery to the top of the hierarchy would be the first questions to answer. Once we know the answers to those questions, then I think the actual policy discovery question will be relatively simple. My prediction is that we will pretty quickly conclude that the org domain construct is essential and then flounder for some time again about how to replace the PSL. As a thought experiment, if the PSD is always consulted when an org doesn't have a DMARC record (because we're just walking up the tree), how does everyone feel about _dmarc.com publishing sp=reject with a reporting address so that the .com operator gets feedback reports for every single .com domain that hasn't deployed DMARC yet? Unless the group consensus is that we're comfortable with that, then ditching the org domain isn't an option. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
For me, the appeal of a tree walk would be to eliminate the PSL. But an artificially constructed domain name could have more than 100 segments, so walking the entire tree seems like an opportunity for denial of service attacks. If we walk up from the bottom and quit too soon, a phony but long name could be used to evade the actual domain policy. We could limit complexity by starting at the PSL or organization and walking down a limited number of segments, but this approach preserves the need for a PSL. These objections would not apply to a solution like the one suggested in ticket #59, where a name is checked for membership in a single sub-organizational unit. Eliminating the PSL was not an objective of ticket 59. Doug On Mon, Oct 25, 2021 at 3:33 PM Todd Herr wrote: > Greetings. > > There are, by my count, eleven tickets that are primarily focused on or at > least touch on the issue of policy discovery. A specialized query for them > is at this URL - https://trac.ietf.org/trac/dmarc/report/15 > > The question of policy discovery has a few options as its answer: > >- Leave things as they are (meaning look up the policy for the >RFC5322.From domain and the organizational domain of that domain if >different) >- Add a third lookup for a public suffix domain >- Walk the DNS tree from the RFC5322.From domain all the way to an >agreed-upon level in the DNS hierarchy >- Something other than what's listed here > > The topic of policy discovery has been proposed for the agenda for the > upcoming DMARC session at IETF 112, and so this message should serve to > kick off a discussion of the topic now, so that we can have a most > productive discussion on the 9th. > > Thank you. > > -- > > *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
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
I know there has been a fair bit of talk about walk-the-tree. Taking a 24h set of data, and trying to measure the number of times where this situation may be warranted. We can try to make a guess the goal is to look for a DMARC policy between the 5322.From which has an unknown number of dotted sections, and the second-level/apex/organizational domain. I extracted the 5322.From and counted the number of "." in the field. So "1" dot, means example.com, "2" means third.example.com, and so on. I included the policy as well, abs(ent)/none/quarantine/reject. In roughly 86% of cases, the domain of record is in the format of "example.com". In about 13%, we have "third.example.com". The other <1% are other variations. Not exactly sure if this data tells us walking-the-tree is going to be advantageous, but thought I would share with others. Let me know if you have questions, or would like to see different data (that I'd be allowed to share) Note: This is percentage of messages, not percentage of domains (apologies if the formatting goes sideways) Num_dotsPolicy PctOfTraffic -- - --- 1 none60.9147275180 1 abs 11.4060937845 1 reject 10.9984823560 2 quarantine 7.3245642177 1 quarantine 3.1460328512 2 abs 2.5626295515 2 reject 2.1029313056 2 none1.1140098795 3 abs 0.1924108697 3 reject 0.1362830691 3 none0.0797639119 3 quarantine 0.0173744076 4 abs 0.0021115047 4 reject 0.0017292496 6 abs 0.0003094447 4 none0.0002730394 4 quarantine 0.0001092158 5 quarantine 0.0001092158 5 abs 0.364053 5 none0.091013 6 none0.091013 -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: dmarc On Behalf Of Todd Herr Sent: Monday, October 25, 2021 3:30 PM To: IETF DMARC WG Subject: [dmarc-ietf] Topic for IETF 112 - Policy Discovery Greetings. There are, by my count, eleven tickets that are primarily focused on or at least touch on the issue of policy discovery. A specialized query for them is at this URL - https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/report/15__;!!CQl3mcHX2A!VGJAEdJ0DpNqMeFma5x4t8ehOeZpPCdYqZs4Dq9_D2Zja366Lx0pcwqK4DFcSskDWHhaFXGCzA$ The question of policy discovery has a few options as its answer: • Leave things as they are (meaning look up the policy for the RFC5322.From domain and the organizational domain of that domain if different) • Add a third lookup for a public suffix domain • Walk the DNS tree from the RFC5322.From domain all the way to an agreed-upon level in the DNS hierarchy • Something other than what's listed here The topic of policy discovery has been proposed for the agenda for the upcoming DMARC session at IETF 112, and so this message should serve to kick off a discussion of the topic now, so that we can have a most productive discussion on the 9th. Thank you. -- Todd Herr | Technical Director, Standards and Ecosystem e: mailto: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
