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

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

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 >

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

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

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

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt

> On Apr 26, 2023, at 3:50 PM, Scott Kitterman > 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

Re: [dmarc-ietf] [EXTERNAL] Re: I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt

On April 26, 2023 7:22:55 PM UTC, "Matthäus Wander" wrote: >Scott Kitterman wrote on 2023-04-26 21:05: >> I think if a non-encrypted transport is used there's a privacy issue with >> sending the report. I think that's one approach. >> >> Currently we have nothing about it in any document.

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt

Scott Kitterman wrote on 2023-04-26 21:05: I think if a non-encrypted transport is used there's a privacy issue with sending the report. I think that's one approach. Currently we have nothing about it in any document. I think the latest revision introduced an undocumented privacy issue.

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt

On April 26, 2023 6:49:32 PM UTC, John Levine wrote: >It appears that Scott Kitterman said: >>I'd like to see the 'SHOULD employ a secure transport mechanism' section >>added back in. As I mentioned in another message, I think >>IETF policy based on RFC 7258 supports it. Alternately,

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt

It appears that Scott Kitterman said: >I'd like to see the 'SHOULD employ a secure transport mechanism' section added >back in. As I mentioned in another message, I think >IETF policy based on RFC 7258 supports it. Alternately, something in privacy >considerations might be okay. I think

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

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

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt

On Wed, Apr 26, 2023 at 8:58 AM Scott Kitterman wrote: > I'd like to see the 'SHOULD employ a secure transport mechanism' section > added back in. As I mentioned in another message, I think IETF policy > based on RFC 7258 supports it. Alternately, something in privacy > considerations might be

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt

I'd like to see the 'SHOULD employ a secure transport mechanism' section added back in. As I mentioned in another message, I think IETF policy based on RFC 7258 supports it. Alternately, something in privacy considerations might be okay. I think it's better to have the SHOULD, but I could

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

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

Re: [dmarc-ietf] [EXTERNAL] Re: I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt

On Tue 25/Apr/2023 21:08:56 +0200 John R Levine wrote: 6.1.  Data Exposure Considerations   Aggregate reports are limited in scope to DMARC policy and   disposition results, to information pertaining to the underlying   authentication mechanisms, and to the domain-level identifiers   involved