Re: [dmarc-ietf] Treewalk causing changes
On February 25, 2023 5:57:54 AM UTC, John Levine wrote: >It appears that Seth Blank said: >>-=-=-=-=-=- >> >>This feels too complicated, and like it adds back in complexity that jumps >>between labels, which was the exact confusion (jumping instead of walking) >>that the tree walk aimed to fixed. > >It also adds all the problems you get with CNAMEs, like long chains >and loops. If you have enough control over your DMARC records to add a >"refer" thing, why couldn't you just copy the policy you want to use? > >While I agree that the results for ret.bmcc.cuny.edu will be >different, I see precious little reason to think that anyone would >care. If people can find examples where it's more plausible that the >difference would matter, please send them along. Agreed. Adding sp=none to the bmcc.cuny.edu would achieve the same result without adding complexity to the protocol. Let's not (add the complexity). Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Treewalk causing changes
It appears that Seth Blank said: >-=-=-=-=-=- > >This feels too complicated, and like it adds back in complexity that jumps >between labels, which was the exact confusion (jumping instead of walking) >that the tree walk aimed to fixed. It also adds all the problems you get with CNAMEs, like long chains and loops. If you have enough control over your DMARC records to add a "refer" thing, why couldn't you just copy the policy you want to use? While I agree that the results for ret.bmcc.cuny.edu will be different, I see precious little reason to think that anyone would care. If people can find examples where it's more plausible that the difference would matter, please send them along. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Treewalk causing changes
I am intrigued by Alex's idea. We are trying to replace the PSL because of potential errors, but the proposed Tree Walk also has ambiguity that leads to potential errors. The ideal solution would be for domain owners to publish apply an exact-match policy for every valid From domain, just like SPF.Then the default policy is used to block non-mail domains, and every published policy could be used to ensure that this happens. But policy multiplication causes management complexity, because each policy triggers independent reporting to independently configured recipient addresses.The REFER:url term would allow the referred domain to provide any data that is not configured explicitly on the exact-match policy. Simplified administration without ambiguity. Seems like a big win. DF On Fri, Feb 24, 2023 at 3:21 PM Brotman, Alex wrote: > While discussing this with someone at the conference yesterday, we thought > perhaps we could introduce something of a referral. > > Currently: > _dmarc.ret.bmcc.cuny.edu NULL > _dmarc.bmcc.cuny.edu "v=DMARC1; p=quarantine; fo=1; rua=mailto: > dmarc_...@emaildefense.proofpoint.com; ruf=mailto: > dmarc_...@emaildefense.proofpoint.com" > _dmarc.cuny.edu "v=DMARC1;p=none;rua=mailto: > dmarc_...@emaildefense.proofpoint.com,mailto:post.mas...@cuny.edu > ;ruf=mailto:dmarc_...@emaildefense.proofpoint.com,mailto: > post.mas...@cuny.edu;fo=1" > > Proposed: > _dmarc.bmcc.cuny.edu "v=DMARC1;sp=refer:cuny.edu; p=quarantine; fo=1; > rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto: > dmarc_...@emaildefense.proofpoint.com" > > Adding the "sp=refer:cuny.edu" would allow the existing policy to be used > for undeclared subdomains under the third-level domain. This could be > useful in the situation where an OrgDomain would like to still maintain > some control over policy for the undeclared domains. > > We didn't give it a ton of thought, so if others believe it to be > problematic, that's understandable. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > > -Original Message- > > From: dmarc On Behalf Of Alessandro Vesely > > Sent: Friday, February 24, 2023 6:54 AM > > To: dmarc@ietf.org > > Subject: Re: [dmarc-ietf] Treewalk causing changes > > > > As I recall it, for some...@ret.bmcc.cuny.edu, the policy domain is > > bmcc.cuny.edu, so the policy is p=quarantine. However, the > organizational > > domain is cuny.edu, so a signature having d=anothersub.cuny.edu is > aligned. > > > > Correct? > > > > Best > > Ale > > > > > > On Fri 24/Feb/2023 03:03:08 +0100 Barry Leiba wrote: > > > I don't understand your point here, Doug. It seems more likely that a > > > subdomain of a subdomain should be following the latter subdomain's > > > policy by default, rather than the higher-level domain's. That is, > > > for a.b.c.d, "a" would be more likely to expect to follow "b" than > > > "c". Which means that the tree walk will give the desired result when > > > the PSL would generally not have done so. > > > > > > Are you disagreeing with that, as it seems? Or am I misunderstanding > you? > > > > > > Barry > > > > > > On Thu, Feb 23, 2023 at 5:56 PM Douglas Foster > > > wrote: > > >> > > >> I seem to have missed this redesign. I thought the plan had always > been to > > take the top-most policy not flagged as PSD=Y.Taking the first > policy found is > > less work, but it turns subdomain policies into organizational domain > policies. I > > expect that to be an unwanted surprise to many domain owners, since the > > subdomain policies will typically lack an sp clause. > > >> > > >> On Thu, Feb 23, 2023 at 7:46 PM Scott Kitterman > > > wrote: > > >>> > > >>> I don't find this to be a surprise. > > >>> > > >>> I believe we discussed this specific type of case early in the tree > walk > > discussion. An early proposal was to walk up the tree to find the PSD > and then > > reverse back down the tree to find the org domain (PSD +1). This > approach > > would have provided an identical result to the PSL design for this case, > but we > > concluded the added complexity and potential other issues made it not > the best > > approach. > > >>> > > >>> Up to now, I don't think anyone has suggested that DMARCbis needs to > > produce 100% identical results with RFC 7489. We know it won't, but the > > differences are at the margins and we assessed that they're okay. > > >>> > > >>> Scott K > > >>> > > >>> > > >>> On February 24, 2023 12:36:03 AM UTC, Barry Leiba > > wrote: > > >>> >The issue here, Tim, is that the current way of checking the PSL > > >>> >would send you to the DMARC record for cuny.edu and p=none, while > > >>> >using the new tree walk would send you to the DMARC record for > > bmcc.cuny.edu and p=quarantine. > > >>> > > > >>> >In this case, it’s showing that the tree walk is the better > > >>> >mechanism, because it’s pretty clear that it matches the > > >>> >publisher’s intent. But Elizabeth is pointing out that it DOES
Re: [dmarc-ietf] Treewalk causing changes
This feels too complicated, and like it adds back in complexity that jumps between labels, which was the exact confusion (jumping instead of walking) that the tree walk aimed to fixed. Seth, hatless On Fri, Feb 24, 2023 at 12:21 Brotman, Alex wrote: > While discussing this with someone at the conference yesterday, we thought > perhaps we could introduce something of a referral. > > Currently: > _dmarc.ret.bmcc.cuny.edu NULL > _dmarc.bmcc.cuny.edu "v=DMARC1; p=quarantine; fo=1; rua=mailto: > dmarc_...@emaildefense.proofpoint.com; ruf=mailto: > dmarc_...@emaildefense.proofpoint.com" > _dmarc.cuny.edu "v=DMARC1;p=none;rua=mailto: > dmarc_...@emaildefense.proofpoint.com,mailto:post.mas...@cuny.edu > ;ruf=mailto:dmarc_...@emaildefense.proofpoint.com,mailto: > post.mas...@cuny.edu;fo=1" > > Proposed: > _dmarc.bmcc.cuny.edu "v=DMARC1;sp=refer:cuny.edu; p=quarantine; fo=1; > rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto: > dmarc_...@emaildefense.proofpoint.com" > > Adding the "sp=refer:cuny.edu" would allow the existing policy to be used > for undeclared subdomains under the third-level domain. This could be > useful in the situation where an OrgDomain would like to still maintain > some control over policy for the undeclared domains. > > We didn't give it a ton of thought, so if others believe it to be > problematic, that's understandable. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > > -Original Message- > > From: dmarc On Behalf Of Alessandro Vesely > > Sent: Friday, February 24, 2023 6:54 AM > > To: dmarc@ietf.org > > Subject: Re: [dmarc-ietf] Treewalk causing changes > > > > As I recall it, for some...@ret.bmcc.cuny.edu, the policy domain is > > bmcc.cuny.edu, so the policy is p=quarantine. However, the > organizational > > domain is cuny.edu, so a signature having d=anothersub.cuny.edu is > aligned. > > > > Correct? > > > > Best > > Ale > > > > > > On Fri 24/Feb/2023 03:03:08 +0100 Barry Leiba wrote: > > > I don't understand your point here, Doug. It seems more likely that a > > > subdomain of a subdomain should be following the latter subdomain's > > > policy by default, rather than the higher-level domain's. That is, > > > for a.b.c.d, "a" would be more likely to expect to follow "b" than > > > "c". Which means that the tree walk will give the desired result when > > > the PSL would generally not have done so. > > > > > > Are you disagreeing with that, as it seems? Or am I misunderstanding > you? > > > > > > Barry > > > > > > On Thu, Feb 23, 2023 at 5:56 PM Douglas Foster > > > wrote: > > >> > > >> I seem to have missed this redesign. I thought the plan had always > been to > > take the top-most policy not flagged as PSD=Y.Taking the first > policy found is > > less work, but it turns subdomain policies into organizational domain > policies. I > > expect that to be an unwanted surprise to many domain owners, since the > > subdomain policies will typically lack an sp clause. > > >> > > >> On Thu, Feb 23, 2023 at 7:46 PM Scott Kitterman > > > wrote: > > >>> > > >>> I don't find this to be a surprise. > > >>> > > >>> I believe we discussed this specific type of case early in the tree > walk > > discussion. An early proposal was to walk up the tree to find the PSD > and then > > reverse back down the tree to find the org domain (PSD +1). This > approach > > would have provided an identical result to the PSL design for this case, > but we > > concluded the added complexity and potential other issues made it not > the best > > approach. > > >>> > > >>> Up to now, I don't think anyone has suggested that DMARCbis needs to > > produce 100% identical results with RFC 7489. We know it won't, but the > > differences are at the margins and we assessed that they're okay. > > >>> > > >>> Scott K > > >>> > > >>> > > >>> On February 24, 2023 12:36:03 AM UTC, Barry Leiba > > wrote: > > >>> >The issue here, Tim, is that the current way of checking the PSL > > >>> >would send you to the DMARC record for cuny.edu and p=none, while > > >>> >using the new tree walk would send you to the DMARC record for > > bmcc.cuny.edu and p=quarantine. > > >>> > > > >>> >In this case, it’s showing that the tree walk is the better > > >>> >mechanism, because it’s pretty clear that it matches the > > >>> >publisher’s intent. But Elizabeth is pointing out that it DOES > > >>> >change the result, which means that the result depends upon which > > >>> >version of the DMARC spec the receiving domain is using. > > >>> > > > >>> >Barry > > >>> > > > >>> >On Thu, Feb 23, 2023 at 3:51 PM Tim Wicinski > > wrote: > > >>> > > > >>> >> > > >>> >> Elizabeth, > > >>> >> > > >>> >> (speaking as a DNS person). I think this is "OK" - at my last > > >>> >> job we set up DMARC records which stricter in certain subdomains > > >>> >> than the parent domain. (Now I need to go find the machine where > > >>> >> I left my code which did all this validation). > > >>> >> > > >>> >> > >
Re: [dmarc-ietf] Treewalk causing changes
While discussing this with someone at the conference yesterday, we thought perhaps we could introduce something of a referral. Currently: _dmarc.ret.bmcc.cuny.edu NULL _dmarc.bmcc.cuny.edu "v=DMARC1; p=quarantine; fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto:dmarc_...@emaildefense.proofpoint.com"; _dmarc.cuny.edu "v=DMARC1;p=none;rua=mailto:dmarc_...@emaildefense.proofpoint.com,mailto:post.mas...@cuny.edu;ruf=mailto:dmarc_...@emaildefense.proofpoint.com,mailto:post.mas...@cuny.edu;fo=1"; Proposed: _dmarc.bmcc.cuny.edu "v=DMARC1;sp=refer:cuny.edu; p=quarantine; fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto:dmarc_...@emaildefense.proofpoint.com"; Adding the "sp=refer:cuny.edu" would allow the existing policy to be used for undeclared subdomains under the third-level domain. This could be useful in the situation where an OrgDomain would like to still maintain some control over policy for the undeclared domains. We didn't give it a ton of thought, so if others believe it to be problematic, that's understandable. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -Original Message- > From: dmarc On Behalf Of Alessandro Vesely > Sent: Friday, February 24, 2023 6:54 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Treewalk causing changes > > As I recall it, for some...@ret.bmcc.cuny.edu, the policy domain is > bmcc.cuny.edu, so the policy is p=quarantine. However, the organizational > domain is cuny.edu, so a signature having d=anothersub.cuny.edu is aligned. > > Correct? > > Best > Ale > > > On Fri 24/Feb/2023 03:03:08 +0100 Barry Leiba wrote: > > I don't understand your point here, Doug. It seems more likely that a > > subdomain of a subdomain should be following the latter subdomain's > > policy by default, rather than the higher-level domain's. That is, > > for a.b.c.d, "a" would be more likely to expect to follow "b" than > > "c". Which means that the tree walk will give the desired result when > > the PSL would generally not have done so. > > > > Are you disagreeing with that, as it seems? Or am I misunderstanding you? > > > > Barry > > > > On Thu, Feb 23, 2023 at 5:56 PM Douglas Foster > > wrote: > >> > >> I seem to have missed this redesign. I thought the plan had always been > >> to > take the top-most policy not flagged as PSD=Y.Taking the first policy > found is > less work, but it turns subdomain policies into organizational domain > policies. I > expect that to be an unwanted surprise to many domain owners, since the > subdomain policies will typically lack an sp clause. > >> > >> On Thu, Feb 23, 2023 at 7:46 PM Scott Kitterman > wrote: > >>> > >>> I don't find this to be a surprise. > >>> > >>> I believe we discussed this specific type of case early in the tree walk > discussion. An early proposal was to walk up the tree to find the PSD and > then > reverse back down the tree to find the org domain (PSD +1). This approach > would have provided an identical result to the PSL design for this case, but > we > concluded the added complexity and potential other issues made it not the best > approach. > >>> > >>> Up to now, I don't think anyone has suggested that DMARCbis needs to > produce 100% identical results with RFC 7489. We know it won't, but the > differences are at the margins and we assessed that they're okay. > >>> > >>> Scott K > >>> > >>> > >>> On February 24, 2023 12:36:03 AM UTC, Barry Leiba > wrote: > >>> >The issue here, Tim, is that the current way of checking the PSL > >>> >would send you to the DMARC record for cuny.edu and p=none, while > >>> >using the new tree walk would send you to the DMARC record for > bmcc.cuny.edu and p=quarantine. > >>> > > >>> >In this case, it’s showing that the tree walk is the better > >>> >mechanism, because it’s pretty clear that it matches the > >>> >publisher’s intent. But Elizabeth is pointing out that it DOES > >>> >change the result, which means that the result depends upon which > >>> >version of the DMARC spec the receiving domain is using. > >>> > > >>> >Barry > >>> > > >>> >On Thu, Feb 23, 2023 at 3:51 PM Tim Wicinski > wrote: > >>> > > >>> >> > >>> >> Elizabeth, > >>> >> > >>> >> (speaking as a DNS person). I think this is "OK" - at my last > >>> >> job we set up DMARC records which stricter in certain subdomains > >>> >> than the parent domain. (Now I need to go find the machine where > >>> >> I left my code which did all this validation). > >>> >> > >>> >> > >>> >> (As a DNS person I want to find the folks who put in the TXT > >>> >> record for _ dmarc.cuny.edu and ask them to quote their string. > >>> >> But that's my OCD). > >>> >> > >>> >> tim > >>> >> > >>> >> > >>> >> On Thu, Feb 23, 2023 at 5:30 PM Elizabeth Zwicky >>> >> 40otoh@dmarc.ietf.org> wrote: > >>> >> > >>> >>> > >>> >>> I haven’t done extensive research but here is a live example > >>> >>> where treewalk will cause a result change. > >>> >>> > >>>
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-failure-reporting-07.txt
Just exercised my re-gained editorship against shortening Terminology and a few nits. Best Ale On Fri 24/Feb/2023 13:03:13 +0100 internet-drafts wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Domain-based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting Authors : Steven M Jones Alessandro Vesely Filename: draft-ietf-dmarc-failure-reporting-07.txt Pages : 15 Date: 2023-02-24 Abstract: Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a domain owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports," or "failed message reports," which provide details about individual messages that failed to authenticate according to the DMARC mechanism. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-failure-reporting/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dmarc-failure-reporting-07.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-failure-reporting-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] I-D Action: draft-ietf-dmarc-failure-reporting-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Domain-based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting Authors : Steven M Jones Alessandro Vesely Filename: draft-ietf-dmarc-failure-reporting-07.txt Pages : 15 Date: 2023-02-24 Abstract: Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a domain owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports," or "failed message reports," which provide details about individual messages that failed to authenticate according to the DMARC mechanism. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-failure-reporting/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dmarc-failure-reporting-07.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-failure-reporting-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Pros & cons with keeping v=1 when replacing pct with t
I think the Tree Walk change presents a greater problem for v=1. The question is how often we have validation tests that match Elizabeth's example: - the examined domain name is two or more levels below the organizational domain, - the examined domain does not have a DMARC policy, - an intermediate domain has a DMARC policy, and - the organizational domain has a DMARC policy. This may be rare, and a subset of that number may produce the same results with either policy used. The most likely error will be that the intermediate DMARC policy prevents the examined domain from testing as aligned with the organizational domain. DF On Fri, Feb 24, 2023 at 6:43 AM Alessandro Vesely wrote: > On Thu 23/Feb/2023 21:17:09 +0100 Scott Kitterman wrote: > > > > If the consensus is that dropping pct requires a version bump, then I > think the correct solution is to not bump the version and add pct back to > the specification. > > > I think the consensus is to not bump version. > > Yet, it's true that the new I-D breaks pct=. It is still mentioned in > Appendix > 7, but it's not specified. I wish for a more gradual change. The tag > should > be handled by verifiers but not set in new DMARC records. > > When I'll upgrade my DMARC software, I'll add handling of t= but won't > remove > that of pct=, not until it disappears from DNSes. > > The inaccuracy of pct= is documented here: > https://en.wikipedia.org/wiki/Bernoulli_sampling > > > Best > Ale > -- > > > > ___ > 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] Treewalk causing changes
As I recall it, for some...@ret.bmcc.cuny.edu, the policy domain is bmcc.cuny.edu, so the policy is p=quarantine. However, the organizational domain is cuny.edu, so a signature having d=anothersub.cuny.edu is aligned. Correct? Best Ale On Fri 24/Feb/2023 03:03:08 +0100 Barry Leiba wrote: I don't understand your point here, Doug. It seems more likely that a subdomain of a subdomain should be following the latter subdomain's policy by default, rather than the higher-level domain's. That is, for a.b.c.d, "a" would be more likely to expect to follow "b" than "c". Which means that the tree walk will give the desired result when the PSL would generally not have done so. Are you disagreeing with that, as it seems? Or am I misunderstanding you? Barry On Thu, Feb 23, 2023 at 5:56 PM Douglas Foster wrote: I seem to have missed this redesign. I thought the plan had always been to take the top-most policy not flagged as PSD=Y.Taking the first policy found is less work, but it turns subdomain policies into organizational domain policies. I expect that to be an unwanted surprise to many domain owners, since the subdomain policies will typically lack an sp clause. On Thu, Feb 23, 2023 at 7:46 PM Scott Kitterman wrote: I don't find this to be a surprise. I believe we discussed this specific type of case early in the tree walk discussion. An early proposal was to walk up the tree to find the PSD and then reverse back down the tree to find the org domain (PSD +1). This approach would have provided an identical result to the PSL design for this case, but we concluded the added complexity and potential other issues made it not the best approach. Up to now, I don't think anyone has suggested that DMARCbis needs to produce 100% identical results with RFC 7489. We know it won't, but the differences are at the margins and we assessed that they're okay. Scott K On February 24, 2023 12:36:03 AM UTC, Barry Leiba wrote: >The issue here, Tim, is that the current way of checking the PSL would send >you to the DMARC record for cuny.edu and p=none, while using the new tree >walk would send you to the DMARC record for bmcc.cuny.edu and p=quarantine. > >In this case, it’s showing that the tree walk is the better mechanism, >because it’s pretty clear that it matches the publisher’s intent. But >Elizabeth is pointing out that it DOES change the result, which means that >the result depends upon which version of the DMARC spec the receiving >domain is using. > >Barry > >On Thu, Feb 23, 2023 at 3:51 PM Tim Wicinski wrote: > >> >> Elizabeth, >> >> (speaking as a DNS person). I think this is "OK" - at my last job we set >> up DMARC records which stricter in certain subdomains than >> the parent domain. (Now I need to go find the machine where I left my code >> which did all this validation). >> >> >> (As a DNS person I want to find the folks who put in the TXT record for _ >> dmarc.cuny.edu and ask them to quote their string. But that's >> my OCD). >> >> tim >> >> >> On Thu, Feb 23, 2023 at 5:30 PM Elizabeth Zwicky > 40otoh@dmarc.ietf.org> wrote: >> >>> >>> I haven’t done extensive research but here is a live example where >>> treewalk will cause a result change. >>> >>> From: is in the domain Ret.bmcc.cuny.edu which has no DMARC record. >>> >>> _dmarc.bmcc.cuny.edu.300INTXT"v=DMARC1; p=quarantine; >>> fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto: >>> dmarc_...@emaildefense.proofpoint.com" >>> >>> _dmarc.cuny.edu.3325INTXT"v=DMARC1;" "p=none;" >>> "rua=mailto:dmarc_...@emaildefense.proofpoint.com,mailto: >>> post.mas...@cuny.edu;" "ruf=mailto:dmarc_...@emaildefense.proofpoint.com >>> ,mailto:post.mas...@cuny.edu;"; "fo=1" >>> >>> Elizabeth Zwicky >>> ___ >>> 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 ___ 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] Pros & cons with keeping v=1 when replacing pct with t
On Thu 23/Feb/2023 21:17:09 +0100 Scott Kitterman wrote: If the consensus is that dropping pct requires a version bump, then I think the correct solution is to not bump the version and add pct back to the specification. I think the consensus is to not bump version. Yet, it's true that the new I-D breaks pct=. It is still mentioned in Appendix 7, but it's not specified. I wish for a more gradual change. The tag should be handled by verifiers but not set in new DMARC records. When I'll upgrade my DMARC software, I'll add handling of t= but won't remove that of pct=, not until it disappears from DNSes. The inaccuracy of pct= is documented here: https://en.wikipedia.org/wiki/Bernoulli_sampling Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
