Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)
On Sat 04/Dec/2021 23:02:50 +0100 Seth Blank wrote: On Sat, Dec 4, 2021 at 10:00 AM John Levine wrote: It appears that Murray S. Kucherawy said: This was reported but not sent to the WG. I believe the right disposition is "Hold for Document Update". Does anyone want to argue for "Rejected" or "Verified"? Reject it. Whether you choose to believe the non-ICANN part of the PSL is local policy. I also think that Scott's example in the notes is wrong. It is perfectly plasuble for an operator's customers to have their own DMARC policy, although most of the subdomains are less exotic than this one. Try Centralic's us.com where I think you would not want foo.us.com and bar.us.com to share the same default policy. > +1 Scott's example, which he states as wrong, is in fact correct. The org domain should in fact be example.s3.dualstack.ap-northeast-1.amazonaws.com and not amazonaws.com, as amazonaws.com is not the organization which controls policy for, or should receive reports for, the organization which has registered and is using example.s3.dualstack.ap-northeast-1.amazonaws.com. +1 While I agree that editing the PSL before giving it as a parameter to a DMARC filter is a question of local policy, a discussion on the effects produced by varying the attribution of org domains is required, especially now that we are enabling domains to freely appoint themselves as PSDs. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)
As discussion after I had filed this makes clear, my proposed solution isn't a great one. Since we're well on our way towards removing PSL use from the DMARC revision, I don't think it matters a lot whether we reject it or hold for document update and mark it resolved when the new revision is finalized. Although it is certainly a corner case, I think it's illustrative of why getting away from the PSL for this use will be a good thing. Scott K On December 4, 2021 6:00:25 PM UTC, John Levine wrote: >It appears that Murray S. Kucherawy said: >>-=-=-=-=-=- >> >>This was reported but not sent to the WG. I believe the right disposition >>is "Hold for Document Update". Does anyone want to argue for "Rejected" or >>"Verified"? > >Reject it. Whether you choose to believe the non-ICANN part of the PSL is >local policy. > >I also think that Scott's example in the notes is wrong. It is perfectly >plasuble for an operator's customers to have their own DMARC policy, although >most >of the subdomains are less exotic than this one. Try Centralic's us.com >where I think you would not want foo.us.com and bar.us.com to share the >same default policy. > >R's, >John > >>-- Forwarded message - >>From: RFC Errata System >>Date: Mon, Nov 1, 2021 at 4:31 PM >>Subject: [Technical Errata Reported] RFC7489 (6729) >>To: , , >>Cc: , >> >> >>The following errata report has been submitted for RFC7489, >>"Domain-based Message Authentication, Reporting, and Conformance (DMARC)". >> >>-- >>You may review the report below and at: >>https://www.rfc-editor.org/errata/eid6729 >> >>-- >>Type: Technical >>Reported by: Scott Kitterman >> >>Section: 3.2 >> >>Original Text >>- >> 3. Search the public suffix list for the name that matches the >> largest number of labels found in the subject DNS domain. Let >> that number be "x". >> >>Corrected Text >>-- >> 3. Search the ICANN DOMAINS section of the public suffix list for >> the name that matches the largest number of labels found in the >> subject DNS domain. Let that number be "x". >> >>Notes >>- >>The PSL includes both public and private domains. RFC 7489 should have >>limited name matching to the public, ICANN DOMAINS section of the PSL. As >>an example, using the current PSL, the organizational domain for >>example.s3.dualstack.ap-northeast-1.amazonaws.com is >>example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com since >>it is listed in the private section of the PSL. This is clearly the wrong >>result. >> >>Instructions: >>- >>This erratum is currently posted as "Reported". If necessary, please >>use "Reply All" to discuss whether it should be verified or >>rejected. When a decision is reached, the verifying party >>can log in to change the status and edit the report, if necessary. >> >>-- >>RFC7489 (draft-kucherawy-dmarc-base-12) >>-- >>Title : Domain-based Message Authentication, Reporting, and >>Conformance (DMARC) >>Publication Date: March 2015 >>Author(s) : M. Kucherawy, Ed., E. Zwicky, Ed. >>Category: INFORMATIONAL >>Source : INDEPENDENT >>Area: N/A >>Stream : INDEPENDENT >>Verifying Party : ISE & Editorial Board >> >>-=-=-=-=-=- >>[Alternative: text/html] >>-=-=-=-=-=- > > >___ >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] Fwd: [Technical Errata Reported] RFC7489 (6729)
On Sat, Dec 4, 2021 at 10:00 AM John Levine wrote: > It appears that Murray S. Kucherawy said: > >-=-=-=-=-=- > > > >This was reported but not sent to the WG. I believe the right disposition > >is "Hold for Document Update". Does anyone want to argue for "Rejected" > or > >"Verified"? > > Reject it. Whether you choose to believe the non-ICANN part of the PSL is > local policy. > > I also think that Scott's example in the notes is wrong. It is perfectly > plasuble for an operator's customers to have their own DMARC policy, > although most > of the subdomains are less exotic than this one. Try Centralic's us.com > where I think you would not want foo.us.com and bar.us.com to share the > same default policy. > > R's, > John > +1 Scott's example, which he states as wrong, is in fact correct. The org domain should in fact be example.s3.dualstack.ap-northeast-1.amazonaws.com and not amazonaws.com, as amazonaws.com is not the organization which controls policy for, or should receive reports for, the organization which has registered and is using example.s3.dualstack.ap-northeast-1.amazonaws.com. Seth, as an individual > > >-- Forwarded message - > >From: RFC Errata System > >Date: Mon, Nov 1, 2021 at 4:31 PM > >Subject: [Technical Errata Reported] RFC7489 (6729) > >To: , , < > rfc-...@rfc-editor.org> > >Cc: , > > > > > >The following errata report has been submitted for RFC7489, > >"Domain-based Message Authentication, Reporting, and Conformance (DMARC)". > > > >-- > >You may review the report below and at: > >https://www.rfc-editor.org/errata/eid6729 > > > >-- > >Type: Technical > >Reported by: Scott Kitterman > > > >Section: 3.2 > > > >Original Text > >- > > 3. Search the public suffix list for the name that matches the > > largest number of labels found in the subject DNS domain. Let > > that number be "x". > > > >Corrected Text > >-- > > 3. Search the ICANN DOMAINS section of the public suffix list for > > the name that matches the largest number of labels found in the > > subject DNS domain. Let that number be "x". > > > >Notes > >- > >The PSL includes both public and private domains. RFC 7489 should have > >limited name matching to the public, ICANN DOMAINS section of the PSL. As > >an example, using the current PSL, the organizational domain for > >example.s3.dualstack.ap-northeast-1.amazonaws.com is > >example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com > since > >it is listed in the private section of the PSL. This is clearly the wrong > >result. > > > >Instructions: > >- > >This erratum is currently posted as "Reported". If necessary, please > >use "Reply All" to discuss whether it should be verified or > >rejected. When a decision is reached, the verifying party > >can log in to change the status and edit the report, if necessary. > > > >-- > >RFC7489 (draft-kucherawy-dmarc-base-12) > >-- > >Title : Domain-based Message Authentication, Reporting, and > >Conformance (DMARC) > >Publication Date: March 2015 > >Author(s) : M. Kucherawy, Ed., E. Zwicky, Ed. > >Category: INFORMATIONAL > >Source : INDEPENDENT > >Area: N/A > >Stream : INDEPENDENT > >Verifying Party : ISE & Editorial Board > > > >-=-=-=-=-=- > >[Alternative: text/html] > >-=-=-=-=-=- > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank * | Chief Product Officer *e:* s...@valimail.com *p:* 415.273.8818 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] Fwd: [Technical Errata Reported] RFC7489 (6729)
I must agree with Mr Levine on this. tim On Sat, Dec 4, 2021 at 1:00 PM John Levine wrote: > It appears that Murray S. Kucherawy said: > >-=-=-=-=-=- > > > >This was reported but not sent to the WG. I believe the right disposition > >is "Hold for Document Update". Does anyone want to argue for "Rejected" > or > >"Verified"? > > Reject it. Whether you choose to believe the non-ICANN part of the PSL is > local policy. > > I also think that Scott's example in the notes is wrong. It is perfectly > plasuble for an operator's customers to have their own DMARC policy, > although most > of the subdomains are less exotic than this one. Try Centralic's us.com > where I think you would not want foo.us.com and bar.us.com to share the > same default policy. > > R's, > John > > >-- Forwarded message - > >From: RFC Errata System > >Date: Mon, Nov 1, 2021 at 4:31 PM > >Subject: [Technical Errata Reported] RFC7489 (6729) > >To: , , < > rfc-...@rfc-editor.org> > >Cc: , > > > > > >The following errata report has been submitted for RFC7489, > >"Domain-based Message Authentication, Reporting, and Conformance (DMARC)". > > > >-- > >You may review the report below and at: > >https://www.rfc-editor.org/errata/eid6729 > > > >-- > >Type: Technical > >Reported by: Scott Kitterman > > > >Section: 3.2 > > > >Original Text > >- > > 3. Search the public suffix list for the name that matches the > > largest number of labels found in the subject DNS domain. Let > > that number be "x". > > > >Corrected Text > >-- > > 3. Search the ICANN DOMAINS section of the public suffix list for > > the name that matches the largest number of labels found in the > > subject DNS domain. Let that number be "x". > > > >Notes > >- > >The PSL includes both public and private domains. RFC 7489 should have > >limited name matching to the public, ICANN DOMAINS section of the PSL. As > >an example, using the current PSL, the organizational domain for > >example.s3.dualstack.ap-northeast-1.amazonaws.com is > >example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com > since > >it is listed in the private section of the PSL. This is clearly the wrong > >result. > > > >Instructions: > >- > >This erratum is currently posted as "Reported". If necessary, please > >use "Reply All" to discuss whether it should be verified or > >rejected. When a decision is reached, the verifying party > >can log in to change the status and edit the report, if necessary. > > > >-- > >RFC7489 (draft-kucherawy-dmarc-base-12) > >-- > >Title : Domain-based Message Authentication, Reporting, and > >Conformance (DMARC) > >Publication Date: March 2015 > >Author(s) : M. Kucherawy, Ed., E. Zwicky, Ed. > >Category: INFORMATIONAL > >Source : INDEPENDENT > >Area: N/A > >Stream : INDEPENDENT > >Verifying Party : ISE & Editorial Board > > > >-=-=-=-=-=- > >[Alternative: text/html] > >-=-=-=-=-=- > > > ___ > 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] Fwd: [Technical Errata Reported] RFC7489 (6729)
It appears that Murray S. Kucherawy said: >-=-=-=-=-=- > >This was reported but not sent to the WG. I believe the right disposition >is "Hold for Document Update". Does anyone want to argue for "Rejected" or >"Verified"? Reject it. Whether you choose to believe the non-ICANN part of the PSL is local policy. I also think that Scott's example in the notes is wrong. It is perfectly plasuble for an operator's customers to have their own DMARC policy, although most of the subdomains are less exotic than this one. Try Centralic's us.com where I think you would not want foo.us.com and bar.us.com to share the same default policy. R's, John >-- Forwarded message - >From: RFC Errata System >Date: Mon, Nov 1, 2021 at 4:31 PM >Subject: [Technical Errata Reported] RFC7489 (6729) >To: , , >Cc: , > > >The following errata report has been submitted for RFC7489, >"Domain-based Message Authentication, Reporting, and Conformance (DMARC)". > >-- >You may review the report below and at: >https://www.rfc-editor.org/errata/eid6729 > >-- >Type: Technical >Reported by: Scott Kitterman > >Section: 3.2 > >Original Text >- > 3. Search the public suffix list for the name that matches the > largest number of labels found in the subject DNS domain. Let > that number be "x". > >Corrected Text >-- > 3. Search the ICANN DOMAINS section of the public suffix list for > the name that matches the largest number of labels found in the > subject DNS domain. Let that number be "x". > >Notes >- >The PSL includes both public and private domains. RFC 7489 should have >limited name matching to the public, ICANN DOMAINS section of the PSL. As >an example, using the current PSL, the organizational domain for >example.s3.dualstack.ap-northeast-1.amazonaws.com is >example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com since >it is listed in the private section of the PSL. This is clearly the wrong >result. > >Instructions: >- >This erratum is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party >can log in to change the status and edit the report, if necessary. > >-- >RFC7489 (draft-kucherawy-dmarc-base-12) >-- >Title : Domain-based Message Authentication, Reporting, and >Conformance (DMARC) >Publication Date: March 2015 >Author(s) : M. Kucherawy, Ed., E. Zwicky, Ed. >Category: INFORMATIONAL >Source : INDEPENDENT >Area: N/A >Stream : INDEPENDENT >Verifying Party : ISE & Editorial Board > >-=-=-=-=-=- >[Alternative: text/html] >-=-=-=-=-=- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)
This was reported but not sent to the WG. I believe the right disposition is "Hold for Document Update". Does anyone want to argue for "Rejected" or "Verified"? -MSK -- Forwarded message - From: RFC Errata System Date: Mon, Nov 1, 2021 at 4:31 PM Subject: [Technical Errata Reported] RFC7489 (6729) To: , , Cc: , The following errata report has been submitted for RFC7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6729 -- Type: Technical Reported by: Scott Kitterman Section: 3.2 Original Text - 3. Search the public suffix list for the name that matches the largest number of labels found in the subject DNS domain. Let that number be "x". Corrected Text -- 3. Search the ICANN DOMAINS section of the public suffix list for the name that matches the largest number of labels found in the subject DNS domain. Let that number be "x". Notes - The PSL includes both public and private domains. RFC 7489 should have limited name matching to the public, ICANN DOMAINS section of the PSL. As an example, using the current PSL, the organizational domain for example.s3.dualstack.ap-northeast-1.amazonaws.com is example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com since it is listed in the private section of the PSL. This is clearly the wrong result. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC7489 (draft-kucherawy-dmarc-base-12) -- Title : Domain-based Message Authentication, Reporting, and Conformance (DMARC) Publication Date: March 2015 Author(s) : M. Kucherawy, Ed., E. Zwicky, Ed. Category: INFORMATIONAL Source : INDEPENDENT Area: N/A Stream : INDEPENDENT Verifying Party : ISE & Editorial Board ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
