Re: [dmarc-ietf] p=interoperability p=compliance p=orgname:policyname
Please, no. This WG has already run a year past its sell-by date. Stuff like this will just tell the world that we'll never finish. Apologies. I wasn't trying to disrupt dmarcbis finishing. Ever since I saw consensus start to form, I started citing dmarcbis whenever explaining how DMARC works (or should work) to people who need to know. Most are still relying on the original language/assumptions as the basis for their knowledge, so there are going to be questions to answer and operational practices to think about during the transition period (forever). Is there a better place to discuss future topics like this? We've talked about an application statement that suggests how best to use DMARC. But there's a giant installed base, and we would need an extremely good reason to make an incompatible change at this point. We spent months debating the tree walk and establishing that in nearly every case the answers will be the same as now, or if different, no worse, so we figured that was a change that we could get away with. 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] p=interoperability p=compliance p=orgname:policyname
On Wed, Aug 23, 2023, at 11:11 AM, John Levine wrote: > It appears that Jesse Thompson said: > >I'm beginning to think that a solution to this problem is "other channels" > > > >Let's discuss p=interoperability, p=compliance, or p=orgname:policyname > > Please, no. This WG has already run a year past its sell-by date. Stuff > like this will just tell the world that we'll never finish. Apologies. I wasn't trying to disrupt dmarcbis finishing. Ever since I saw consensus start to form, I started citing dmarcbis whenever explaining how DMARC works (or should work) to people who need to know. Most are still relying on the original language/assumptions as the basis for their knowledge, so there are going to be questions to answer and operational practices to think about during the transition period (forever). Is there a better place to discuss future topics like this? Jesse___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=interoperability p=compliance p=orgname:policyname
We have many considerations and if we “are [near] finish” then please publish a new draft to see where are at. With so many unknowns, its fertilizes uncertainty, “desperate questions” and ignored suggestions and proposals. I believe an update is warranted. All the best, Hector Santos > On Aug 23, 2023, at 4:10 PM, Barry Leiba wrote: > > Apart from "never finish", I would contend that changes of that nature > violate the "preserve interoperability with the installed base of > DMARC systems" clause of our charter. We *can* make changes such as > this if we have a reason that's compelling enough, but as we talk > about changing the strings that we use for "p=", the arguments are > more cosmetic than truly functional, and I certainly don't see them as > compelling. > > Barry > > On Wed, Aug 23, 2023 at 12:11 PM John Levine wrote: >> >> It appears that Jesse Thompson said: >>> I'm beginning to think that a solution to this problem is "other channels" >>> >>> Let's discuss p=interoperability, p=compliance, or p=orgname:policyname >> >> Please, no. This WG has already run a year past its sell-by date. Stuff >> like this will just tell the world that we'll never finish. >> >> R's, >> John >> >> ___ >> 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] p=interoperability p=compliance p=orgname:policyname
Apart from "never finish", I would contend that changes of that nature violate the "preserve interoperability with the installed base of DMARC systems" clause of our charter. We *can* make changes such as this if we have a reason that's compelling enough, but as we talk about changing the strings that we use for "p=", the arguments are more cosmetic than truly functional, and I certainly don't see them as compelling. Barry On Wed, Aug 23, 2023 at 12:11 PM John Levine wrote: > > It appears that Jesse Thompson said: > >I'm beginning to think that a solution to this problem is "other channels" > > > >Let's discuss p=interoperability, p=compliance, or p=orgname:policyname > > Please, no. This WG has already run a year past its sell-by date. Stuff > like this will just tell the world that we'll never finish. > > R's, > John > > ___ > 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] p=interoperability p=compliance p=orgname:policyname
It appears that Jesse Thompson said: >I'm beginning to think that a solution to this problem is "other channels" > >Let's discuss p=interoperability, p=compliance, or p=orgname:policyname Please, no. This WG has already run a year past its sell-by date. Stuff like this will just tell the world that we'll never finish. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=interoperability p=compliance p=orgname:policyname
p=reject has two effects: - It makes impersonation attacks less likely to be successful, and - It encourages attackers to chose other domains for impersonation, since attacks on protected domains are more likely to fail. Therefore, evaluators should expect that most attacks will occur against non-enforcing domains, because: - Non-enforcing domains are the lion's share of all incoming messages, and - Attacks on these domains are more attractive because they are more likely to succeed. Consequently, an evaluator who only worries about p=reject is probably ignoring most of his incoming attacks. Given that the mailing list problem is only described as a problem for p=reject domains, I conclude that an important segment of evaluators are ignoring the largest portion of impersonation attacks. The appropriate security posture is to assume that any unauthenticated message may be an impersonation attack, and risk reduction requires that such messages be studied. Unacceptable messages need an unconditional block rule, and acceptable message need an alternate authentication rule. Those who are unwilling to investigate unauthenticated messages will remain vulnerable to deception. I don't know that obtaining different information from the domain owner will fix this. Doug Fosster On Tue, Aug 22, 2023 at 11:40 PM Jesse Thompson wrote: > On Mon, Jul 24, 2023, at 1:03 PM, Neil Anuskiewicz wrote: > > > > > On Jul 19, 2023, at 3:21 PM, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > > > > > > Perhaps you can clarify what you think DMARC is. > > > > Apparently a significant number of evaluators think that "DMARC Fail > with p=reject always means unwanted mail". Or to use Michael Hammer's > language, "DMARC Fail with p=reject means the domain owner wants it > rejected so I will reject it."These are exactly the attitudes that > cause us so much trouble because (a) DMARC Fail with p=reject does not mean > that rejection is always the correct response, and (b) DMARC Fail with > p=none is an important piece of information. > > Doug, if what you’re saying is true then the root cause might be our > fault. If we’ve not communicated clearly enough DMARC’s purpose. A > communication problem likely needs to be solved with more and better > communication via the standards doc itself and other channels. > > > (again, apologies if already suggested, still working my way through the > backlog in my spare time) > > I'm beginning to think that a solution to this problem is "other channels" > > Let's discuss p=interoperability, p=compliance, or p=orgname:policyname > > "By the book" receivers who see an "invalid" policy will treat it no > differently than p=none, and intermediaries will not bother trying to > munge. So, it is achieving the interoperability objectives of IETF > > "Smart" receivers will see that the policy is a reference to a policy > definition that can be queried in some standard fashion. The policy owner > can articulate clearly what the policy means. > > IETF should not be in the business of describing the mail handling > policies that exist in practice or any that will emerge, but should define > how those policies are communicated (for interoperability sake). > > Domain owners interested in achieving compliance will gravitate towards > p=compliance over p=reject (because compliance is what they are trying to > achieve), or they may choose to define their own p=orgname:policyname > namespace if they want to get more specific in describing their intended > mail flows > > Those that wish to express backwards compatibility can use > p=interoperability or a p=orgname:policyname namespace that expresses > policy in some other way > > Jesse > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] p=interoperability p=compliance p=orgname:policyname
On Mon, Jul 24, 2023, at 1:03 PM, Neil Anuskiewicz wrote: > > > > On Jul 19, 2023, at 3:21 PM, Douglas Foster > > wrote: > > > > > > Perhaps you can clarify what you think DMARC is. > > > > Apparently a significant number of evaluators think that "DMARC Fail with > > p=reject always means unwanted mail". Or to use Michael Hammer's > > language, "DMARC Fail with p=reject means the domain owner wants it > > rejected so I will reject it."These are exactly the attitudes that > > cause us so much trouble because (a) DMARC Fail with p=reject does not mean > > that rejection is always the correct response, and (b) DMARC Fail with > > p=none is an important piece of information. > > Doug, if what you’re saying is true then the root cause might be our fault. > If we’ve not communicated clearly enough DMARC’s purpose. A communication > problem likely needs to be solved with more and better communication via the > standards doc itself and other channels. > (again, apologies if already suggested, still working my way through the backlog in my spare time) I'm beginning to think that a solution to this problem is "other channels" Let's discuss p=interoperability, p=compliance, or p=orgname:policyname "By the book" receivers who see an "invalid" policy will treat it no differently than p=none, and intermediaries will not bother trying to munge. So, it is achieving the interoperability objectives of IETF "Smart" receivers will see that the policy is a reference to a policy definition that can be queried in some standard fashion. The policy owner can articulate clearly what the policy means. IETF should not be in the business of describing the mail handling policies that exist in practice or any that will emerge, but should define how those policies are communicated (for interoperability sake). Domain owners interested in achieving compliance will gravitate towards p=compliance over p=reject (because compliance is what they are trying to achieve), or they may choose to define their own p=orgname:policyname namespace if they want to get more specific in describing their intended mail flows Those that wish to express backwards compatibility can use p=interoperability or a p=orgname:policyname namespace that expresses policy in some other way Jesse___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
