Re: [dmarc-ietf] Treewalk causing changes
Oh well. It is hardly the first time that consensus did not involve my consent. On Thu, Feb 23, 2023, 9:03 PM 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 < > barryle...@computer.org> 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
Re: [dmarc-ietf] Treewalk causing changes
It appears that Douglas Foster said: >-=-=-=-=-=- > >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. The current design has been in the draft since October, and we discussed it on this list at great length. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Treewalk causing changes
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
Re: [dmarc-ietf] Treewalk causing changes
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
Re: [dmarc-ietf] Treewalk causing changes
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" Good catch, although in this case I think the most likely result is that the people at bmcc.cuny.edu will say "who set up Ret.bmcc.cuny.edu?" I see that bmcc.cuny.edu and cuny.edu both use Proofpoint in front of O365, while Ret.bmcc.cuny.edu goes directly to O365. There's some other strangeness; www.cuny.edu is a CNAME for web.cuny.edu which has an MX to mail-relay.cuny.edu. which has 7 A records pointing to machines running sendmail. It might be interesting to set up a web page where you can put in a mail domain and it'll tell you whether its treatment will change with the tree walk. Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", 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] Treewalk causing changes
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
Re: [dmarc-ietf] Treewalk causing changes
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
Re: [dmarc-ietf] Treewalk causing changes
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 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
Re: [dmarc-ietf] Info for SitRep
If anyone in the DMARC wg has status information for us to include in the Silicon Valley Red Cross chapter monthly report, I'll be glad to include it. For the rest of you, apologies for the misaddressed message... d/ On 2/23/2023 2:58 PM, Dave Crocker wrote: On 2/23/2023 2:23 PM, Meyerson, Julie wrote: As I discussed last volunteer meeting, I'm not able to access the doc for editing the SitRep. Here's what I'd like to include for community disaster education. Julie, I'll add your text, but would like to do a session with you to try to figure out the problem. Any chance you have some time tomorrow (Friday) afternoon? d/ -- Dave Crocker dcroc...@gmail.com mast:@dcrocker@mastodon.social 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] Info for SitRep
On 2/23/2023 2:23 PM, Meyerson, Julie wrote: As I discussed last volunteer meeting, I'm not able to access the doc for editing the SitRep. Here's what I'd like to include for community disaster education. Julie, I'll add your text, but would like to do a session with you to try to figure out the problem. Any chance you have some time tomorrow (Friday) afternoon? d/ -- Dave Crocker dcroc...@gmail.com mast:@dcrocker@mastodon.social 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
[dmarc-ietf] Treewalk causing changes
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
Re: [dmarc-ietf] Pros & cons with keeping v=1 when replacing pct with t
Since as long as the pct is not zero, any message can have the policy applied, I don't think this is a substantiative compatibility break that warrants a version bump. A version bump effectively translates to 'this is a new protocol with zero deployment', which is not what this group is chartered to do. 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. Scott K On February 23, 2023 7:18:11 PM UTC, Emil Gustafsson wrote: >I recognize that the changes in DMARCbis without also changing v=2 are >possible and don't cause a security problem as ignoring "pct" when parsers >are updated should result in the more restricive policy being applied. >I think however there is a practical problem. As a mailbox provider I would >not want to just switch parsers but will need to examine the DMARC record >and actually support both pct and t for backward compatibility just in >order to not change the behavior overnight for our users. > >I also noticed by looking at some recent data in our logs that there is a >significant number of emails received with p=quarantine or p=reject where >the pct value that is neither 0 nor 100 (so not 1:1 compatible with t). > >I think having DMARCbis actually changing the version would simplify and >keep the interpretation of DMARC records consistent. > >What do you think? >/E ___ 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 2/23/2023 11:20 AM, Trent Adams wrote: I agree... given that changes are being made, it makes total sense to rev the version number. a natural assessment. unfortunately it has problems. version numbers mostly don't work. if the changes produce a spec that is a superset of the previous version, the new stuff is self-declaring and version number isn't needed. if the changes produce an incompatible spec, it's a new protocol, rather than a 'version'. cf, MIME history that landed on this realization. d/ -- Dave Crocker dcroc...@gmail.com mast:@dcrocker@mastodon.social 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] Pros & cons with keeping v=1 when replacing pct with t
It appears that Trent Adams said: >-=-=-=-=-=- > > >I agree... given that changes are being made, it makes total sense to rev the >version number. That means that everyone will have to publish two DMARC records, one with v=1 and one with v=2. How long until it's safe not to publish the v=1? Since we've never done a version bump before, how confident are we that existing DMARC libraries will ignore the v=2 record and look at the v=1 record? Remember that the DNS makes no promises about the order of records so half the time the v=1 will be first, half the time the v=2 will be first. I do not see what problem a version bump would change. New code will ignore the pct tag, old code will ignore the t tag. While it's possible that the t= tag might confuse existing libraries, I think that's less likely to be a problem than picking the right one from two records with different version numbers. R's, John ___ 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 agree... given that changes are being made, it makes total sense to rev the version number. - Trent From: dmarc on behalf of Emil Gustafsson Date: Thursday, February 23, 2023 at 11:18 AM To: DMARC IETF Subject: [dmarc-ietf] Pros & cons with keeping v=1 when replacing pct with t I recognize that the changes in DMARCbis without also changing v=2 are possible and don't cause a security problem as ignoring "pct" when parsers are updated should result in the more restricive policy being applied. I think however I recognize that the changes in DMARCbis without also changing v=2 are possible and don't cause a security problem as ignoring "pct" when parsers are updated should result in the more restricive policy being applied. I think however there is a practical problem. As a mailbox provider I would not want to just switch parsers but will need to examine the DMARC record and actually support both pct and t for backward compatibility just in order to not change the behavior overnight for our users. I also noticed by looking at some recent data in our logs that there is a significant number of emails received with p=quarantine or p=reject where the pct value that is neither 0 nor 100 (so not 1:1 compatible with t). I think having DMARCbis actually changing the version would simplify and keep the interpretation of DMARC records consistent. What do you think? /E ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Pros & cons with keeping v=1 when replacing pct with t
I recognize that the changes in DMARCbis without also changing v=2 are possible and don't cause a security problem as ignoring "pct" when parsers are updated should result in the more restricive policy being applied. I think however there is a practical problem. As a mailbox provider I would not want to just switch parsers but will need to examine the DMARC record and actually support both pct and t for backward compatibility just in order to not change the behavior overnight for our users. I also noticed by looking at some recent data in our logs that there is a significant number of emails received with p=quarantine or p=reject where the pct value that is neither 0 nor 100 (so not 1:1 compatible with t). I think having DMARCbis actually changing the version would simplify and keep the interpretation of DMARC records consistent. What do you think? /E ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] I-D Action: draft-ietf-dmarc-failure-reporting-06.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-06.txt Pages : 15 Date: 2023-02-23 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-06.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-failure-reporting-06 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
