Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <7f854d28-d3b5-fd00-4613-b8baa1217...@tana.it>, Alessandro Vesely writes >What I find nonsensical is to eliminate SPF in order to save DNS queries, at $DAYJOB$ (a large mailbox provider) SPF queries are limited to 15 ... since the prescribed limit of 10 was determined to cause too many SPF passes not to be found... > given >that we replaced local PSL lookups with a series of queries. We cannot do >that >and pretend that SPF is too expensive. the change here is not, I believe, 15 ... or even 10 (I think, counting quickly on my fingers, it's +3 -- and for the vast majority of cases +0) - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZIUeV92nQQHFxEViEQLzKgCfRotct0/P4e2sKJm0bGi/biVBF5gAnioH e8rlOpyGxUI3Y6+a4nQfCspM =nexz -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] PSD flag vs Version bump
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <20230610210457.b4c22e924...@ary.qy>, John Levine writes >We have two of the largest mail operators in the world saying that if >they can't tell which org domain scheme domain expects, they won't >implement the tree walk. We have to do something or we are wasting our >time. Clarity is everything ... reducing system complexity matters as well. Removing the need to consult a (reasonably) current version of the PSL matters a great deal, because even when operating at the scale that you can have engineers (and further systems) monitoring for when this does not happen is complexity that one would wish to dispose of. ie the new tree walk is an improvement and not just because of the new features it provides. Domain owners can learn when the new treewalk is being used by consulting aggregate reports... domains that wish to use the features the new treewalk provides may, in the fullness of time, start reaching out to the recalcitrant. For example, if you are gov.uk and running a special DNS system to make the old approach provide some safety, you may want to turn that system off, but you can only do that once mailbox provides have changed over. Meantime the mailbox providers want to know if they are behind the curve in using the new tree walk... tracking the DMARC records they fetch (or looking at surveys by people who fetch and count them) will tell them if domain owners know that things have changed. Personally (and I am not writing on behalf of $DAYJOB$) I think that signal "I know things have changed and am setting things up accordingly" is most clearly sent by bumping the version number, rather than relying on other more subtle syntax changes. viz: the version number bump is a clear signal that domain owners know what is going on (and is really easy to explain to them). That signal tells mailbox providers which tree walk (and any other changes) to use and when it is clear that we're into the long tail of domain owners who have not heard the messaging then is the time to say "well the new tree walk makes no difference" and delete the old code, stop fetching the PSL and decommission the monitoring... the final step is to ignore version 1 records completely (and signal that in aggregate reports)... I foresee almost no enthusiasm for running two systems in parallel in perpetuity. Running the simpler __system__ is clearly better all round but I do think that the fact that there are changes should be signalled very clearly rather than deduced ... it will make the messaging to the masses rather than the cognoscenti so much simpler. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZIT54d2nQQHFxEViEQJweACg4lDlD2TSRG8FoV/cmRtGRnKwVvYAnRpi S+YOpSRfkBjQATjp3bmb0WXM =1EKf -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] PSD flag vs Version bump
On June 10, 2023 9:04:57 PM UTC, John Levine wrote: >It appears that Scott Kitterman said: >> >>What's the incentive that any existing DMARC users (senders or receivers) >>would have to invest additional resources in another email >>authentication protocol? > >We have two of the largest mail operators in the world saying that if >they can't tell which org domain scheme domain expects, they won't >implement the tree walk. We have to do something or we are wasting our >time. > >So how about this: in the tree walk, you look for DMARC records that >have an explicit psd=y/n/u tag. If you find at least one record with a >tag, you use the new scheme. If you find no records with a tag, you >fall back to the old scheme. I think this will let people do >everything they can do with the current tree walk, while being >backward compatible. If you want a domain to be an org domain you put >psd=n, if you want the tree walk to skip it and keep looking, you put >psd=u, and if it's one of the 0.001% of domains that actually is a >PSD, you put psd=y. > >We already added DiscoveryType to the aggregate report schema so we >are OK there. Generally, I think it's fine, but specifically, I think we need to be careful about the language. Using PSL is 7489DMARC. Using tree walk is DMARCbis. I don't think we want to include all the PSL stuff in the bis document, so I think we need to avoid talking about it. We can update the tag description and include a statement that the presence of the tag is an indication that the record has been evaluated as being compatible with DMARCbis (which is I think what they actually want). At the rate we're going on the description of overall interoperability status of DMARC, I think there's plenty of time to work out the details. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] PSD flag vs Version bump
Why not say "SHOULD use tree walk", and then document, as explanation for "SHOULD" instead of "MUST", non-normative reasons why you might not? I don't think that will fly with the VLMPs. The mandatory PSD seems relatively easy to implement, just add it to the template you use for everything. R's, John On Sat, Jun 10, 2023 at 5:05 PM John Levine wrote: It appears that Scott Kitterman said: What's the incentive that any existing DMARC users (senders or receivers) would have to invest additional resources in another email authentication protocol? We have two of the largest mail operators in the world saying that if they can't tell which org domain scheme domain expects, they won't implement the tree walk. We have to do something or we are wasting our time. So how about this: in the tree walk, you look for DMARC records that have an explicit psd=y/n/u tag. If you find at least one record with a tag, you use the new scheme. If you find no records with a tag, you fall back to the old scheme. I think this will let people do everything they can do with the current tree walk, while being backward compatible. If you want a domain to be an org domain you put psd=n, if you want the tree walk to skip it and keep looking, you put psd=u, and if it's one of the 0.001% of domains that actually is a PSD, you put psd=y. We already added DiscoveryType to the aggregate report schema so we are OK there. R's, John PS: Whether we say people SHOULD NOT use SPF is a separate issue. 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] PSD flag vs Version bump
Hm... Why not say "SHOULD use tree walk", and then document, as explanation for "SHOULD" instead of "MUST", non-normative reasons why you might not? Waddyathink? Barry On Sat, Jun 10, 2023 at 5:05 PM John Levine wrote: > > It appears that Scott Kitterman said: > > > >What's the incentive that any existing DMARC users (senders or receivers) > >would have to invest additional resources in another email > >authentication protocol? > > We have two of the largest mail operators in the world saying that if > they can't tell which org domain scheme domain expects, they won't > implement the tree walk. We have to do something or we are wasting our > time. > > So how about this: in the tree walk, you look for DMARC records that > have an explicit psd=y/n/u tag. If you find at least one record with a > tag, you use the new scheme. If you find no records with a tag, you > fall back to the old scheme. I think this will let people do > everything they can do with the current tree walk, while being > backward compatible. If you want a domain to be an org domain you put > psd=n, if you want the tree walk to skip it and keep looking, you put > psd=u, and if it's one of the 0.001% of domains that actually is a > PSD, you put psd=y. > > We already added DiscoveryType to the aggregate report schema so we > are OK there. > > R's, > John > > PS: Whether we say people SHOULD NOT use SPF is a separate issue. > > > ___ > 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] PSD flag vs Version bump
It appears that Scott Kitterman said: > >What's the incentive that any existing DMARC users (senders or receivers) >would have to invest additional resources in another email >authentication protocol? We have two of the largest mail operators in the world saying that if they can't tell which org domain scheme domain expects, they won't implement the tree walk. We have to do something or we are wasting our time. So how about this: in the tree walk, you look for DMARC records that have an explicit psd=y/n/u tag. If you find at least one record with a tag, you use the new scheme. If you find no records with a tag, you fall back to the old scheme. I think this will let people do everything they can do with the current tree walk, while being backward compatible. If you want a domain to be an org domain you put psd=n, if you want the tree walk to skip it and keep looking, you put psd=u, and if it's one of the 0.001% of domains that actually is a PSD, you put psd=y. We already added DiscoveryType to the aggregate report schema so we are OK there. R's, John PS: Whether we say people SHOULD NOT use SPF is a separate issue. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
On Sat, Jun 10, 2023, at 12:50 AM, Barry Leiba wrote: > Are there working group participants who can do this sort of > evaluation, not just giving numbers but also analyzing why DKIM > failures happened when they should not have? As primarily an outbound ESP, we don't have access to relevant inbound logs, nor DMARC reports for customer domains, so our awareness of this issue is dependent on being told. That said, at MAAWG we were made aware of an edge case which is resulting in DKIM failures. Presumably, unknown bugs like this are inflating the numbers to support the "pro keeping SPF in DMARC" argument. I typically advise customers that DKIM (CNAMEs with managed rotation) is enough. But that's speaking as a sender that supports DKIM. I suppose that some senders still aren't willing to implement DKIM today. Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Version bump: was DMARC2 & SPF Dependency Removal
To the extent we might need it so far, I think the psd= tag is that flag. Scott K On June 10, 2023 7:34:59 PM UTC, Tim Wicinski wrote: >I'd rather add an option to flag some behavior rather than do a version >bump. > >Have to agree with Scott that version bumps take forever. >(I had a network engineer recently tell me that DNS packets *MUST* be no >larger than 512 bytes - and EDNS0 was 1999?) > >tim > >On Sat, Jun 10, 2023 at 3:03 PM Scott Kitterman >wrote: > >> >> >> On June 8, 2023 12:58:51 PM UTC, Tobias Herkula > 401und1...@dmarc.ietf.org> wrote: >> ... >> > >> >However, such a fundamental shift in the protocol's architecture warrants >> a clear signifier. I suggest we upgrade our DMARC version string from the >> current state to 'DMARC2.' This upgrade would not only denote the change of >> SPF removal, but also the switch from the Public Suffix List (PSL) to the >> Tree-Walk algorithm. >> > >> >By moving towards DMARC2, we not only update our standard to better >> reflect our present requirements, but we also make a clear commitment to >> the ongoing evolution and improvement of the protocol. >> >> >> There's been a fair amount of discussion of the drop SPF part of this >> proposal, but I think less about the question of version bumps. I'm going >> back to the top of the thread to focus on that. >> >> I don't think there's much precedent for version bumps being successful in >> any reasonable time frame. How long did it take to transition from SMTP to >> ESMTP? Is it done yet? Absent IPv4 address exhaustion, how many more >> decades would it have taken for IPv6 deployment to take off? SSL/TLS is >> the best example I can think of, but even that, where there are very strong >> security and privacy incentives, has been too slow and very painful. We >> have nothing like that level incentive for people to support an >> incompatible break between non-IETF DMARC and IETF DMARC. >> >> Technically, it's a new protocol. There's no technical difference between >> saying records now have to start with v=DMARC2 and they have to start with >> v=NOTDMARC. It's a decision to abandon all existing deployments and start >> over. >> >> What's the incentive that any existing DMARC users (senders or receivers) >> would have to invest additional resources in another email authentication >> protocol? My expectation is that if the IETF decides to bump the version, >> very little deployment of the IETF variant. "The IETF says this one is >> better" doesn't move budgets in any meaningful way. >> >> My suggestion is that if we determine that a change requires a version >> bump, out response should be to not make that change instead. >> >> For clarity, I don't think the tree walk should drive a version bump (and >> we already went over that, let's resist the temptation to do it again), but >> if it did, then I would rather stay with the PSL. >> >> Please, no version bumps. >> >> 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] Version bump: was DMARC2 & SPF Dependency Removal
I'd rather add an option to flag some behavior rather than do a version bump. Have to agree with Scott that version bumps take forever. (I had a network engineer recently tell me that DNS packets *MUST* be no larger than 512 bytes - and EDNS0 was 1999?) tim On Sat, Jun 10, 2023 at 3:03 PM Scott Kitterman wrote: > > > On June 8, 2023 12:58:51 PM UTC, Tobias Herkula 401und1...@dmarc.ietf.org> wrote: > ... > > > >However, such a fundamental shift in the protocol's architecture warrants > a clear signifier. I suggest we upgrade our DMARC version string from the > current state to 'DMARC2.' This upgrade would not only denote the change of > SPF removal, but also the switch from the Public Suffix List (PSL) to the > Tree-Walk algorithm. > > > >By moving towards DMARC2, we not only update our standard to better > reflect our present requirements, but we also make a clear commitment to > the ongoing evolution and improvement of the protocol. > > > There's been a fair amount of discussion of the drop SPF part of this > proposal, but I think less about the question of version bumps. I'm going > back to the top of the thread to focus on that. > > I don't think there's much precedent for version bumps being successful in > any reasonable time frame. How long did it take to transition from SMTP to > ESMTP? Is it done yet? Absent IPv4 address exhaustion, how many more > decades would it have taken for IPv6 deployment to take off? SSL/TLS is > the best example I can think of, but even that, where there are very strong > security and privacy incentives, has been too slow and very painful. We > have nothing like that level incentive for people to support an > incompatible break between non-IETF DMARC and IETF DMARC. > > Technically, it's a new protocol. There's no technical difference between > saying records now have to start with v=DMARC2 and they have to start with > v=NOTDMARC. It's a decision to abandon all existing deployments and start > over. > > What's the incentive that any existing DMARC users (senders or receivers) > would have to invest additional resources in another email authentication > protocol? My expectation is that if the IETF decides to bump the version, > very little deployment of the IETF variant. "The IETF says this one is > better" doesn't move budgets in any meaningful way. > > My suggestion is that if we determine that a change requires a version > bump, out response should be to not make that change instead. > > For clarity, I don't think the tree walk should drive a version bump (and > we already went over that, let's resist the temptation to do it again), but > if it did, then I would rather stay with the PSL. > > Please, no version bumps. > > 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-ietf] Version bump: was DMARC2 & SPF Dependency Removal
On June 8, 2023 12:58:51 PM UTC, Tobias Herkula wrote: ... > >However, such a fundamental shift in the protocol's architecture warrants a >clear signifier. I suggest we upgrade our DMARC version string from the >current state to 'DMARC2.' This upgrade would not only denote the change of >SPF removal, but also the switch from the Public Suffix List (PSL) to the >Tree-Walk algorithm. > >By moving towards DMARC2, we not only update our standard to better reflect >our present requirements, but we also make a clear commitment to the ongoing >evolution and improvement of the protocol. There's been a fair amount of discussion of the drop SPF part of this proposal, but I think less about the question of version bumps. I'm going back to the top of the thread to focus on that. I don't think there's much precedent for version bumps being successful in any reasonable time frame. How long did it take to transition from SMTP to ESMTP? Is it done yet? Absent IPv4 address exhaustion, how many more decades would it have taken for IPv6 deployment to take off? SSL/TLS is the best example I can think of, but even that, where there are very strong security and privacy incentives, has been too slow and very painful. We have nothing like that level incentive for people to support an incompatible break between non-IETF DMARC and IETF DMARC. Technically, it's a new protocol. There's no technical difference between saying records now have to start with v=DMARC2 and they have to start with v=NOTDMARC. It's a decision to abandon all existing deployments and start over. What's the incentive that any existing DMARC users (senders or receivers) would have to invest additional resources in another email authentication protocol? My expectation is that if the IETF decides to bump the version, very little deployment of the IETF variant. "The IETF says this one is better" doesn't move budgets in any meaningful way. My suggestion is that if we determine that a change requires a version bump, out response should be to not make that change instead. For clarity, I don't think the tree walk should drive a version bump (and we already went over that, let's resist the temptation to do it again), but if it did, then I would rather stay with the PSL. Please, no version bumps. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Errors in the tree walk, was version bump to DMARC2
On Sat 10/Jun/2023 01:26:18 +0200 Emil Gustafsson wrote: Without a version change for the tree-walk, I think we (Google) would need to support both approaches (the old one plus the tree-walk) and based on what we see - make a best guess which version we should use. I haven't coded the tree walk yet, but I'm thinking to do the same. Having two explicit versions still means we have two implementations, but at least we don't have to guess which one to use whenever there would be ambiguity with a single version. Why two versions? Tree walk can be supported while still checking it against the PSL in the same version of the verifier. One point, for example is the lack of psd=y tags in the critical domains. In this respect, I propose to report the most striking configuration errors in DMARC aggregate reports. In fact, RFCs 6651 and 6652 have seen very little adoption; ruf= a little bit more, but still much less than DMARC aggregate reports. Errors like missing psd=, invalid SPF record, invalid or missing DKIM record, and similar could be added in the report header, e.g. after , in case relevant errors are seen. Maybe that could improve settings... Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
On Fri 09/Jun/2023 17:33:16 +0200 Scott Kitterman wrote: You may not think that last half of a percent is important (my recollection is that it varied a bit between 0.2% and 0.8%), but I think it exists and is important. I only keep one month worth of DKIM and SPF results, and got 0.52% on it right now, featuring large an small companies. Surely they must be misconfigured... Two names are twitter.com and gnupg.org. The latter cannot be said to be crypto-ignorant. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
