Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On 4/28/2023 5:19 AM, Alessandro Vesely wrote: > On Sun 02/Apr/2023 20:13:48 +0200 Scott Kitterman wrote: >> Mailing list changes to ameliorate damage due to DMARC are in no way an improvement. Absent DMARC, they would not be needed at all. > > +1 In my view, when an incomplete protocol is

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Sun 02/Apr/2023 20:13:48 +0200 Scott Kitterman wrote: Mailing list changes to ameliorate damage due to DMARC are in no way an improvement. Absent DMARC, they would not be needed at all. +1 Best Ale -- ___ dmarc mailing list

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On April 18, 2023 10:25:00 PM UTC, Jim Fenton wrote: >On 9 Apr 2023, at 11:33, Barry Leiba wrote: > >> There is an alternative, though: we can acknowledge that because of how >> those deploying DMARC view their needs over interoperability, DMARC is not >> appropriate as an IETF standard, and

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On April 18, 2023 10:00:45 PM UTC, Jim Fenton wrote: >On 9 Apr 2023, at 0:50, Murray S. Kucherawy wrote: > >> (Note, here, that Barry has in his proposed text limited the constraint to >> those types of deployments where the damage is likely. I concur. DMARC, >> as currently defined, works

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

I'm glad you brought up the binding operative, I had the same thought. The federal mandate also pushed several state governments to follow suit, as there wasn't any pressure before (even though federal BO's don't technically apply to state governments.) Examples: Alabama - reject

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On 9 Apr 2023, at 11:33, Barry Leiba wrote: > There is an alternative, though: we can acknowledge that because of how > those deploying DMARC view their needs over interoperability, DMARC is not > appropriate as an IETF standard, and we abandon the effort to make it > Proposed Standard. > > I see

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On 9 Apr 2023, at 0:50, Murray S. Kucherawy wrote: > (Note, here, that Barry has in his proposed text limited the constraint to > those types of deployments where the damage is likely. I concur. DMARC, > as currently defined, works just fine when deployed in transactional > situations. Or, at

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Fri 14/Apr/2023 21:36:54 +0200 Dotzero wrote: On Fri, Apr 14, 2023 at 2:00 PM Laura Atkins wrote: On 14 Apr 2023, at 18:38, Alessandro Vesely wrote: On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote: On 12 Apr 2023, at 12:21, Douglas Foster wrote: Any form of security creates

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Apr 14, 2023, at 8:37 PM, Dotzero wrote:On Fri, Apr 14, 2023 at 2:00 PM Laura Atkins wrote:On 14 Apr 2023, at 18:38, Alessandro Vesely wrote:On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote:On 12 Apr 2023, at 12:21, Douglas Foster

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Fri, Apr 14, 2023 at 9:47 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > These decisions are made in the light of ransomware attacks that have shut > down critical social infrastructure like city governments and hospital > systems. > > The proceeds from Internet-based fraud

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Fri, Apr 14, 2023 at 6:47 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Unless a mailing list has controls in place to ensure that EVERY post > comes from the asserted participant, it is the height of hypocrisy to ask > an evaluator to assume that the post is from the

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

These decisions are made in the light of ransomware attacks that have shut down critical social infrastructure like city governments and hospital systems. The proceeds from Internet-based fraud are funding groups like Boko Haram that kidnaps girls into sex slavery, boys into child soldiering, and

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Fri, Apr 14, 2023 at 12:37 PM Dotzero wrote: > While the you part of "we" may not see any advantages, quite a few > financials, greeting card sites, retailers AND many receivers have seen the > advantages, including p=reject. One thing I've learned over the years is > that it is presumptuous

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Fri, Apr 14, 2023 at 4:25 PM John Levine wrote: > It appears that Dotzero said: > >While the you part of "we" may not see any advantages, quite a few > >financials, greeting card sites, retailers AND many receivers have seen > the > >advantages, including p=reject. ... > > The advantages

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

It appears that Dotzero said: >While the you part of "we" may not see any advantages, quite a few >financials, greeting card sites, retailers AND many receivers have seen the >advantages, including p=reject. ... The advantages you see are certainly real but they're not about interoperability.

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Fri, Apr 14, 2023 at 2:00 PM Laura Atkins wrote: > > > On 14 Apr 2023, at 18:38, Alessandro Vesely wrote: > > On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote: > > On 12 Apr 2023, at 12:21, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > Any form of security creates

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

> On 14 Apr 2023, at 18:38, Alessandro Vesely wrote: > > On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote: >>> On 12 Apr 2023, at 12:21, Douglas Foster >>> wrote: >>> Any form of security creates inconvenience. >> Yes. And we make tradeoffs between that. In this case, the security is >>

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Friday, April 14, 2023 1:38:42 PM EDT Alessandro Vesely wrote: > On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote: > >> On 12 Apr 2023, at 12:21, Douglas Foster > >> wrote: > >> > >> Any form of security creates inconvenience. > > > > Yes. And we make tradeoffs between that. In this

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote: On 12 Apr 2023, at 12:21, Douglas Foster wrote: Any form of security creates inconvenience. Yes. And we make tradeoffs between that. In this case, the security is ensuring that users at specific domains can and should only send mail

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

> On 12 Apr 2023, at 12:21, Douglas Foster > wrote: > > Any form of security creates inconvenience. Yes. And we make tradeoffs between that. In this case, the security is ensuring that users at specific domains can and should only send mail through approved channels managed by those

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

Any form of security creates inconvenience. Based on the header rewriting done by IETF, I have a hard time seeing how its rewrite of Comcast addresses can cause any of the problems that you cite. But does your domain require even headers toi be rewritten?Why doesn't IETF ask you, and omit

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

Thank you for returning to the topic of stream identifiers. Email filtering is not about single messages, it is about identifying and classifying streams into high value (whitelist), low value (allow) and unwanted (block). I know existing filtering configurations that will conditionally block

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

> On 12 Apr 2023, at 10:45, Alessandro Vesely wrote: > > On Sun 09/Apr/2023 09:50:46 +0200 Murray S. Kucherawy wrote: >> Mike Hammer asks, reasonably, whether an IETF standard containing a "MUST >> NOT" that we know people will ignore calls into question the IETFs relevance >> or legitimacy.

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Sat 08/Apr/2023 23:27:26 +0200 Douglas Foster wrote: Even when the recipient and the evaluator have a great working relationship, neither party may understand what exceptions are needed for the messages from every participant, current or future, to be accepted reliably.   So the list

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Sun 09/Apr/2023 09:50:46 +0200 Murray S. Kucherawy wrote: Mike Hammer asks, reasonably, whether an IETF standard containing a "MUST NOT" that we know people will ignore calls into question the IETFs relevance or legitimacy.  But I submit that the IETF issuing a standards track document

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

I've thought about this a bit more; I could get behind "purpose> domains MUST NOT publish p=reject" (for interoperability) as long as it is made clear the interoperability context for the "MUST NOT" does not address the perceived security benefits of its current usage by domain owners at large.

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Sun 09/Apr/2023 20:33:54 +0200 Barry Leiba wrote: There is an alternative, though: we can acknowledge that because of how those deploying DMARC view their needs over interoperability, DMARC is not appropriate as an IETF standard, and we abandon the effort to make it Proposed Standard.

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

John Levine wrote on 2023-04-09 15:55: When someone sets a DMARC policy for mail from people, it's hard to think of a time when they asked at wll whether that was what the people wanted. Or if they did, they asked something like "do you want your mail to be more secure?" which misses the point.

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On April 9, 2023 6:33:54 PM UTC, Barry Leiba wrote: >> As Todd previously stated, my preference is for language that >> acknowledges the primacy of the domain owner over interoperability > >The problem is that IETF standards are about interoperability, not about >anyone’s primacy. > >There is

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

> On Apr 9, 2023, at 6:33 AM, Jesse Thompson wrote: > >  >> On Sat, Apr 8, 2023, at 8:17 PM, Mark Alley wrote: >> Personally, I prefer the latter of the two, quoted below. >> >> "to preserve interoperability, domains SHOULD NOT publish p=reject unless >> they are [not general purpose]*

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

This topic is so nuanced that I think we need a more detailed discussion than has been proposed. Below is my counter proposal for the topic. Doug Foster As DMARC rollout approaches completion, aggregate reports may continue to indicate non-affiliated servers that produce DMARC FAIL. The DMARC

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

> On Apr 9, 2023, at 2:33 PM, Barry Leiba wrote: > > > As Todd previously stated, my preference is for language that > > acknowledges the primacy of the domain owner over interoperability > > The problem is that IETF standards are about interoperability, not about > anyone’s primacy. > >

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

> As Todd previously stated, my preference is for language that > acknowledges the primacy of the domain owner over interoperability The problem is that IETF standards are about interoperability, not about anyone’s primacy. There is an alternative, though: we can acknowledge that because of how

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

> On Apr 9, 2023, at 2:15 PM, Murray S. Kucherawy wrote: > > On Sun, Apr 9, 2023 at 6:33 AM Jesse Thompson > wrote: >> As Todd previously stated, my preference is for language that acknowledges >> the primacy of the domain owner over interoperability. CISOs have

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Sun, Apr 9, 2023 at 6:33 AM Jesse Thompson wrote: > As Todd previously stated, my preference is for language that acknowledges > the primacy of the domain owner over interoperability. CISOs have been sold > (arguably, by the DMARC deployment companies' marketing) on the idea that > there are

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Sunday, April 9, 2023 3:50:46 AM EDT Murray S. Kucherawy wrote: > Emphatically "wearing no hat" here, just speaking as a long-time > participant: > > On Sat, Apr 8, 2023 at 2:13 PM Mark Alley > 40tekmarc@dmarc.ietf.org> wrote: > > Re-looking at the definition of "SHOULD NOT", I don't see

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Sunday, April 9, 2023 9:55:29 AM EDT John Levine wrote: > It appears that Matthäus Wander said: > >Earlier in the discussion, the term high-value domain has been used > >(along with transactional email domain) in opposition to domain for > >general-purpose email. ... > > "High value" isn't a

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

It appears that Matthäus Wander said: >Earlier in the discussion, the term high-value domain has been used >(along with transactional email domain) in opposition to domain for >general-purpose email. ... "High value" isn't a useful metric here. yahoo.com is a very valuable domain, but they

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Sat, Apr 8, 2023, at 8:17 PM, Mark Alley wrote: > Personally, I prefer the latter of the two, quoted below. > > "to preserve interoperability, domains SHOULD NOT publish p=reject unless > they are [not general purpose]* domains" > > "Publishing DMARC records with restrictive policies does

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

Murray S. Kucherawy wrote on 2023-04-09 09:50: Since one of the IETF's main goals in producing a technical specification is interoperability, and since improperly deployed "p=reject" results in the very essence of non-interoperability in the deployed email base, I'm having trouble imagining

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

Emphatically "wearing no hat" here, just speaking as a long-time participant: On Sat, Apr 8, 2023 at 2:13 PM Mark Alley wrote: > Re-looking at the definition of "SHOULD NOT", I don't see why it can't be > considered. > > "SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that there

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

Personally, I prefer the latter of the two, quoted below. "to preserve interoperability, domains SHOULD NOT publish p=reject unless they are [not general purpose]* domains" "Publishing DMARC records with restrictive policies does cause interoperability problems for some normal email usage

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

It appears that Scott Kitterman said: >We could do I think any of the following and they are roughly semantically >equivalent: > >[general purpose]* domains MUST NOT publish p=reject to preserve >interoperability > >to preserve interoperability, domains SHOULD NOT publish p=reject unless they

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

> On Apr 8, 2023, at 3:28 PM, Scott Kitterman wrote: > > There are several variations of text that roughly mean the same thing, > particularly when you keep in mind that IETF specifications are intended to > be > interoperability specifications, not implementation specifications. > > We

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

d in > >>>>>> various ways for internal messaging. Should I tell our corporate > >>> > >>> admins > >>> > >>>>>> that they need to no longer publish p=reject? They’re violating the > >>> > >>> R

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Sat, Apr 8, 2023 at 5:10 PM Scott Kitterman wrote: > Possible. I didn't count. > > I didn't see any convergence towards an alternative. > The fact that there hasn't been convergence on an alternative doesn't mean there has been convergence on the proposed new txt. This also doesn't mean the

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

ll feels like the right thing to do. > > > > > > > >If it’s not obvious, I’m having a hard time with “MUST NOT”, and > > > >dictating to domain owners what is in their best interests, regardless > > > >of our perceived value of their domain. > > &

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

r perceived value of their domain. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: dmarc On Behalf Of Barry Leiba Sent: Wednesday, March 29, 2023 10:15 AM To: Todd Herr Cc:dmarc@ietf.org Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows I'm ver

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

yees wants to use a mailing list. >> > > >But that still feels like the right thing to do. >> > > > >> > > >If it’s not obvious, I’m having a hard time with “MUST NOT”, and >> > > >dictating to domain owners what is in their best interests,

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

n owners what is in their best interests, regardless > > > >of our perceived value of their domain. > > > > > > > >-- > > > >Alex Brotman > > > >Sr. Engineer, Anti-Abuse & Messaging Policy > > > >Comcast > &g

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

the right thing to do. > > > > > >If it’s not obvious, I’m having a hard time with “MUST NOT”, and > > >dictating to domain owners what is in their best interests, regardless > > >of our perceived value of their domain. > > > > > >-- > > &g

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On April 2, 2023 5:01:20 PM UTC, Alessandro Vesely wrote: >On Fri 31/Mar/2023 18:16:28 +0200 Scott Kitterman wrote: >> On March 31, 2023 11:06:37 AM UTC, Alessandro Vesely wrote: >>> On Fri 31/Mar/2023 02:41:19 +0200 Murray S. Kucherawy wrote: On Thu, Mar 30, 2023 at 8:41 PM Alessandro

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Fri 31/Mar/2023 18:16:28 +0200 Scott Kitterman wrote: On March 31, 2023 11:06:37 AM UTC, Alessandro Vesely wrote: On Fri 31/Mar/2023 02:41:19 +0200 Murray S. Kucherawy wrote: On Thu, Mar 30, 2023 at 8:41 PM Alessandro Vesely wrote: Does that mean that instead of "non-transactional mail

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On March 31, 2023 11:06:37 AM UTC, Alessandro Vesely wrote: >On Fri 31/Mar/2023 02:41:19 +0200 Murray S. Kucherawy wrote: >> On Thu, Mar 30, 2023 at 8:41 PM Alessandro Vesely wrote: >> >>> Does that mean that instead of "non-transactional mail flows" we could say >>> "mail flows involving

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

Douglas Foster wrote " My point was to only restate that "signed" is the only truth that the DMARC policy can assert." This is not true. If a sending domain provides a p=reject policy assertion in their DMARC record, that is truth. They are not saying that fail always means fraud. They are saying

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Fri 31/Mar/2023 02:41:19 +0200 Murray S. Kucherawy wrote: On Thu, Mar 30, 2023 at 8:41 PM Alessandro Vesely wrote: Does that mean that instead of "non-transactional mail flows" we could say "mail flows involving decades old software"? If you're going to put that label on MLMs, we need to

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Fri, Mar 31, 2023 at 12:22 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > My point was to only restate that "signed" is the only truth that the > DMARC policy can assert.The new prose needs to fix the false certainty > that the old prose created. But until this week,

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

My point was to only restate that "signed" is the only truth that the DMARC policy can assert.The new prose needs to fix the false certainty that the old prose created. But until this week, the group seemed ready to repeat the same mistake and use language which perpetuates the myth that

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Thu, Mar 30, 2023 at 7:51 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I would be happy with p=signed, because that is what p=reject means, and > it is our job is to ensure that people interpret the signal correctly. > Quoting the charter: "The working group will seek to

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Thu, Mar 30, 2023 at 8:41 PM Alessandro Vesely wrote: > Does that mean that instead of "non-transactional mail flows" we could say > "mail flows involving decades old software"? > If you're going to put that label on MLMs, we need to add it to MTAs too. Oh and most of the protocols we're

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Thu 30/Mar/2023 01:44:42 +0200 Barry Leiba wrote: There's no need for me to define it: I intentionally did not word my proposed text that way. I think my proposed text is clear about who MUST NOT use p=reject and why... and, as I said in my response to Scott, I'm happy to add an explicit

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Thu 30/Mar/2023 04:01:10 +0200 Barry Leiba wrote: Hooya’s use of p=reject would amount to announcing that policy, given how mailing list software works and has worked for decades. Actually, that's how mailing list software has worked for decades, but not how it works now. Best Ale --

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

I would be happy with p=signed, because that is what p=reject means, and it is our job is to ensure that people interpret the signal correctly. But for those who believe (a) that sender policy is the problem and (b) that the mailing lists should not be inconvenienced, there is a simple way to

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On 30 Mar 2023, at 10:32, Douglas Foster wrote: Here is a quick attempt at a definition: Interoperability:Two (or more) entities cooperating to achieve a mutual objective" Not quite. If a third party does something that causes failure even when two entities do cooperate on their

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

> Our spec needs to fix the evaluators, and their products, not the sender policy. No: it should be doing both. Let’s look at it this way: Suppose a general-use email provider called “Hooya” promulgated a policy that said receiving domains should bounce any message from a hooya.com sender that

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

Here is a quick attempt at a definition: Interoperability:Two (or more) entities cooperating to achieve a mutual objective" Interoperability can perhaps be illustrated by design for a VPN tunnel or other encryption mechanism: 1) You have to know the identity of the other party. It does not

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

It appears that Murray S. Kucherawy said: >-=-=-=-=-=- > >On Wed, Mar 29, 2023 at 8:59 PM Douglas Foster < >dougfoster.emailstanda...@gmail.com> wrote: > >> MUST seems to take us back to the unfinished debate of 3 years ago, where >> some asserted that DMARC did more harm than good and should

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Thu, Mar 30, 2023 at 7:30 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > There is no interoperability problem. > How are you defining interoperability? "p=reject" when used on domains that send non-transactional messages disrupts interoperability of the email ecosystem in

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

There's no need for me to define it: I intentionally did not word my proposed text that way. I think my proposed text is clear about who MUST NOT use p=reject and why... and, as I said in my response to Scott, I'm happy to add an explicit statement that it's an issue of interoperability with

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

value of their domain. > > > >-- > >Alex Brotman > >Sr. Engineer, Anti-Abuse & Messaging Policy > >Comcast > > > >From: dmarc On Behalf Of Barry Leiba > >Sent: Wednesday, March 29, 2023 10:15 AM > >To: Todd Herr > >Cc: dmarc

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

ging Policy Comcast From: dmarc On Behalf Of Barry Leiba Sent: Wednesday, March 29, 2023 10:15 AM To: Todd Herr Cc:dmarc@ietf.org Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows I'm very much against text such as this, as I think it encourages deployments that are

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

cy > >Comcast > > > >From: dmarc On Behalf Of Barry Leiba > >Sent: Wednesday, March 29, 2023 10:15 AM > >To: Todd Herr > >Cc: dmarc@ietf.org > >Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail > flows > > > >I'm

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

t is in their best interests, regardless of our perceived >value of their domain. > >-- >Alex Brotman >Sr. Engineer, Anti-Abuse & Messaging Policy >Comcast > >From: dmarc On Behalf Of Barry Leiba >Sent: Wednesday, March 29, 2023 10:15 AM >To: Todd Herr >Cc: dm

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

Suppose we use your language. Some domains will still reject your advice, so evaluators still need to apply intelligence to their disposition decisions, if they care about pleasing their account holders. Mailing lists take a calculated risk by forwarding with changes. Doing so creates a trust

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Wed 29/Mar/2023 15:25:19 +0200 Murray S. Kucherawy wrote: On Wed, Mar 29, 2023 at 8:59 PM Douglas Foster wrote: MUST seems to take us back to the unfinished debate of 3 years ago, where some asserted that DMARC did more harm than good and should only be used for transactional mail, which

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Wed, Mar 29, 2023 at 10:15 AM Barry Leiba wrote: > I'm very much against text such as this, as I think it encourages > deployments that are contrary to interoperability and to the intent of > p=reject. > > I contend that p=reject (as with the similar construct in the older ADSP) > was

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

buse & Messaging Policy Comcast From: dmarc On Behalf Of Barry Leiba Sent: Wednesday, March 29, 2023 10:15 AM To: Todd Herr Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows I'm very much against text such as this, as I think it encourages dep

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

I'm very much against text such as this, as I think it encourages deployments that are contrary to interoperability and to the intent of p=reject. I contend that p=reject (as with the similar construct in the older ADSP) was intended for high-value domains and transactional mail, and that it was

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick wrote: > If you agree that interoperability is increased, then I'd suggest that you > actually do agree that the proposed text is appropriate. > > > I don't know that I agree that interoperability is increased... I'm having trouble squaring proposed

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Wed, Mar 29, 2023 at 7:18 PM Alessandro Vesely wrote: > I'd mention indirect mail flows explicitly, rather than referring to > generic > interoperability problems. But several mailing list adopted expedients in > order to overcome those problems. Furthermore, there are experimental >

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Wed, Mar 29, 2023 at 8:59 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > MUST seems to take us back to the unfinished debate of 3 years ago, where > some asserted that DMARC did more harm than good and should only be used > for transactional mail, which seemed to mean PayPal

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

MUST seems to take us back to the unfinished debate of 3 years ago, where some asserted that DMARC did more harm than good and should only be used for transactional mail, which seemed to mean PayPal and not much else. On Wed, Mar 29, 2023, 6:18 AM Alessandro Vesely wrote: > On Tue 28/Mar/2023

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Tue 28/Mar/2023 10:15:04 +0200 Barry Leiba wrote: I raised this issue in the DMARC session in Vienna, and have let it sit for a while so as not to derail other discussion. As we're pretty close to finished with the DMARCbis document, I'd like to raise it again, this time with specific

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On March 29, 2023 4:49:16 AM UTC, John Levine wrote: >It appears that Dotzero said: >>I agree with Scott on this. I don't believe that "open signup" domains >>deserve this special call out in this manner. ... > >The only way to get an account on my system is to know me personally, >but my

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

It appears that Dotzero said: >I agree with Scott on this. I don't believe that "open signup" domains >deserve this special call out in this manner. ... The only way to get an account on my system is to know me personally, but my human users have the same issues as Gmail's or Yahoo's. They're

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

Are we trying to define a protocol that evaluators can follow automatically without ever making any mistakes? I am not. It is simply wrong to assume that changes-in-transit are the only cause of DMARC Fail on acceptable messages.If you work with a mailstream, you should be aware of these

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On 29 Mar 2023, at 5:20, Todd Herr wrote: In my estimation, the language you propose here establishes the primacy of interoperability over the needs/wishes of the domain owner.  As is appropriate for such normative language. From RFC 2119: 6. Guidance in the use of these Imperatives

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

isfied". > > > >-- >Alex Brotman >Sr. Engineer, Anti-Abuse & Messaging Policy >Comcast > >> -Original Message- >> From: dmarc On Behalf Of Scott Kitterman >> Sent: Tuesday, March 28, 2023 4:01 PM >> To: dmarc@ietf.org >> Subject: Re: [

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On March 28, 2023 8:20:54 PM UTC, Todd Herr wrote: >On Tue, Mar 28, 2023 at 4:01 PM Scott Kitterman >wrote: > >> >> "...MUST NOT deploy a DMARC policy other than p=none because use of >> p=reject >> or (to a slightly lesser extent) p=quarantine for such domains is >> extremely >> harmful to

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

Policy Comcast > -Original Message- > From: dmarc On Behalf Of Scott Kitterman > Sent: Tuesday, March 28, 2023 4:01 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows > > On Tuesday, March 28, 2023 3:14:38 PM EDT Todd Herr wrote:

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Tue, Mar 28, 2023 at 4:01 PM Scott Kitterman wrote: > > "...MUST NOT deploy a DMARC policy other than p=none because use of > p=reject > or (to a slightly lesser extent) p=quarantine for such domains is > extremely > harmful to email interoperability. Mitigation strategies are discussed in >

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Tuesday, March 28, 2023 3:14:38 PM EDT Todd Herr wrote: > On Tue, Mar 28, 2023 at 1:41 PM Scott Kitterman > > wrote: > > On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote: > > > NEW > > > > > >5.5.6. Decide If and When to Update DMARC Policy > > > > > >Once the Domain

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Tue, Mar 28, 2023 at 1:41 PM Scott Kitterman wrote: > On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote: > > > NEW > > > >5.5.6. Decide If and When to Update DMARC Policy > > > >Once the Domain Owner is satisfied that it is properly authenticating > >all of its mail,

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote: > I raised this issue in the DMARC session in Vienna, and have let it > sit for a while so as not to derail other discussion. As we're pretty > close to finished with the DMARCbis document, I'd like to raise it > again, this time with

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

l Message- >> From: dmarc On Behalf Of Scott Kitterman >> Sent: Tuesday, March 28, 2023 12:18 PM >> To: dmarc@ietf.org >> Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows >> >> On Tuesday, March 28, 2023 11:58:40 AM EDT Todd

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Tue, Mar 28, 2023 at 12:18 PM Scott Kitterman wrote: > > > I don't understand the connection between DMARC policies and open signup > domains? What makes them in any way special relative to DMARC? > > Scott K > I agree with Scott on this. I don't believe that "open signup" domains deserve

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

tf.org > Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows > > On Tuesday, March 28, 2023 11:58:40 AM EDT Todd Herr wrote: > > Upon further reflection, I find myself liking Barry's proposed text > > less, and instead propose the following: > > &g

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Tuesday, March 28, 2023 11:58:40 AM EDT Todd Herr wrote: > Upon further reflection, I find myself liking Barry's proposed text less, > and instead propose the following: > > On Tue, Mar 28, 2023 at 9:42 AM Todd Herr wrote: > > On 28 Mar 2023, at 17:15, Barry Leiba wrote: > >> > NEW > >> > >

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

Upon further reflection, I find myself liking Barry's proposed text less, and instead propose the following: On Tue, Mar 28, 2023 at 9:42 AM Todd Herr wrote: > On 28 Mar 2023, at 17:15, Barry Leiba wrote: >> >> > NEW >> > >> >5.5.6. Decide If and When to Update DMARC Policy >> > >> >

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

I know that M3 is totally separate from this group, but this is more-so a question for Todd H- does this mean that the M3AAWG authentication best practices recommendation will also change based on this if this is the intended usage going forwards with DMARCbis? Quote from the existing

  1   2   >