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] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt
On April 27, 2023 3:36:29 PM UTC, Alessandro Vesely wrote: >On Thu 27/Apr/2023 16:11:17 +0200 Brotman, Alex wrote: >> In summary: >> >> “Report senders SHOULD attempt delivery via SMTP using STARTTLS to all >> receivers. Transmitting these reports via a secured session is preferrable.” >> >> I don’t think we should add this in > > >+1, after we said there's (almost) no privacy leak. > >You know, we use STARTTLS to send messages to this publicly archived ML. >No leak, anyone browsing the archives uses HTTPS. > It's not a fair comparison. Even if the data isn't particularly privacy sensitive, it's not primarily public. None of that is relevant to the threats described in RFC 7258. 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] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt
On Thu 27/Apr/2023 16:11:17 +0200 Brotman, Alex wrote: In summary: “Report senders SHOULD attempt delivery via SMTP using STARTTLS to all receivers. Transmitting these reports via a secured session is preferrable.” I don’t think we should add this in +1, after we said there's (almost) no privacy leak. You know, we use STARTTLS to send messages to this publicly archived ML. No leak, anyone browsing the archives uses HTTPS. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt
It appears that Brotman, Alex said: >You just want: > > Where the URI specified in a "rua" tag does not specify otherwise, a > Mail Receiver generating a feedback report SHOULD employ a secure > transport mechanism. Sure. That is at worst harmless. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt
I think so. Scott K On April 27, 2023 2:49:07 PM UTC, "Brotman, Alex" wrote: >You just want: > > Where the URI specified in a "rua" tag does not specify otherwise, a > Mail Receiver generating a feedback report SHOULD employ a secure > transport mechanism. > >Restored in some useful place? > >-- >Alex Brotman >Sr. Engineer, Anti-Abuse & Messaging Policy >Comcast > >> -Original Message- >> From: dmarc On Behalf Of Scott Kitterman >> Sent: Thursday, April 27, 2023 10:26 AM >> To: dmarc@ietf.org >> Subject: Re: [dmarc-ietf] I-D Action: >> draft-ietf-dmarc-aggregate-reporting-10.txt >> >> I think that the original wording, which is technology agnostic, is better. >> As you >> suggest, there are multiple ways to address the requirement and being overly >> specific will not age well. >> >> Scott K >> >> On April 27, 2023 2:11:17 PM UTC, "Brotman, Alex" >> wrote: >> >In summary: >> > >> >“Report senders SHOULD attempt delivery via SMTP using STARTTLS to all >> receivers. Transmitting these reports via a secured session is preferrable.” >> > >> >I don’t think we should add this in, but receivers could deploy >> >DANE/MTA-STS if >> they wanted to ensure senders who honor those will use TLS. >> > >> > >> >-- >> >Alex Brotman >> >Sr. Engineer, Anti-Abuse & Messaging Policy Comcast >> > >> >From: dmarc On Behalf Of Hector Santos >> >Sent: Wednesday, April 26, 2023 4:29 PM >> >To: Scott Kitterman >> >Cc: IETF DMARC WG >> >Subject: Re: [dmarc-ietf] I-D Action: >> >draft-ietf-dmarc-aggregate-reporting-10.txt >> > >> > >> > >> > >> >On Apr 26, 2023, at 3:50 PM, Scott Kitterman >> mailto:skl...@kitterman.com>> wrote: >> > >> >I think it would be crazy in 2023 not to use STARTTLS is offered. >> > >> >+1 >> > >> > >> >Personally I interpreted it more as employ a secure transport and think >> >through >> if you really want to be sending the report if you can't. >> > >> >I think there's some room for interpretation and I think that's fine. >> > >> >I believe connectivity is independent of the application. >> > >> >All connections SHOULD assume the highest possible security available today. >> > >> >For unsolicited email, the presumption would be: >> > >> >Port 25 >> >STARTTLS >> > >> >If I was start performing reports (and I think I will), that is how I would >> >begin, >> naturally, with outbound SMTP clients with optional TLS if offered. >> > >> >Sorry if I was not focused with the main question, >> > >> >— >> >HLS >> >> ___ >> dmarc mailing list >> dmarc@ietf.org >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;! >> !CQl3mcHX2A!AVsdi1d3H3sasZaM8-wu8vjzqXURKE-7ScPmC46NRIUY1Bm- >> BCM87bHXhlrobfn5hRcqTP-Q-joOqGmXiPi-$ >___ >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] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt
You just want: Where the URI specified in a "rua" tag does not specify otherwise, a Mail Receiver generating a feedback report SHOULD employ a secure transport mechanism. Restored in some useful place? -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -Original Message- > From: dmarc On Behalf Of Scott Kitterman > Sent: Thursday, April 27, 2023 10:26 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] I-D Action: > draft-ietf-dmarc-aggregate-reporting-10.txt > > I think that the original wording, which is technology agnostic, is better. > As you > suggest, there are multiple ways to address the requirement and being overly > specific will not age well. > > Scott K > > On April 27, 2023 2:11:17 PM UTC, "Brotman, Alex" > wrote: > >In summary: > > > >“Report senders SHOULD attempt delivery via SMTP using STARTTLS to all > receivers. Transmitting these reports via a secured session is preferrable.” > > > >I don’t think we should add this in, but receivers could deploy DANE/MTA-STS > >if > they wanted to ensure senders who honor those will use TLS. > > > > > >-- > >Alex Brotman > >Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > > > >From: dmarc On Behalf Of Hector Santos > >Sent: Wednesday, April 26, 2023 4:29 PM > >To: Scott Kitterman > >Cc: IETF DMARC WG > >Subject: Re: [dmarc-ietf] I-D Action: > >draft-ietf-dmarc-aggregate-reporting-10.txt > > > > > > > > > >On Apr 26, 2023, at 3:50 PM, Scott Kitterman > mailto:skl...@kitterman.com>> wrote: > > > >I think it would be crazy in 2023 not to use STARTTLS is offered. > > > >+1 > > > > > >Personally I interpreted it more as employ a secure transport and think > >through > if you really want to be sending the report if you can't. > > > >I think there's some room for interpretation and I think that's fine. > > > >I believe connectivity is independent of the application. > > > >All connections SHOULD assume the highest possible security available today. > > > >For unsolicited email, the presumption would be: > > > >Port 25 > >STARTTLS > > > >If I was start performing reports (and I think I will), that is how I would > >begin, > naturally, with outbound SMTP clients with optional TLS if offered. > > > >Sorry if I was not focused with the main question, > > > >— > >HLS > > ___ > dmarc mailing list > dmarc@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;! > !CQl3mcHX2A!AVsdi1d3H3sasZaM8-wu8vjzqXURKE-7ScPmC46NRIUY1Bm- > BCM87bHXhlrobfn5hRcqTP-Q-joOqGmXiPi-$ ___ 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] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt
I think that the original wording, which is technology agnostic, is better. As you suggest, there are multiple ways to address the requirement and being overly specific will not age well. Scott K On April 27, 2023 2:11:17 PM UTC, "Brotman, Alex" wrote: >In summary: > >“Report senders SHOULD attempt delivery via SMTP using STARTTLS to all >receivers. Transmitting these reports via a secured session is preferrable.” > >I don’t think we should add this in, but receivers could deploy DANE/MTA-STS >if they wanted to ensure senders who honor those will use TLS. > > >-- >Alex Brotman >Sr. Engineer, Anti-Abuse & Messaging Policy >Comcast > >From: dmarc On Behalf Of Hector Santos >Sent: Wednesday, April 26, 2023 4:29 PM >To: Scott Kitterman >Cc: IETF DMARC WG >Subject: Re: [dmarc-ietf] I-D Action: >draft-ietf-dmarc-aggregate-reporting-10.txt > > > > >On Apr 26, 2023, at 3:50 PM, Scott Kitterman >mailto:skl...@kitterman.com>> wrote: > >I think it would be crazy in 2023 not to use STARTTLS is offered. > >+1 > > >Personally I interpreted it more as employ a secure transport and think >through if you really want to be sending the report if you can't. > >I think there's some room for interpretation and I think that's fine. > >I believe connectivity is independent of the application. > >All connections SHOULD assume the highest possible security available today. > >For unsolicited email, the presumption would be: > >Port 25 >STARTTLS > >If I was start performing reports (and I think I will), that is how I would >begin, naturally, with outbound SMTP clients with optional TLS if offered. > >Sorry if I was not focused with the main question, > >— >HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt
+1 On 4/27/2023 10:11 AM, Brotman, Alex wrote: In summary: “Report senders SHOULD attempt delivery via SMTP using STARTTLS to all receivers. Transmitting these reports via a secured session is preferrable.” I don’t think we should add this in, but receivers could deploy DANE/MTA-STS if they wanted to ensure senders who honor those will use TLS. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast *From:* dmarc *On Behalf Of * Hector Santos *Sent:* Wednesday, April 26, 2023 4:29 PM *To:* Scott Kitterman *Cc:* IETF DMARC WG *Subject:* Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt On Apr 26, 2023, at 3:50 PM, Scott Kitterman mailto:skl...@kitterman.com>> wrote: I think it would be crazy in 2023 not to use STARTTLS is offered. +1 Personally I interpreted it more as employ a secure transport and think through if you really want to be sending the report if you can't. I think there's some room for interpretation and I think that's fine. I believe connectivity is independent of the application. All connections SHOULD assume the highest possible security available today. For unsolicited email, the presumption would be: Port 25 STARTTLS If I was start performing reports (and I think I will), that is how I would begin, naturally, with outbound SMTP clients with optional TLS if offered. Sorry if I was not focused with the main question, — HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc -- Hector Santos, https://santronics.com https://winserver.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt
In summary: “Report senders SHOULD attempt delivery via SMTP using STARTTLS to all receivers. Transmitting these reports via a secured session is preferrable.” I don’t think we should add this in, but receivers could deploy DANE/MTA-STS if they wanted to ensure senders who honor those will use TLS. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: dmarc On Behalf Of Hector Santos Sent: Wednesday, April 26, 2023 4:29 PM To: Scott Kitterman Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt On Apr 26, 2023, at 3:50 PM, Scott Kitterman mailto:skl...@kitterman.com>> wrote: I think it would be crazy in 2023 not to use STARTTLS is offered. +1 Personally I interpreted it more as employ a secure transport and think through if you really want to be sending the report if you can't. I think there's some room for interpretation and I think that's fine. I believe connectivity is independent of the application. All connections SHOULD assume the highest possible security available today. For unsolicited email, the presumption would be: Port 25 STARTTLS If I was start performing reports (and I think I will), that is how I would begin, naturally, with outbound SMTP clients with optional TLS if offered. Sorry if I was not focused with the main question, — 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 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] I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt
There are options on TLS failure. Mandatory TLS is actually pretty common, since PCI DSS, HIPAA and GDBR have all been interpreted as requiring TLS on email.For outbound mail, our MTA is configured to drop the connection if encryption cannot be established. I think this configuration option has become pretty common in commercial products.Domains that cannot accept encrypted traffic are handled with secure web relay (Zixmail or one of its many imitators.) In the case of a report recipient that cannot accept TLS traffic, we would simply drop the destination. For inbound mail, my organization has concluded that data security is the responsibility of the sender, so we do accept unencrypted messages. By and large, mandatory TLS will be implemented consistently, rather than on a specific message like a DMARC report, so I don't know how much needs to be said in this document. Doug On Tue, Apr 25, 2023 at 12:29 PM John R. Levine wrote: > >> Since the only mechanism is mail and nobody's going to S/MIME encrypt > >> their reports, I suggest just deleting it. > > > > TLS vs not TLS. > > I suppose, but that's not up to the report sender. If I say > "rua=mailto:rep...@cruddy.org;, and the MX for cruddy.org doesn't do > STARTTLS, what are you going to do? > > 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] [EXTERNAL] Re: I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt
These are the potential data harvesting strategies that I can envision. Are there others? Data harvesting by originating domain (I don't see how data harvesting by the originating domain can be considered a privacy violation, but these are the strategies: - Report data can be matched to outbound logs to determine which specific messages are covered by a specific report. - If coupled with individualized DKIM scopes or low volumes, report data can be matched to outbound logs to identify specific messages that were forwarded and the domain to which they were forwarded. Local-part of the forwarded address is not revealed. Data harvesting by report processor - Many reports are processed by service providers rather than by the domain owner. The report processor could use that data to develop a database of domain-to-domain communication patterns, and might seek to monetize that knowledge somehow. This possibility applies to both the report sending organization and the report receiving domain. Data harvesting by eavesdroppers - A report might be intercepted by eavesdroppers if the transmission channel is not secured. This information might be useful to an attacker as part of a data aggregation effort. For the last two, I don't see how DKIM scope IDs would be useful to someone who lacked access to the outbound information flow. If the attacker is intercepting all of a domain owner's mail flow, the problem is more serious and the DMARC reports are the least of his worries. Do we have a problem at all? On Wed, Apr 26, 2023 at 3:52 PM Matthäus Wander wrote: > > On Tue 25/Apr/2023 21:08:56 +0200 John R Levine wrote: > >> Looks mostly good to me. By the way, that bit about a malicious > >> Doamin Owner is not hypothetical, and I don't think I'm malicious. > >> Just make it A Domain Owner ... > > Agreed, just Domain Owner then. > > Alessandro Vesely wrote on 2023-04-26 09:25: > > No, wait. Domain owners can only add something when users posts via > > their domain's MSAs. In that case, the information that can be gathered > > by aggregate reports is a blurred image of what can be obtained from > > internal logs. One can find out who is using external MSAs by matching > > connections in small domain to small domain correspondence only. > > The Domain Owner may not learn anything new by putting in tracking IDs > into messages, but the privacy leak creeps into the aggregated report > and becomes visible to third-party report processors or organizational > units that have access to the rua mailbox but not the internal logs. > > Regards, > Matt > > ___ > 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
