Re: [dmarc-ietf] PSD flag vs Version bump
> What if MIME-Version changed on every new MIME type? (I presume you mean "subtype", as we've only defined two new media types: example (RFC 4735) and font (RFC 8081).) This is a red herring, as MIME was specifically designed to be extensible by adding new media types and subtypes, as well as parameters, charsets, and the like. We aren't talking about an extension here, but a change to the basic mechanism of the protocol. We decided that the change from PSD to tree walk was sufficiently compatible that it's OK without a version change. Removing SPF validation is a less compatible change to the protocol, and it makes it a different discussion. Best to avoid analogies: most of them fail and are only distracting. Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] PSD flag vs Version bump
On Sun 11/Jun/2023 00:32:01 +0200 Richard Clayton wrote: 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. Among changes, besides the tree walk, we have ed25519 and t=. Compatibility seems to be much more at stake with the latter ones than with the former. In fact, if you sign with (only) ed25519, many receivers won't verify. If you use pct=5, like some do, you may be off for some harsh surprises. In contrast, if your record is found by walking the tree rather than looking up the PSL, most likely you won't even notice. We don't need psd=u's, except if we're drawing statistics. New tags can be added also after DMARCbis is out. There is a registry already: https://www.iana.org/assignments/dmarc-parameters/dmarc-parameters.xhtml#tag Not all receivers recognize every tag. There was a project to syntactically denote tags that cannot be ignored, and it was abandoned (also) because it required a version bump. Conserving the installed base is important. 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. What if MIME-Version changed on every new MIME type? We'd be running n systems in parallel, with n -> ∞. Introducing a new system, however simpler, would divide the users community, rather than unite them. https://xkcd.com/927/ Best Ale -- ___ 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
