Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Friday, April 28, 2023 3:57:55 AM EDT Alessandro Vesely wrote: > On Fri 28/Apr/2023 05:14:16 +0200 Jesse Thompson wrote: > > On Thu, Apr 27, 2023, at 9:54 PM, Scott Kitterman wrote: > >> On April 28, 2023 2:49:48 AM UTC, Jesse Thompson wrote: > >>>On Thu, Apr 27, 2023, at 9:40 PM, Jesse Thompson wrote: > On Thu, Apr 27, 2023, at 10:44 AM, Alessandro Vesely wrote: > > Also, state that serious consideration includes testing p=quarantine; > > pct=0^H t=y. > I was going to say something similar but I think that it is implied by > section A.7>>> > >>>Actually, I like referencing A.7 here as a pointer. > >>> > >>>This achieves consensus on the rewrite objection. > >>> > >>>A.7 describes the rewrite without condoning it: > >>>[citation elided] > > Good note. I think it's called /lapsus calami/ when one ends up writing > something which wasn't supposed to be uttered. "The phenomena can be traced > back to incompletely suppressed psychical material, which, although pushed > away by consciousness, has nevertheless not been robbed of all capacity for > expressing itself" to cite Freud. > > >> I think we can describe what people are doing without placing a strong > >> value judgement on it, but I think we have to say we haven't assessed > >> all the associated interoperability impacts of it and at least mention > >> that 5321 says not to do it.> > > Restricting the "MUST NOT" to the context of 5321 achieves consensus, I > > think > RFC 5321 is not normative on that point. Section 3.9 says MLMs MUST change > the bounce address and SHOULD simply use the list. That's the only mustard > in the section. Changes to the header and the body are certainly not > encouraged, but the section ends saying: > > There exist mailing lists that perform additional, sometimes > extensive, modifications to a message and its envelope. Such mailing > lists need to be viewed as full MUAs, which accept a delivery and > post a new message. > > Now, *every* MUA I know rewrites From: when the user forwards a message. We've gone pretty far past where I was planning to go with this particular thread, so I'll leave this with two points: 1. MUA forwarding of a message is not a mailing list. 2. Read the main part of 3.9, not the sub-paragraph. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Thu 27/Apr/2023 22:49:31 +0200 Scott Kitterman wrote: On April 27, 2023 4:02:32 PM UTC, Alessandro Vesely wrote: On Wed 26/Apr/2023 13:21:33 +0200 Scott Kitterman wrote: On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely wrote: On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote: My recollection is that a general formulation that I proposed had at least some traction out of both groups: [some appropriate description] domains MUST NOT publish restrictive DMARC policies due to interoperability issues Leaving aside (for now) the question of what goes into [some appropriate description] and with the assumption that there will be some non-normative discussion to amplify whatever that is and probably give some indication about what domains might do to not be one of those domains, is there anyone who just can't live with that formulation of the situation? Me, for one. Because more than 98% of domains are going to fall into the description, however we word it, that statement makes the whole I-D nonsensical. Cannot we just tell the problem without MUSTard? In any case, using the complement of [some appropriate description] is certainly easier. For example: Forcing authentication into Internet mail by publishing restrictive DMARC policies breaks some well established patterns of usage. Publishing such policies is thus RECOMMENDED only for domains [in this other appropriate description]. Thanks. I understand your objection to be that the proposed description of the interoperability problems would apply to too many domains, regardless of the modifier we might use. Is that correct? Nearly. Too many would be 40%. 98% is practically all. Indeed, we're talking of mailboxes used by humans... I don't understand the technical issue associated with that objection. I get that you feel the construction is too negative, but I don't have a sense you think it's inaccurate. Focusing on the technical aspects of this, would you please help me understand what you think is technically incorrect about it? Perhaps MUST NOT would have some sense if DMARC were breaking a well known protocol. The established patterns of usage we break are in turn breaking some other RFCs, aren't they? Why would the applied workaround have less merit than the original hack, from a formal POV? I mean, if we stand by the letter of the protocols so much as to feel the need to say MUST NOT. If we think internet standards are meaningful, then if the applied work around directly conflicts with an internet standard (which From rewriting does: RFC 5321 and predecessors), then it he as substantially less merit. My recollection is that mailing lists were never standardized. They arose as a local-scoped alternative to Usenet, piggybacked on SMTP, following methods and traditions derived from common sense and convenience. The onset of From: rewriting is the latest step in their evolution, which testifies for their flexibility. From a user's perspective, From: rewriting in no way an improvement. Semantically, it poses the questions of authorship and identity of individuals with respect to the community. To the extent that DMARC marks a turning point in the email landscape, From: rewriting can be considered like sparks flying from the tire rim if the curve is too sharp. It'll settle eventually. Otherwise, we can try to stick to tradition and condemn DMARC, refusing to acknowledge the need for human authentication that seems to emerge. Why? To honor a tradition? To respect a standard that was never issued? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Fri 28/Apr/2023 05:14:16 +0200 Jesse Thompson wrote: On Thu, Apr 27, 2023, at 9:54 PM, Scott Kitterman wrote: On April 28, 2023 2:49:48 AM UTC, Jesse Thompson wrote: On Thu, Apr 27, 2023, at 9:40 PM, Jesse Thompson wrote: On Thu, Apr 27, 2023, at 10:44 AM, Alessandro Vesely wrote: Also, state that serious consideration includes testing p=quarantine; pct=0^H t=y. I was going to say something similar but I think that it is implied by section A.7 Actually, I like referencing A.7 here as a pointer. This achieves consensus on the rewrite objection. A.7 describes the rewrite without condoning it: [citation elided] Good note. I think it's called /lapsus calami/ when one ends up writing something which wasn't supposed to be uttered. "The phenomena can be traced back to incompletely suppressed psychical material, which, although pushed away by consciousness, has nevertheless not been robbed of all capacity for expressing itself" to cite Freud. I think we can describe what people are doing without placing a strong value judgement on it, but I think we have to say we haven't assessed all the associated interoperability impacts of it and at least mention that 5321 says not to do it. Restricting the "MUST NOT" to the context of 5321 achieves consensus, I think RFC 5321 is not normative on that point. Section 3.9 says MLMs MUST change the bounce address and SHOULD simply use the list. That's the only mustard in the section. Changes to the header and the body are certainly not encouraged, but the section ends saying: There exist mailing lists that perform additional, sometimes extensive, modifications to a message and its envelope. Such mailing lists need to be viewed as full MUAs, which accept a delivery and post a new message. Now, *every* MUA I know rewrites From: when the user forwards a message. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Thu, Apr 27, 2023, at 9:54 PM, Scott Kitterman wrote: > > > On April 28, 2023 2:49:48 AM UTC, Jesse Thompson wrote: > >On Thu, Apr 27, 2023, at 9:40 PM, Jesse Thompson wrote: > >> On Thu, Apr 27, 2023, at 10:44 AM, Alessandro Vesely wrote: > >>> Also, state that serious consideration includes testing p=quarantine; > >>> pct=0^H t=y. > >> > >> I was going to say something similar but I think that it is implied by > >> section A.7 > > > >Actually, I like referencing A.7 here as a pointer. > > > >This achieves consensus on the rewrite objection. > > > >A.7 describes the rewrite without condoning it: > > > > Operational experience showed ... > > ... header rewriting by an > > intermediary meant that a Domain Owner's aggregate reports could > > reveal to the Domain Owner how much of its traffic was routing > > through intermediaries that don't rewrite the RFC5322.From header > > I think we can describe what people are doing without placing a strong value > judgement on it, but I think we have to say we haven't assessed all the > associated interoperability impacts of it and at least mention that 5321 says > not to do it. Restricting the "MUST NOT" to the context of 5321 achieves consensus, I think Jesse___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Thu, Apr 27, 2023, at 9:52 PM, Scott Kitterman wrote: > > > On April 28, 2023 2:25:57 AM UTC, Jesse Thompson wrote: > >On Thu, Apr 27, 2023, at 9:30 AM, Brotman, Alex wrote: > >> Attempt to make it a tad more concise (I think), altering some of the > >> language: > >> > >> - > >> There can be inherent damage to the ability to use certain SMTP-based > >> systems in conjunction with a policy of quarantine or reject. These could > >> include, though are not limited to, mailing lists, forwarding services, > >> and other types of indirect mail flows. Especially in situations where > >> the sending domain is SPF-only, or the intermediary is known to alter > >> messages. If the users of the domain may utilize these types of systems, > >> the domain administrator MUST NOT deploy a policy of quarantine or reject > >> without serious considerations to the impact to interoperability. These > >> considerations will be informed by careful analysis of DMARC aggregate > >> reports prior to deploying such a policy. Some third-party systems may be > >> willing to create a workaround for these situations, though it cannot be > >> guaranteed. Domain owners MAY choose to create a sub-domain > >> (listmail.example.org) or cousin domain (listmail-example.org) which uses > >> a different policy for users wishing to utilize those service > s. > >> - > > > >I like this, and it gives room for best common practices to evolve that > >don't necessarily conflict. > > > >s/ > >Especially in situations where the sending domain is SPF-only, or the > > intermediary is known to alter messages. If the users of the domain may > > utilize these types of systems, the domain administrator MUST NOT deploy > >/ > >For situations where the sending domain is not DKIM signing all of its > > traffic in an aligned fashion or there is legitimate use of an intermediary > > known to alter messages, the domain administrator MUST NOT deploy > >/x > > I think most of this would be good in a non-normative appendix. For my > immediate purpose, I'm imagining that in addition to the [adjective] domain, > there would need to be an amplification of [adjective] that would explain > exactly what we mean by [adjective] and what actions a domain owner might > take in order to be [not adjective]. > > I don't think it's formally part of the protocol, but it's quite important. +1___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On April 28, 2023 2:49:48 AM UTC, Jesse Thompson wrote: >On Thu, Apr 27, 2023, at 9:40 PM, Jesse Thompson wrote: >> On Thu, Apr 27, 2023, at 10:44 AM, Alessandro Vesely wrote: >>> Also, state that serious consideration includes testing p=quarantine; >>> pct=0^H t=y. >> >> I was going to say something similar but I think that it is implied by >> section A.7 > >Actually, I like referencing A.7 here as a pointer. > >This achieves consensus on the rewrite objection. > >A.7 describes the rewrite without condoning it: > > Operational experience showed ... > ... header rewriting by an > intermediary meant that a Domain Owner's aggregate reports could > reveal to the Domain Owner how much of its traffic was routing > through intermediaries that don't rewrite the RFC5322.From header I think we can describe what people are doing without placing a strong value judgement on it, but I think we have to say we haven't assessed all the associated interoperability impacts of it and at least mention that 5321 says not to do it. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On April 28, 2023 2:25:57 AM UTC, Jesse Thompson wrote: >On Thu, Apr 27, 2023, at 9:30 AM, Brotman, Alex wrote: >> Attempt to make it a tad more concise (I think), altering some of the >> language: >> >> - >> There can be inherent damage to the ability to use certain SMTP-based >> systems in conjunction with a policy of quarantine or reject. These could >> include, though are not limited to, mailing lists, forwarding services, and >> other types of indirect mail flows. Especially in situations where the >> sending domain is SPF-only, or the intermediary is known to alter messages. >> If the users of the domain may utilize these types of systems, the domain >> administrator MUST NOT deploy a policy of quarantine or reject without >> serious considerations to the impact to interoperability. These >> considerations will be informed by careful analysis of DMARC aggregate >> reports prior to deploying such a policy. Some third-party systems may be >> willing to create a workaround for these situations, though it cannot be >> guaranteed. Domain owners MAY choose to create a sub-domain >> (listmail.example.org) or cousin domain (listmail-example.org) which uses a >> different policy for users wishing to utilize those service s. >> - > >I like this, and it gives room for best common practices to evolve that don't >necessarily conflict. > >s/ >Especially in situations where the sending domain is SPF-only, or the > intermediary is known to alter messages. If the users of the domain may > utilize these types of systems, the domain administrator MUST NOT deploy >/ >For situations where the sending domain is not DKIM signing all of its > traffic in an aligned fashion or there is legitimate use of an intermediary > known to alter messages, the domain administrator MUST NOT deploy >/x I think most of this would be good in a non-normative appendix. For my immediate purpose, I'm imagining that in addition to the [adjective] domain, there would need to be an amplification of [adjective] that would explain exactly what we mean by [adjective] and what actions a domain owner might take in order to be [not adjective]. I don't think it's formally part of the protocol, but it's quite important. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Thu, Apr 27, 2023, at 9:40 PM, Jesse Thompson wrote: > On Thu, Apr 27, 2023, at 10:44 AM, Alessandro Vesely wrote: >> Also, state that serious consideration includes testing p=quarantine; >> pct=0^H t=y. > > I was going to say something similar but I think that it is implied by > section A.7 Actually, I like referencing A.7 here as a pointer. This achieves consensus on the rewrite objection. A.7 describes the rewrite without condoning it: Operational experience showed ... ... header rewriting by an intermediary meant that a Domain Owner's aggregate reports could reveal to the Domain Owner how much of its traffic was routing through intermediaries that don't rewrite the RFC5322.From header ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Thu, Apr 27, 2023, at 10:44 AM, Alessandro Vesely wrote: > Also, state that serious consideration includes testing p=quarantine; pct=0^H > t=y. I was going to say something similar but I think that it is implied by section A.7 Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Thu, Apr 27, 2023, at 9:30 AM, Brotman, Alex wrote: > Attempt to make it a tad more concise (I think), altering some of the > language: > > - > There can be inherent damage to the ability to use certain SMTP-based systems > in conjunction with a policy of quarantine or reject. These could include, > though are not limited to, mailing lists, forwarding services, and other > types of indirect mail flows. Especially in situations where the sending > domain is SPF-only, or the intermediary is known to alter messages. If the > users of the domain may utilize these types of systems, the domain > administrator MUST NOT deploy a policy of quarantine or reject without > serious considerations to the impact to interoperability. These > considerations will be informed by careful analysis of DMARC aggregate > reports prior to deploying such a policy. Some third-party systems may be > willing to create a workaround for these situations, though it cannot be > guaranteed. Domain owners MAY choose to create a sub-domain > (listmail.example.org) or cousin domain (listmail-example.org) which uses a > different policy for users wishing to utilize those services. > - I like this, and it gives room for best common practices to evolve that don't necessarily conflict. s/ Especially in situations where the sending domain is SPF-only, or the intermediary is known to alter messages. If the users of the domain may utilize these types of systems, the domain administrator MUST NOT deploy / For situations where the sending domain is not DKIM signing all of its traffic in an aligned fashion or there is legitimate use of an intermediary known to alter messages, the domain administrator MUST NOT deploy /x Jesse___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On April 27, 2023 4:02:32 PM UTC, Alessandro Vesely wrote: >On Wed 26/Apr/2023 13:21:33 +0200 Scott Kitterman wrote: >> On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely wrote: >>> On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote: My recollection is that a general formulation that I proposed had at least some traction out of both groups: > [some appropriate description] domains MUST NOT publish restrictive DMARC > policies due to interoperability issues Leaving aside (for now) the question of what goes into [some appropriate description] and with the assumption that there will be some non-normative discussion to amplify whatever that is and probably give some indication about what domains might do to not be one of those domains, is there anyone who just can't live with that formulation of the situation? >>> >>> Me, for one. Because more than 98% of domains are going to fall into the >>> description, however we word it, that statement makes the whole I-D >>> nonsensical. Cannot we just tell the problem without MUSTard? >>> >>> In any case, using the complement of [some appropriate description] is >>> certainly easier. For example: >>> >>>Forcing authentication into Internet mail by publishing restrictive DMARC >>>policies breaks some well established patterns of usage. Publishing such >>>policies is thus RECOMMENDED only for domains [in this other appropriate >>>description]. >> >> Thanks. >> >> I understand your objection to be that the proposed description of the >> interoperability problems would apply to too many domains, regardless of the >> modifier we might use. Is that correct? > > >Nearly. Too many would be 40%. 98% is practically all. Indeed, we're >talking of mailboxes used by humans... > > >> I don't understand the technical issue associated with that objection. I >> get that you feel the construction is too negative, but I don't have a sense >> you think it's inaccurate. Focusing on the technical aspects of this, would >> you please help me understand what you think is technically incorrect about >> it? > > >Perhaps MUST NOT would have some sense if DMARC were breaking a well known >protocol. The established patterns of usage we break are in turn breaking >some other RFCs, aren't they? > >Why would the applied workaround have less merit than the original hack, from >a formal POV? I mean, if we stand by the letter of the protocols so much as >to feel the need to say MUST NOT. > If we think internet standards are meaningful, then if the applied work around directly conflicts with an internet standard (which From rewriting does: RFC 5321 and predecessors), then it he as substantially less merit. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Wed 26/Apr/2023 13:21:33 +0200 Scott Kitterman wrote: On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely wrote: On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote: My recollection is that a general formulation that I proposed had at least some traction out of both groups: [some appropriate description] domains MUST NOT publish restrictive DMARC policies due to interoperability issues Leaving aside (for now) the question of what goes into [some appropriate description] and with the assumption that there will be some non-normative discussion to amplify whatever that is and probably give some indication about what domains might do to not be one of those domains, is there anyone who just can't live with that formulation of the situation? Me, for one. Because more than 98% of domains are going to fall into the description, however we word it, that statement makes the whole I-D nonsensical. Cannot we just tell the problem without MUSTard? In any case, using the complement of [some appropriate description] is certainly easier. For example: Forcing authentication into Internet mail by publishing restrictive DMARC policies breaks some well established patterns of usage. Publishing such policies is thus RECOMMENDED only for domains [in this other appropriate description]. Thanks. I understand your objection to be that the proposed description of the interoperability problems would apply to too many domains, regardless of the modifier we might use. Is that correct? Nearly. Too many would be 40%. 98% is practically all. Indeed, we're talking of mailboxes used by humans... I don't understand the technical issue associated with that objection. I get that you feel the construction is too negative, but I don't have a sense you think it's inaccurate. Focusing on the technical aspects of this, would you please help me understand what you think is technically incorrect about it? Perhaps MUST NOT would have some sense if DMARC were breaking a well known protocol. The established patterns of usage we break are in turn breaking some other RFCs, aren't they? Why would the applied workaround have less merit than the original hack, from a formal POV? I mean, if we stand by the letter of the protocols so much as to feel the need to say MUST NOT. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Thu 27/Apr/2023 16:30:14 +0200 Brotman, Alex wrote: Attempt to make it a tad more concise (I think), altering some of the language: - There can be inherent damage to the ability to use certain SMTP-based systems in conjunction with a policy of quarantine or reject. These could include, though are not limited to, mailing lists, forwarding services, and other types of indirect mail flows. Especially in situations where the sending domain is SPF-only, or the intermediary is known to alter messages. If the users of the domain may utilize these types of systems, the domain administrator MUST NOT deploy a policy of quarantine or reject without serious considerations to the impact to interoperability. These considerations will be informed by careful analysis of DMARC aggregate reports prior to deploying such a policy. Some third-party systems may be willing to create a workaround for these situations, though it cannot be guaranteed. Domain owners MAY choose to create a sub-domain (listmail.example.org) or cousin domain (listmail-example.org) which uses a different policy for users wishing to utilize those services . - I like this kind of text. I'd still s/MUST NOT/must not/. Also, state that serious consideration includes testing p=quarantine; pct=0^H t=y. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
Attempt to make it a tad more concise (I think), altering some of the language: - There can be inherent damage to the ability to use certain SMTP-based systems in conjunction with a policy of quarantine or reject. These could include, though are not limited to, mailing lists, forwarding services, and other types of indirect mail flows. Especially in situations where the sending domain is SPF-only, or the intermediary is known to alter messages. If the users of the domain may utilize these types of systems, the domain administrator MUST NOT deploy a policy of quarantine or reject without serious considerations to the impact to interoperability. These considerations will be informed by careful analysis of DMARC aggregate reports prior to deploying such a policy. Some third-party systems may be willing to create a workaround for these situations, though it cannot be guaranteed. Domain owners MAY choose to create a sub-domain (listmail.example.org) or cousin domain (listmail-example.org) which uses a different policy for users wishing to utilize those services. - If you're looking for me, I'm standing behind the firewall. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -Original Message- > From: dmarc On Behalf Of Scott Kitterman > Sent: Thursday, April 27, 2023 1:07 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Search for some consensus, was: Proposed text for > p=reject and indirect mail flows > > > > On April 27, 2023 2:32:49 AM UTC, Jim Fenton > wrote: > >On 26 Apr 2023, at 9:06, John Levine wrote: > > > >> It seems to me there are two somewhat different kinds of DMARC > >> damange that we might separate. One is what happens on discussion > >> lists, where messages get lost and in the process unrelated > >> recipients get unsubscribed. The other is simple forwarding and > >> send-to-a-friend which gets lost but is less likely to cause problems > >> for the recipients beyond not getting the mail they want. > > > >Isn’t (in the latter case) the recipients not getting the mail they want > >exactly an > interoperability problem? > > It absolutely is. The difference, my view, is that if the domain owner has a > policy > that leads to you not getting your mail, it's a different level of severity > than you > both don't get your mail and end up unsubscribed from the mailing list. > > One might make a case that the former is "works as designed" since the sending > domain owner has published policy indicating he doesn't want you to get your > mail and your mail host has decided to honor that request (I think that's > wrong, > but I can see the logic). I don't think there's any way to claim third > party's > getting bounced from a mailing list is OK. > > Scott K > > ___ > dmarc mailing list > dmarc@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;! > !CQl3mcHX2A!HIiPwxlibmp0jYdSD3ap2XsLrLB28EJJ-xUe- > XVECMs6n5re7eRqcuXfev2ioFKD8ouqGUsAw9o76AycuD29$ ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On 4/26/2023 11:51 AM, Scott Kitterman wrote: I agree that more will be needed. Thanks for the feedback. The last run at this question ended up being a mess, so I'm trying to see if we can get further by going in small steps. Scott, I provided some suggested text below of what I think, as an implementator, to get closer to finishing this DKIM Policy project. Incremental changes is always preferred, but it has been many years with operational experiences. We know where the stepping stones are. That was the goal with ADSP as well and unfortunately the stepping stones are being ignored. So lets not ignore them anymore to we can move forward with a more protocol complete DKIM Policy model. The beauty of the IETF RFC documentation format is that its addresses a wide audience of disciplines It's a blend of all the functional, technical, security and operator's manual. But the RFC is for everyone, including management and decision makers. I think the wording for the I-D can be done to satisfy all. Look it at this another way. We really don't have a problem anymore. We know what the mitigations are. So whatever is done with the I-D, the problems as been addressed. So I suppose, its more of a clean up, a codification of what has happened with the DKIM Policy model that now comes under the umbrella of DMARC. We know what the issues are and the solutions. Why not just document this and be done. Proposed new Appendix A section. A.8 Mailing List Servers Mailing List Servers (MLS) applications who are compliant with DMARC operations, SHOULD adhere to the following guidelines to integrated DMARC. Subscription and Submission Controls MLS subscription processes should perform a DMARC check to determine if a subscribing or submission email domain DMARC policy is restrictive in regards to mail integrity changes or 3rd party signatures. The MLS SHOULD only allow subscriptions and submission from original domain policies who allow 3rd party signatures with p=none policy. Message Content Integrity Change List Servers which will alter the message content SHOULD only do so for original domains with optional DKIM signing practices. If the List Server is not going to alter the message, it SHOULD NOT remove the signature, if present. Security Tear Down The MLS SHOULD NOT change the author's security by changing the authorship address (From) domain. It should apply subscription/submission controls. However, if there circumstances where a From rewrite is necessary, ideally, a rewrite with a new address SHOULD may the same level of security as the original submission to avoid potential Replay and Display Name Attacks. Proposed updated 4.4.3 section. 4.4.3. Alignment and Extension Technologies DMARC can be extended to include the use of authentication and authorization mechanisms that assist in DMARC evaluation of policy. Any new authentication extensions will need to allow for domain identifier extraction so that alignment with the RFC5322.From domain can be verified. Authorization extensions deal with the condition when the author domain does not match the signer domain. These are called 3rd party signatures. The following Author::Signer domain authorization methods has been explored: DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures (ATPS) [https://datatracker.ietf.org/doc/html/rfc6541] Third-Party Authorization Label (TPA) [https://datatracker.ietf.org/doc/html/draft-otis-tpa-label-08] Mandatory Tags for DKIM Signatures [https://datatracker.ietf.org/doc/html/draft-levine-dkim-conditional-04] Delegating DKIM Signing Authority [https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-delegate-02] The first two are DNS-based and the latter are non-DNS-based. All have one goal - To authorize the 3rd party signature. The ATPS proposal is the simplest method and it has shown success in practice to reduce false positive failure results when a valid and unverified but ATPS authorized 3rd party signer is present in a message. MDA receivers should consider using ATPS to verify 3rd party signatures. I hope this can be a starting point for someone better than me can write for the RFC wide audience. I personally feel, we should have an ATPS section that shows the simple steps with the "atps=y" tag added to the DMARC record, the discovery method and how publishers can delegate 3rd party signers using ATPS records. The key is to get closer towards completing the DKIM-based secured mail system with 3rd party signer support as it was originally envisioned. Thanks -- Hector Santos, https://santronics.com https://winserver.com ___ dmarc mailing
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On April 27, 2023 2:32:49 AM UTC, Jim Fenton wrote: >On 26 Apr 2023, at 9:06, John Levine wrote: > >> It seems to me there are two somewhat different kinds of DMARC damange >> that we might separate. One is what happens on discussion lists, where >> messages get lost and in the process unrelated recipients get >> unsubscribed. The other is simple forwarding and send-to-a-friend >> which gets lost but is less likely to cause problems for the >> recipients beyond not getting the mail they want. > >Isn’t (in the latter case) the recipients not getting the mail they want >exactly an interoperability problem? It absolutely is. The difference, my view, is that if the domain owner has a policy that leads to you not getting your mail, it's a different level of severity than you both don't get your mail and end up unsubscribed from the mailing list. One might make a case that the former is "works as designed" since the sending domain owner has published policy indicating he doesn't want you to get your mail and your mail host has decided to honor that request (I think that's wrong, but I can see the logic). I don't think there's any way to claim third party's getting bounced from a mailing list is OK. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On 26 Apr 2023, at 9:06, John Levine wrote: > It seems to me there are two somewhat different kinds of DMARC damange > that we might separate. One is what happens on discussion lists, where > messages get lost and in the process unrelated recipients get > unsubscribed. The other is simple forwarding and send-to-a-friend > which gets lost but is less likely to cause problems for the > recipients beyond not getting the mail they want. Isn’t (in the latter case) the recipients not getting the mail they want exactly an interoperability problem? -Jim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Wed, Apr 26, 2023, at 5:47 PM, Scott Kitterman wrote: > On April 26, 2023 9:39:08 PM UTC, Jesse Thompson wrote: > >On Wed, Apr 26, 2023, at 11:06 AM, John Levine wrote: > >> It appears that Scott Kitterman said: > >> >>Domains owners who have users who individually request 3rd parties to > >> >>emit mail as an address within the domain MUST NOT publish a > >> >restrictive DMARC policy if they wish to support their users' usage of > >> >any potential 3rd party. Examples of 3rd parties include > >> >mailing lists and email service providers. These 3rd parties are not > >> >always aware of, or willing to work around, DMARC. Domain owners > >> >implementing DMARC as a means for governance by restricting the > >> >unauthorized usage of the domain MUST be aware that not all of the > >> >3rd parties will make changes to work around DMARC, resulting in > >> >interoperability issues for their users' usage of the 3rd parties. > >> >Domain owners SHOULD provide an alternative address for these users > >> >within a cousin domain or subdomain that is not directly > >> >associated with the organization's brand-associated domain that is used > >> >for marketing and transactional email that needs the security > >> >benefits of DMARC. These users MUST use an address within a domain that > >> >does not have a restrictive DMARC policy. > >> >> > >> >>(Not a troll. Not directly aware of humming (sorry, it's on my bucket > >> >>list). Hopefully, didn't touch the 3rd rail. Honestly, in good > >> >faith, representing the perspective of an extremely large domain owner, > >> >users within said policy-restricted domain, and as a 3rd > >> >party commonly used by these, and similar, users.) > >> > ... > >> >I can see what you're attempting here and I see the logic. I think the > >> >normative part would need to be about 90% shorter. > >> > >> I was going to say the same thing. > > > >I agree it is too lengthy, but wished to convey the logic. > > > > > >> > >> >I think it misses the impact on innocent bystanders. > >> > >> It seems to me there are two somewhat different kinds of DMARC damange > >> that we might separate. One is what happens on discussion lists, where > >> messages get lost and in the process unrelated recipients get > >> unsubscribed. The other is simple forwarding and send-to-a-friend > >> which gets lost but is less likely to cause problems for the > >> recipients beyond not getting the mail they want. > > > >I know you don't like talking about ESP concerns, but for the sake of > >fitting into the categorizations you state, I think that usage of ESPs falls > >into the send-to-a-friend category. Is there a better term than > >"send-to-a-friend" that is more aligned to the vast variety of use cases and > >types of customers that ESPs have grown to support? The term sounds a bit > >pejorative. Think about use cases like: digital receipts sent from point of > >sale systems via an ESP on behalf of small businesses who don't have the > >ability to delegate authorization to the entire domain (e.g. > >local-flower-s...@yahoo.com) > > > >And for the record, the ESP can either have unhappy customers due to > >rejected email, or they can do something like this (but not call it > >"rewriting") > >https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Replace_address_with_a_generic_one > > > > I don't think the categorization is specific to ESPs. > > Broadly, I think the failure modes are: > > 1. Starts authorized, breaks in transit (e.g. mailing lists) > > 2. Starts as unauthorized 3rd party and stays that way (e.g. send to a > friend) > > I don't think there is anything ESP specific in the failure modes. That assumes every mailing list authenticates its rfc5322.from authors and that every send-to-a-friend-er does not authenticate its rfc5322.from authors. This list does not. The send-to-a-friend-er I work for does. Maybe we don't want to trust the method the send-to-a-friend-er uses to authenticate its authors, and give a pass to the mailing list's method at the same time, but none of it matters since there's no way a mail receiving organization can determine if the message originated in an authorized context in either situation. To be clear, I am not laying down on the tracks on the MUST NOT issue. Consider me "humming". Yes, I'd prefer something less pejorative than "send to a friend". I'd prefer if any non-SPF/DKIM-authorized mail-emitting entity running into DMARC policies could find a nugget of advice in the spec. I'd prefer some of the other ideas I have constructively suggested in previous messages (granted, address-level authentication is wishful thinking and maybe that discussion needs a different forum). In the end, I will need to give this "how to mitigate" advice directly and I will need to explain why every domain owner is adopting DMARC for reasons other than the IETF is willing to condone. Having something to point to in the spec other
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On April 26, 2023 9:39:08 PM UTC, Jesse Thompson wrote: >On Wed, Apr 26, 2023, at 11:06 AM, John Levine wrote: >> It appears that Scott Kitterman said: >> >>Domains owners who have users who individually request 3rd parties to emit >> >>mail as an address within the domain MUST NOT publish a >> >restrictive DMARC policy if they wish to support their users' usage of any >> >potential 3rd party. Examples of 3rd parties include >> >mailing lists and email service providers. These 3rd parties are not always >> >aware of, or willing to work around, DMARC. Domain owners >> >implementing DMARC as a means for governance by restricting the >> >unauthorized usage of the domain MUST be aware that not all of the >> >3rd parties will make changes to work around DMARC, resulting in >> >interoperability issues for their users' usage of the 3rd parties. >> >Domain owners SHOULD provide an alternative address for these users within >> >a cousin domain or subdomain that is not directly >> >associated with the organization's brand-associated domain that is used for >> >marketing and transactional email that needs the security >> >benefits of DMARC. These users MUST use an address within a domain that >> >does not have a restrictive DMARC policy. >> >> >> >>(Not a troll. Not directly aware of humming (sorry, it's on my bucket >> >>list). Hopefully, didn't touch the 3rd rail. Honestly, in good >> >faith, representing the perspective of an extremely large domain owner, >> >users within said policy-restricted domain, and as a 3rd >> >party commonly used by these, and similar, users.) >> > ... >> >I can see what you're attempting here and I see the logic. I think the >> >normative part would need to be about 90% shorter. >> >> I was going to say the same thing. > >I agree it is too lengthy, but wished to convey the logic. > > >> >> >I think it misses the impact on innocent bystanders. >> >> It seems to me there are two somewhat different kinds of DMARC damange >> that we might separate. One is what happens on discussion lists, where >> messages get lost and in the process unrelated recipients get >> unsubscribed. The other is simple forwarding and send-to-a-friend >> which gets lost but is less likely to cause problems for the >> recipients beyond not getting the mail they want. > >I know you don't like talking about ESP concerns, but for the sake of fitting >into the categorizations you state, I think that usage of ESPs falls into the >send-to-a-friend category. Is there a better term than "send-to-a-friend" that >is more aligned to the vast variety of use cases and types of customers that >ESPs have grown to support? The term sounds a bit pejorative. Think about use >cases like: digital receipts sent from point of sale systems via an ESP on >behalf of small businesses who don't have the ability to delegate >authorization to the entire domain (e.g. local-flower-s...@yahoo.com) > >And for the record, the ESP can either have unhappy customers due to rejected >email, or they can do something like this (but not call it "rewriting") >https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Replace_address_with_a_generic_one > I don't think the categorization is specific to ESPs. Broadly, I think the failure modes are: 1. Starts authorized, breaks in transit (e.g. mailing lists) 2. Starts as unauthorized 3rd party and stays that way (e.g. send to a friend) I don't think there is anything ESP specific in the failure modes. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On April 26, 2023 9:52:29 PM UTC, Jesse Thompson wrote: >On Wed, Apr 26, 2023, at 6:21 AM, Scott Kitterman wrote: >> >> >> On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely wrote: >> >On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote: >> >> My recollection is that a general formulation that I proposed had at least >> >> some traction out of both groups: >> >> >> >>> [some appropriate description] domains MUST NOT publish restrictive DMARC >> >>> policies due to interoperability issues >> >> >> >> Leaving aside (for now) the question of what goes into [some appropriate >> >> description] and with the assumption that there will be some non-normative >> >> discussion to amplify whatever that is and probably give some indication >> >> about >> >> what domains might do to not be one of those domains, is there anyone who >> >> just >> >> can't live with that formulation of the situation? >> > >> > >> >Me, for one. Because more than 98% of domains are going to fall into the >> >description, however we word it, that statement makes the whole I-D >> >nonsensical. Cannot we just tell the problem without MUSTard? >> > >> >In any case, using the complement of [some appropriate description] is >> >certainly easier. For example: >> > >> >Forcing authentication into Internet mail by publishing restrictive >> > DMARC >> >policies breaks some well established patterns of usage. Publishing >> > such >> >policies is thus RECOMMENDED only for domains [in this other appropriate >> >description]. >> > >> Thanks. >> >> I understand your objection to be that the proposed description of the >> interoperability problems would apply to too many domains, regardless of the >> modifier we might use. Is that correct? > >I have a similar concern. Any domain owner with size or complexity or users >(who will do what they wanna do) will easily find their domain in a mixed-use >state, and (ironically) the only management/governance tool at the domain >owner's disposal to prevent future unintended use of the domain, in favor of >subdomains, is to publish p=quarantine|reject (throwing the baby out with the >bathwater) > Which, I think is precisely the point. "... or there will be interoperability problems ..." isn't a magic block to people doing things. If you are willing to accept the fallout, nothing is stopping you. I don't think what you describe as your concern is technical. What I understand you to be saying is it's technically correct, but you would prefer it was less obvious. I suspect that's not how you view it, but it seems to me like the fundamental concern is that if we clearly articulate the interoperability risk, people might choose not to take that risk. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Wed, Apr 26, 2023, at 6:21 AM, Scott Kitterman wrote: > > > On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely wrote: > >On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote: > >> My recollection is that a general formulation that I proposed had at least > >> some traction out of both groups: > >> > >>> [some appropriate description] domains MUST NOT publish restrictive DMARC > >>> policies due to interoperability issues > >> > >> Leaving aside (for now) the question of what goes into [some appropriate > >> description] and with the assumption that there will be some non-normative > >> discussion to amplify whatever that is and probably give some indication > >> about > >> what domains might do to not be one of those domains, is there anyone who > >> just > >> can't live with that formulation of the situation? > > > > > >Me, for one. Because more than 98% of domains are going to fall into the > >description, however we word it, that statement makes the whole I-D > >nonsensical. Cannot we just tell the problem without MUSTard? > > > >In any case, using the complement of [some appropriate description] is > >certainly easier. For example: > > > >Forcing authentication into Internet mail by publishing restrictive DMARC > >policies breaks some well established patterns of usage. Publishing such > >policies is thus RECOMMENDED only for domains [in this other appropriate > >description]. > > > Thanks. > > I understand your objection to be that the proposed description of the > interoperability problems would apply to too many domains, regardless of the > modifier we might use. Is that correct? I have a similar concern. Any domain owner with size or complexity or users (who will do what they wanna do) will easily find their domain in a mixed-use state, and (ironically) the only management/governance tool at the domain owner's disposal to prevent future unintended use of the domain, in favor of subdomains, is to publish p=quarantine|reject (throwing the baby out with the bathwater) Jesse___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Wed, Apr 26, 2023, at 11:06 AM, John Levine wrote: > It appears that Scott Kitterman said: > >>Domains owners who have users who individually request 3rd parties to emit > >>mail as an address within the domain MUST NOT publish a > >restrictive DMARC policy if they wish to support their users' usage of any > >potential 3rd party. Examples of 3rd parties include > >mailing lists and email service providers. These 3rd parties are not always > >aware of, or willing to work around, DMARC. Domain owners > >implementing DMARC as a means for governance by restricting the unauthorized > >usage of the domain MUST be aware that not all of the > >3rd parties will make changes to work around DMARC, resulting in > >interoperability issues for their users' usage of the 3rd parties. > >Domain owners SHOULD provide an alternative address for these users within a > >cousin domain or subdomain that is not directly > >associated with the organization's brand-associated domain that is used for > >marketing and transactional email that needs the security > >benefits of DMARC. These users MUST use an address within a domain that does > >not have a restrictive DMARC policy. > >> > >>(Not a troll. Not directly aware of humming (sorry, it's on my bucket > >>list). Hopefully, didn't touch the 3rd rail. Honestly, in good > >faith, representing the perspective of an extremely large domain owner, > >users within said policy-restricted domain, and as a 3rd > >party commonly used by these, and similar, users.) > > ... > >I can see what you're attempting here and I see the logic. I think the > >normative part would need to be about 90% shorter. > > I was going to say the same thing. I agree it is too lengthy, but wished to convey the logic. > > >I think it misses the impact on innocent bystanders. > > It seems to me there are two somewhat different kinds of DMARC damange > that we might separate. One is what happens on discussion lists, where > messages get lost and in the process unrelated recipients get > unsubscribed. The other is simple forwarding and send-to-a-friend > which gets lost but is less likely to cause problems for the > recipients beyond not getting the mail they want. I know you don't like talking about ESP concerns, but for the sake of fitting into the categorizations you state, I think that usage of ESPs falls into the send-to-a-friend category. Is there a better term than "send-to-a-friend" that is more aligned to the vast variety of use cases and types of customers that ESPs have grown to support? The term sounds a bit pejorative. Think about use cases like: digital receipts sent from point of sale systems via an ESP on behalf of small businesses who don't have the ability to delegate authorization to the entire domain (e.g. local-flower-s...@yahoo.com) And for the record, the ESP can either have unhappy customers due to rejected email, or they can do something like this (but not call it "rewriting") https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Replace_address_with_a_generic_one Jesse___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
It appears that Scott Kitterman said: >>Domains owners who have users who individually request 3rd parties to emit >>mail as an address within the domain MUST NOT publish a >restrictive DMARC policy if they wish to support their users' usage of any >potential 3rd party. Examples of 3rd parties include >mailing lists and email service providers. These 3rd parties are not always >aware of, or willing to work around, DMARC. Domain owners >implementing DMARC as a means for governance by restricting the unauthorized >usage of the domain MUST be aware that not all of the >3rd parties will make changes to work around DMARC, resulting in >interoperability issues for their users' usage of the 3rd parties. >Domain owners SHOULD provide an alternative address for these users within a >cousin domain or subdomain that is not directly >associated with the organization's brand-associated domain that is used for >marketing and transactional email that needs the security >benefits of DMARC. These users MUST use an address within a domain that does >not have a restrictive DMARC policy. >> >>(Not a troll. Not directly aware of humming (sorry, it's on my bucket list). >>Hopefully, didn't touch the 3rd rail. Honestly, in good >faith, representing the perspective of an extremely large domain owner, users >within said policy-restricted domain, and as a 3rd >party commonly used by these, and similar, users.) > ... >I can see what you're attempting here and I see the logic. I think the >normative part would need to be about 90% shorter. I was going to say the same thing. >I think it misses the impact on innocent bystanders. It seems to me there are two somewhat different kinds of DMARC damange that we might separate. One is what happens on discussion lists, where messages get lost and in the process unrelated recipients get unsubscribed. The other is simple forwarding and send-to-a-friend which gets lost but is less likely to cause problems for the recipients beyond not getting the mail they want. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On April 26, 2023 3:24:58 PM UTC, Hector Santos wrote: > > >On 4/26/2023 7:21 AM, Scott Kitterman wrote: >> On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely wrote: >>> On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote: My recollection is that a general formulation that I proposed had at least some traction out of both groups: > [some appropriate description] domains MUST NOT publish restrictive DMARC > policies due to interoperability issues Leaving aside (for now) the question of what goes into [some appropriate description] and with the assumption that there will be some non-normative discussion to amplify whatever that is and probably give some indication about what domains might do to not be one of those domains, is there anyone who just can't live with that formulation of the situation? >>> Me, for one. Because more than 98% of domains are going to fall into the >>> description, however we word it, that statement makes the whole I-D >>> nonsensical. Cannot we just tell the problem without MUSTard? >>> >>> In any case, using the complement of [some appropriate description] is >>> certainly easier. For example: >>> >>> Forcing authentication into Internet mail by publishing restrictive >>> DMARC >>> policies breaks some well established patterns of usage. Publishing >>> such >>> policies is thus RECOMMENDED only for domains [in this other appropriate >>> description]. >>> >> Thanks. >> >> I understand your objection to be that the proposed description of the >> interoperability problems would apply to too many domains, regardless of the >> modifier we might use. Is that correct? >> >> I don't understand the technical issue associated with that objection. I >> get that you feel the construction is too negative, but I don't have a sense >> you think it's inaccurate. Focusing on the technical aspects of this, would >> you please help me understand what you think is technically incorrect about >> it? >> >> Scott K > >Scott, > >I will two to remained focus. With Barry's MUST NOT text and as you surmised: > > [some appropriate description] domains MUST NOT publish restrictive DMARC > policies due to interoperability issues > >I believe you are asking if this is technically correct ... for IETF PS >passage? > >To me, there were a number of folks who indicated support for MUST NOT but >preferred more details. > >We will need to deal with the consequences when existing restrictive domains >have the proverbial "book" thrown at them for their user's actions which >creates the necessary known mitigations; Rewrite and Subscription/Submission >controls. As advice to MLS/MLM implementators, the latter should be a natural >part of the protocol when honoring the policy. The former is a security tear >down when intentionally not honoring the policy. > >With no deliberation as to what the interop issues are and the mitigation, not >closing the loop holes for implementators, I see a new potential security >issue is highlighted. The "MUST NOT due to Interop issues" may require a >security review with a new possible Security Section 11.9 "Intentional DMARC >Security Tear down Threats" or it may fall under an updated section 11.4 as a >Display Name Attack. > >So is it technically correct and sufficient? > >I would be flabbergasted if this was IETF/IESG "technically correct" as a PS. >Maybe as an Informational Status, but difficult as a PS and I believe Barry >may have suggested that. I agree with that if left as is. > I agree that more will be needed. Thanks for the feedback. The last run at this question ended up being a mess, so I'm trying to see if we can get further by going in small steps. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On 4/26/2023 7:21 AM, Scott Kitterman wrote: On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely wrote: On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote: My recollection is that a general formulation that I proposed had at least some traction out of both groups: [some appropriate description] domains MUST NOT publish restrictive DMARC policies due to interoperability issues Leaving aside (for now) the question of what goes into [some appropriate description] and with the assumption that there will be some non-normative discussion to amplify whatever that is and probably give some indication about what domains might do to not be one of those domains, is there anyone who just can't live with that formulation of the situation? Me, for one. Because more than 98% of domains are going to fall into the description, however we word it, that statement makes the whole I-D nonsensical. Cannot we just tell the problem without MUSTard? In any case, using the complement of [some appropriate description] is certainly easier. For example: Forcing authentication into Internet mail by publishing restrictive DMARC policies breaks some well established patterns of usage. Publishing such policies is thus RECOMMENDED only for domains [in this other appropriate description]. Thanks. I understand your objection to be that the proposed description of the interoperability problems would apply to too many domains, regardless of the modifier we might use. Is that correct? I don't understand the technical issue associated with that objection. I get that you feel the construction is too negative, but I don't have a sense you think it's inaccurate. Focusing on the technical aspects of this, would you please help me understand what you think is technically incorrect about it? Scott K Scott, I will two to remained focus. With Barry's MUST NOT text and as you surmised: [some appropriate description] domains MUST NOT publish restrictive DMARC policies due to interoperability issues I believe you are asking if this is technically correct ... for IETF PS passage? To me, there were a number of folks who indicated support for MUST NOT but preferred more details. We will need to deal with the consequences when existing restrictive domains have the proverbial "book" thrown at them for their user's actions which creates the necessary known mitigations; Rewrite and Subscription/Submission controls. As advice to MLS/MLM implementators, the latter should be a natural part of the protocol when honoring the policy. The former is a security tear down when intentionally not honoring the policy. With no deliberation as to what the interop issues are and the mitigation, not closing the loop holes for implementators, I see a new potential security issue is highlighted. The "MUST NOT due to Interop issues" may require a security review with a new possible Security Section 11.9 "Intentional DMARC Security Tear down Threats" or it may fall under an updated section 11.4 as a Display Name Attack. So is it technically correct and sufficient? I would be flabbergasted if this was IETF/IESG "technically correct" as a PS. Maybe as an Informational Status, but difficult as a PS and I believe Barry may have suggested that. I agree with that if left as is. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely wrote: >On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote: >> My recollection is that a general formulation that I proposed had at least >> some traction out of both groups: >> >>> [some appropriate description] domains MUST NOT publish restrictive DMARC >>> policies due to interoperability issues >> >> Leaving aside (for now) the question of what goes into [some appropriate >> description] and with the assumption that there will be some non-normative >> discussion to amplify whatever that is and probably give some indication >> about >> what domains might do to not be one of those domains, is there anyone who >> just >> can't live with that formulation of the situation? > > >Me, for one. Because more than 98% of domains are going to fall into the >description, however we word it, that statement makes the whole I-D >nonsensical. Cannot we just tell the problem without MUSTard? > >In any case, using the complement of [some appropriate description] is >certainly easier. For example: > >Forcing authentication into Internet mail by publishing restrictive DMARC >policies breaks some well established patterns of usage. Publishing such >policies is thus RECOMMENDED only for domains [in this other appropriate >description]. > Thanks. I understand your objection to be that the proposed description of the interoperability problems would apply to too many domains, regardless of the modifier we might use. Is that correct? I don't understand the technical issue associated with that objection. I get that you feel the construction is too negative, but I don't have a sense you think it's inaccurate. Focusing on the technical aspects of this, would you please help me understand what you think is technically incorrect about it? Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote: My recollection is that a general formulation that I proposed had at least some traction out of both groups: [some appropriate description] domains MUST NOT publish restrictive DMARC policies due to interoperability issues Leaving aside (for now) the question of what goes into [some appropriate description] and with the assumption that there will be some non-normative discussion to amplify whatever that is and probably give some indication about what domains might do to not be one of those domains, is there anyone who just can't live with that formulation of the situation? Me, for one. Because more than 98% of domains are going to fall into the description, however we word it, that statement makes the whole I-D nonsensical. Cannot we just tell the problem without MUSTard? In any case, using the complement of [some appropriate description] is certainly easier. For example: Forcing authentication into Internet mail by publishing restrictive DMARC policies breaks some well established patterns of usage. Publishing such policies is thus RECOMMENDED only for domains [in this other appropriate description]. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On April 26, 2023 2:50:16 AM UTC, Hector Santos wrote: >On 4/25/2023 10:06 PM, Scott Kitterman wrote: >> On April 26, 2023 1:47:14 AM UTC, Hector Santos wrote: >>> On 4/25/2023 9:06 PM, John Levine wrote: PS: If anyone was going to suggest we just tell people how to change their mailing lists to work around DMARC, don't go there. >>> I don't follow. >>> >>> A "no change" recommendation caused problems. The current fix is: >>> >>> 1) "Rewrite From" to tear down restrictive DMARC security, >>> 2) Prevent Subscription/Submission of restrictive DMARC domains. >>> >>> #1 is undesirable. Empirical practice on a different internet has shown >>> when following #2, for an existing list with members with restrictive >>> domains, they will essentially become Read-Only List members because any >>> submission/reply by them will be blocked. >>> >> Hector, >> >> I think we all understand that there are things mailing lists can do to >> mitigate the interoperability impacts of DMARC. I don't think it's germane >> to the current question. Please, let's stay focused. > >I honestly don't follow the PS. What is the question? Where are we not >suppose to "go there" to? > >Let me ask, is DMARCbis going to be intentionally ambiguous about these long >time inherent protocol problems? Just like ADSP was? Or we just want it to be >open ended - say nothing? I don't know. We do that. But not like this, for so >long. I just wish to finally close some of the most obvious loop holes and >reduce false positives with well defined options like done with SPF. SPF has >a way to offer 3rd party machines. DMARC also needs a way to offer 3rd party >signers. > >Something like a simple DMARCbis endorsement would work wonders: > >Verifier MAY check|explore|consider|implement an extended technology >for ADID::SDID authorization. There are a number of concepts available >using a DNS or non-DNS approach to verifier the association, if any. >The following proposals are available: > >Personally, I think it should be reduced to two simple approaches, described >in IETF fashion: > >ATPS - Murray's protocol. Brilliant. Simply wasn't promoted. >VBR - Levine's protocol. Also brilliant. Why was it not used? > >A published DMARCbis will most likely not going to change again for a long >time. So it should recognize in this draft document, the need to help close >the loop holes ADSP failed to do causing it to be abandoned. DMARCbis risk >the same sound engineering challenges. > I'm not claiming this is the only thing that needs to be done to finish DMARCbis. If you want to discuss a topic different than if the construct I've proposed to capture the overall interoperability problem is workable, please don't do it in this thread. As long as it's consistent with the guidance from the chairs and the working group charter, please go start a different thread for the topic. In order to try and avoid this thread getting dragged further off the topic I'm trying to address, I'm going to leave this discussion here. Back to the topic at hand, I believe you could live with the basic construct, which is good to know. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On April 26, 2023 2:23:52 AM UTC, Jesse Thompson wrote: >On Tue, Apr 25, 2023, at 8:06 PM, John Levine wrote: >> It appears that Scott Kitterman said: >> >My recollection is that a general formulation that I proposed had at least >> >some traction out of both groups: >> > >> >> [some appropriate description] domains MUST NOT publish restrictive DMARC >> >> policies due to interoperability issues >> >> This seems like a reasonable approach. As a purely practical point, I >> cannot imagine this document getting through the IESG without some >> clear guidance about DMARC's interop issues. >> >> R's, >> John >> >> PS: If anyone was going to suggest we just tell people how to change >> their mailing lists to work around DMARC, don't go there. > >How about: > >Domains owners who have users who individually request 3rd parties to emit >mail as an address within the domain MUST NOT publish a restrictive DMARC >policy if they wish to support their users' usage of any potential 3rd party. >Examples of 3rd parties include mailing lists and email service providers. >These 3rd parties are not always aware of, or willing to work around, DMARC. >Domain owners implementing DMARC as a means for governance by restricting the >unauthorized usage of the domain MUST be aware that not all of the 3rd parties >will make changes to work around DMARC, resulting in interoperability issues >for their users' usage of the 3rd parties. Domain owners SHOULD provide an >alternative address for these users within a cousin domain or subdomain that >is not directly associated with the organization's brand-associated domain >that is used for marketing and transactional email that needs the security >benefits of DMARC. These users MUST use an address within a domain that does >not h ave a restrictive DMARC policy. > >(Not a troll. Not directly aware of humming (sorry, it's on my bucket list). >Hopefully, didn't touch the 3rd rail. Honestly, in good faith, representing >the perspective of an extremely large domain owner, users within said >policy-restricted domain, and as a 3rd party commonly used by these, and >similar, users.) > I never really got humming either (I mean I understand the theory and that it works, but that doesn't make it not weird in my book). I can see what you're attempting here and I see the logic. I think the normative part would need to be about 90% shorter. I think it misses the impact on innocent bystanders. When you send mail from a domain with a restrictive policy and indirect recipients reject that mail, the intermediary gets the bounce and things like involuntary unsubscriptions from mailing lists result. It's not just about the impact on the relevant domain. It's also about third party impacts. Thanks, Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On 4/25/2023 10:06 PM, Scott Kitterman wrote: On April 26, 2023 1:47:14 AM UTC, Hector Santos wrote: On 4/25/2023 9:06 PM, John Levine wrote: PS: If anyone was going to suggest we just tell people how to change their mailing lists to work around DMARC, don't go there. I don't follow. A "no change" recommendation caused problems. The current fix is: 1) "Rewrite From" to tear down restrictive DMARC security, 2) Prevent Subscription/Submission of restrictive DMARC domains. #1 is undesirable. Empirical practice on a different internet has shown when following #2, for an existing list with members with restrictive domains, they will essentially become Read-Only List members because any submission/reply by them will be blocked. Hector, I think we all understand that there are things mailing lists can do to mitigate the interoperability impacts of DMARC. I don't think it's germane to the current question. Please, let's stay focused. I honestly don't follow the PS. What is the question? Where are we not suppose to "go there" to? Let me ask, is DMARCbis going to be intentionally ambiguous about these long time inherent protocol problems? Just like ADSP was? Or we just want it to be open ended - say nothing? I don't know. We do that. But not like this, for so long. I just wish to finally close some of the most obvious loop holes and reduce false positives with well defined options like done with SPF. SPF has a way to offer 3rd party machines. DMARC also needs a way to offer 3rd party signers. Something like a simple DMARCbis endorsement would work wonders: Verifier MAY check|explore|consider|implement an extended technology for ADID::SDID authorization. There are a number of concepts available using a DNS or non-DNS approach to verifier the association, if any. The following proposals are available: Personally, I think it should be reduced to two simple approaches, described in IETF fashion: ATPS - Murray's protocol. Brilliant. Simply wasn't promoted. VBR - Levine's protocol. Also brilliant. Why was it not used? A published DMARCbis will most likely not going to change again for a long time. So it should recognize in this draft document, the need to help close the loop holes ADSP failed to do causing it to be abandoned. DMARCbis risk the same sound engineering challenges. -- Hector Santos, https://santronics.com https://winserver.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On Tue, Apr 25, 2023, at 8:06 PM, John Levine wrote: > It appears that Scott Kitterman said: > >My recollection is that a general formulation that I proposed had at least > >some traction out of both groups: > > > >> [some appropriate description] domains MUST NOT publish restrictive DMARC > >> policies due to interoperability issues > > This seems like a reasonable approach. As a purely practical point, I > cannot imagine this document getting through the IESG without some > clear guidance about DMARC's interop issues. > > R's, > John > > PS: If anyone was going to suggest we just tell people how to change > their mailing lists to work around DMARC, don't go there. How about: Domains owners who have users who individually request 3rd parties to emit mail as an address within the domain MUST NOT publish a restrictive DMARC policy if they wish to support their users' usage of any potential 3rd party. Examples of 3rd parties include mailing lists and email service providers. These 3rd parties are not always aware of, or willing to work around, DMARC. Domain owners implementing DMARC as a means for governance by restricting the unauthorized usage of the domain MUST be aware that not all of the 3rd parties will make changes to work around DMARC, resulting in interoperability issues for their users' usage of the 3rd parties. Domain owners SHOULD provide an alternative address for these users within a cousin domain or subdomain that is not directly associated with the organization's brand-associated domain that is used for marketing and transactional email that needs the security benefits of DMARC. These users MUST use an address within a domain that does not have a restrictive DMARC policy. (Not a troll. Not directly aware of humming (sorry, it's on my bucket list). Hopefully, didn't touch the 3rd rail. Honestly, in good faith, representing the perspective of an extremely large domain owner, users within said policy-restricted domain, and as a 3rd party commonly used by these, and similar, users.) Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On April 26, 2023 1:47:14 AM UTC, Hector Santos wrote: >On 4/25/2023 9:06 PM, John Levine wrote: >> It appears that Scott Kitterman said: >>> My recollection is that a general formulation that I proposed had at least >>> some traction out of both groups: >>> [some appropriate description] domains MUST NOT publish restrictive DMARC policies due to interoperability issues >> This seems like a reasonable approach. As a purely practical point, I >> cannot imagine this document getting through the IESG without some >> clear guidance about DMARC's interop issues. > >+1 > >> PS: If anyone was going to suggest we just tell people how to change >> their mailing lists to work around DMARC, don't go there. > >I don't follow. > >A "no change" recommendation caused problems. The current fix is: > >1) "Rewrite From" to tear down restrictive DMARC security, >2) Prevent Subscription/Submission of restrictive DMARC domains. > >#1 is undesirable. Empirical practice on a different internet has shown when >following #2, for an existing list with members with restrictive domains, they >will essentially become Read-Only List members because any submission/reply by >them will be blocked. > Hector, I think we all understand that there are things mailing lists can do to mitigate the interoperability impacts of DMARC. I don't think it's germane to the current question. Please, let's stay focused. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
On 4/25/2023 9:06 PM, John Levine wrote: It appears that Scott Kitterman said: My recollection is that a general formulation that I proposed had at least some traction out of both groups: [some appropriate description] domains MUST NOT publish restrictive DMARC policies due to interoperability issues This seems like a reasonable approach. As a purely practical point, I cannot imagine this document getting through the IESG without some clear guidance about DMARC's interop issues. +1 PS: If anyone was going to suggest we just tell people how to change their mailing lists to work around DMARC, don't go there. I don't follow. A "no change" recommendation caused problems. The current fix is: 1) "Rewrite From" to tear down restrictive DMARC security, 2) Prevent Subscription/Submission of restrictive DMARC domains. #1 is undesirable. Empirical practice on a different internet has shown when following #2, for an existing list with members with restrictive domains, they will essentially become Read-Only List members because any submission/reply by them will be blocked. -- Hector Santos, https://santronics.com https://winserver.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
It appears that Scott Kitterman said: >My recollection is that a general formulation that I proposed had at least >some traction out of both groups: > >> [some appropriate description] domains MUST NOT publish restrictive DMARC >> policies due to interoperability issues This seems like a reasonable approach. As a purely practical point, I cannot imagine this document getting through the IESG without some clear guidance about DMARC's interop issues. R's, John PS: If anyone was going to suggest we just tell people how to change their mailing lists to work around DMARC, don't go there. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
