Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Mon 17/Apr/2023 07:05:47 +0200 Murray S. Kucherawy wrote: On Sat, Apr 15, 2023 at 3:58 PM Neil Anuskiewicz wrote: 1. Cousin domains. We all get that dmarc doesn’t touch those. Dmarc is to stop spoofing of exact domains. There are other technologies and methods whose responsibility it is to

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Sat, Apr 15, 2023 at 3:58 PM Neil Anuskiewicz wrote: > 1. Cousin domains. We all get that dmarc doesn’t touch those. Dmarc is to > stop spoofing of exact domains. There are other technologies and methods > whose responsibility it is to track down and take down fraudsters. > The claim was

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> On Apr 14, 2023, at 7:43 PM, Mark Alley > wrote: > >  > Its not ideal, but I could live with that. That's somewhat less ambiguous > than [general purpose] domains, but still ambiguous; the Appendix or the same > section could easily clarify "unrestrictive usage policies", and then maybe

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> On Apr 15, 2023, at 4:21 PM, Scott Kitterman wrote: > >  > >> On April 15, 2023 10:58:06 PM UTC, Neil Anuskiewicz >> wrote: >> >> On Apr 14, 2023, at 8:26 PM, Scott Kitterman wrote: >>> >>> Perfect. The goal is working towards consensus is to find something we >>> can >>>

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On April 15, 2023 10:58:06 PM UTC, Neil Anuskiewicz wrote: > > >> On Apr 14, 2023, at 8:26 PM, Scott Kitterman wrote: >> >> Perfect. The goal is working towards consensus is to find something we can >> live with, so that's exactly what I was hoping for. I don't think it's >> ideal >>

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> On Apr 14, 2023, at 8:26 PM, Scott Kitterman wrote: > > Perfect. The goal is working towards consensus is to find something we can > live with, so that's exactly what I was hoping for. I don't think it's ideal > either, but I can live with it. > > Scott K Yes sir, that’s it. However,

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

Perfect. The goal is working towards consensus is to find something we can live with, so that's exactly what I was hoping for. I don't think it's ideal either, but I can live with it. Scott K On Friday, April 14, 2023 10:43:24 PM EDT Mark Alley wrote: > Its not ideal, but I could live with

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

Its not ideal, but I could live with that. That's somewhat less ambiguous than [general purpose] domains, but still ambiguous; the Appendix or the same section could easily clarify "unrestrictive usage policies", and then maybe the appendix, as you say, could cover the known issues and

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Friday, April 14, 2023 5:54:06 PM EDT Dotzero wrote: > Barry wrote: > > " The idea is MUST NOT because it harms interop with long-standing > deployments. If you decide you're more important than that, you do > what you want and there it is. It's as simple as that" > > I could live with the

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Apr 14, 2023, at 2:54 PM, Dotzero wrote:On Thu, Apr 13, 2023 at 9:52 PM Barry Leiba wrote:> I don’t think folks are objecting to cautionary language.  I think > folks are objecting to a blanket MUST NOT.  If we're going to qualify > the MUST NOT with a bunch of

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Thu, Apr 13, 2023 at 9:52 PM Barry Leiba wrote: > > I don’t think folks are objecting to cautionary language. I think > > folks are objecting to a blanket MUST NOT. If we're going to qualify > > the MUST NOT with a bunch of language, that's a bit different. The > > original proposal was:

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> I don’t think folks are objecting to cautionary language. I think > folks are objecting to a blanket MUST NOT. If we're going to qualify > the MUST NOT with a bunch of language, that's a bit different. The > original proposal was: "To be explicitly clear: domains used for > general-purpose

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On April 13, 2023 5:49:30 PM UTC, "Brotman, Alex" wrote: >> That's the sort of thing I proposed, and which some participants here are >> objecting to. I continue not to understand the objection to clear language >> that >> says that if you do under conditions, it will cause problems, >>

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

rotocol police..) -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -Original Message- > From: Barry Leiba > Sent: Thursday, April 13, 2023 12:34 PM > To: Brotman, Alex > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Example of Indirect Mail Flow Br

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Thu, Apr 13, 2023 at 9:11 AM Dotzero wrote: > On Wed, Apr 12, 2023 at 1:57 PM Murray S. Kucherawy > wrote: > >> On Wed, Apr 12, 2023 at 8:27 AM Brotman, Alex >> wrote: >> >>> In the case of DNSSEC, my ISP is the intermediary utilizing DNSSEC, and >>> the website signs records via DNSSEC.

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> I think we all understand the inconvenience that DMARC can cause to a > subset of domains, or more accurately its users. The problem here that we're describing as an interoperability issue is not that DMARC causes problems for the users of domains that choose to use p=reject -- that would be

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Wed, Apr 12, 2023 at 1:57 PM Murray S. Kucherawy wrote: > On Wed, Apr 12, 2023 at 8:27 AM Brotman, Alex > wrote: > >> In the case of DNSSEC, my ISP is the intermediary utilizing DNSSEC, and >> the website signs records via DNSSEC. The website I want to go to breaks >> their DNSSEC. My ISP

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Wed, Apr 12, 2023 at 8:27 AM Brotman, Alex wrote: > In the case of DNSSEC, my ISP is the intermediary utilizing DNSSEC, and > the website signs records via DNSSEC. The website I want to go to breaks > their DNSSEC. My ISP cannot retrieve a record to return to my browser that > can be used.

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

& Messaging Policy Comcast From: Murray S. Kucherawy Sent: Wednesday, April 12, 2023 9:51 AM To: Brotman, Alex Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject? On Wed, Apr 12, 2023 at 6:31 AM Murray S. Kucherawy mailto:superu...@gmail

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Wed, Apr 12, 2023 at 6:31 AM Murray S. Kucherawy wrote: > To my mind, there's a substantial difference between something like TLSv1 > or HTTP whose deprecation excludes you from participating in something > until you upgrade, versus the DMARC situation where because of an > unfortunate

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Wed, Apr 12, 2023 at 5:20 AM Brotman, Alex wrote: > There is a non-zero set of cases where the IETF prefers security over > interoperability. A document like RFC8997/8996 where we've deprecated > TLSv1 in because it was no longer secure. I assure you there are still > systems/users who have

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

of each policy type, and the implications of each? -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -Original Message- > From: dmarc On Behalf Of Scott Kitterman > Sent: Tuesday, April 11, 2023 11:50 PM > To: dmarc@ietf.org > Subject: Re: [dm

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Wed 12/Apr/2023 07:10:26 +0200 Neil Anuskiewicz wrote: On Apr 11, 2023, at 9:25 PM, Murray S. Kucherawy wrote: On Tue, Apr 11, 2023 at 8:25 PM Neil Anuskiewicz wrote: The standard and the document should reflect that it’s already making a massive difference and could do even more. The

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Apr 11, 2023, at 9:25 PM, Murray S. Kucherawy wrote:On Tue, Apr 11, 2023 at 8:25 PM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:The standard and the document should reflect that it’s already making a massive difference and could do even more. I don’t think it’s unreasonable to

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Tue, Apr 11, 2023 at 8:25 PM Neil Anuskiewicz wrote: > The standard and the document should reflect that it’s already making a > massive difference and could do even more. I don’t think it’s unreasonable > to expect ml managers to adapt. If cyber crime was street crime people > would be

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On April 12, 2023 3:24:39 AM UTC, Neil Anuskiewicz wrote: > > >> On Apr 8, 2023, at 6:56 AM, John Levine wrote: >> >> We're never going to persuade DMARC absolutists that the damage is real, >> nor the rest of us that we can wave our hands and ignore the damage. > >John, the damage is real.

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> On Apr 8, 2023, at 6:56 AM, John Levine wrote: > > We're never going to persuade DMARC absolutists that the damage is real, > nor the rest of us that we can wave our hands and ignore the damage. John, the damage is real. There’s no doubt about that. Trade offs, painful trade offs, have to

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

It appears that Neil Anuskiewicz said: >-=-=-=-=-=- >To this point, some inbound configurations have no record or a permerror have >a continue disposition. Is that risky? Everything is a trade off so I� m not >asking is there any >risk at all but more asking about the trade offs. It seems to

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

To this point, some inbound configurations have no record or a permerror have a continue disposition. Is that risky? Everything is a trade off so I’m not asking is there any risk at all but more asking about the trade offs.On Apr 5, 2023, at 3:58 AM, Douglas Foster wrote:The sad thing is that 

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Thu, Apr 6, 2023, at 11:43 AM, Murray S. Kucherawy wrote: > > > On Sat, Apr 1, 2023 at 3:13 PM Jesse Thompson wrote: >> __ >> I just read https://datatracker.ietf.org/doc/rfc6541/ (or, re-read, I can't >> remember) >> >> I'm struggling to understand how ATPS is significantly better than

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

Hi, Le 06/04/2023 à 20:05, Dotzero a écrit : > > So Baptiste, what responsibility do you expect these organizations to > undertake? I'm asking this as a serious question, not a rhetorical one. > In all seriousness they are/were focused on addressing their, > potentially existential, problems and

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Thu, Apr 6, 2023 at 9:19 AM Baptiste Carvello < devel2...@baptiste-carvello.net> wrote: > Hallo, > > Le 06/04/2023 à 01:46, Dotzero a écrit : > > > > Not at all. The discussion (and specific post I was responding to) was > > about mailing lists but it also applies more generally. A number of >

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Sat, Apr 1, 2023 at 3:13 PM Jesse Thompson wrote: > I just read https://datatracker.ietf.org/doc/rfc6541/ (or, re-read, I > can't remember) > > I'm struggling to understand how ATPS is significantly better than > delegation via DKIM CNAME records. I can see that it's simpler for a domain >

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

Hallo, Le 06/04/2023 à 01:46, Dotzero a écrit : > > Not at all. The discussion (and specific post I was responding to) was > about mailing lists but it also applies more generally. A number of > years ago I saw bounces from a Polish domain. Their policy was that if > the From and the Mail From

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Wed, Apr 5, 2023, at 4:41 PM, Jim Fenton wrote: > This got me to musing: What if IETF decided to remove its From address > rewriting and started bouncing all incoming mail to its mailing lists from > domains that have a p=reject (and maybe p=quarantine) policy? I don’t think > it would be

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Wed, Apr 5, 2023 at 5:41 PM Jim Fenton wrote: > On 1 Apr 2023, at 8:25, Dotzero wrote: > > > Hmm, let's apply this to DMARC. > > > > " But it interoperates just fine once you make the effort." > > > > Nobody forces a Sender to publish a DMARC record. Nobody forces a > receiver > > to

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

Yes, imperfections will always be with us.That is my point. Why should we expect that millions of organizations, operating independently, will produce a result where the good guys always have perfectly correct information? My implementation expects problems.Separating the harmless

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On 1 Apr 2023, at 8:25, Dotzero wrote: > Hmm, let's apply this to DMARC. > > " But it interoperates just fine once you make the effort." > > Nobody forces a Sender to publish a DMARC record. Nobody forces a receiver > to validate DMARC. Nobody forces mailing lists to accept mail from domains >

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Apr 5, 2023, at 3:58 AM, Douglas Foster wrote:The sad thing is that there is no need to do a bandage pull if evaluators can learn how to serve the interests of their users properly.   I don't throw away any mail based on Sender Authentication failure alone.   But I also don't tolerate the

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

The sad thing is that there is no need to do a bandage pull if evaluators can learn how to serve the interests of their users properly. I don't throw away any mail based on Sender Authentication failure alone. But I also don't tolerate the idea that I have to accept malicious impersonation in

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

I’m with Doug on this one. The bandage should be pulled off quickly and sympathy expressed to those who miss backward compatibility. I wouldn’t say utilitarianism is the right frame but here why wouldn’t it be morally right not to mention technically sound to inconvenience and anger the few to

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Mar 29, 2023, at 7:25 PM, Murray S. Kucherawy wrote:On Thu, Mar 30, 2023 at 11:01 AM Douglas Foster wrote:Someone please explain to me why everyone should make themselves more vulnerable to ransomware and other attacks so that mailing lists can avoid

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Sat 01/Apr/2023 13:17:55 +0200 Jim Fenton wrote: Not picking on Murray here, but his message was the most recent that talked about p=reject with respect to non-transactional email: On 1 Apr 2023, at 15:53, Murray S. Kucherawy wrote: If we use SHOULD NOT, as you suggest, there's an

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

I'm looking at this through the lens of formerly being a domain owner for a complex organization doing a successful DMARC deployment which ended at p=quarantine for the organization domain primarily housing user-generated email. A subdomain strategy is employed for most other non-user generated

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

We simply fundamentally disagree here. Barry On Sun, Apr 2, 2023 at 12:33 AM Dotzero wrote: > > > > On Sat, Apr 1, 2023 at 3:02 AM Barry Leiba wrote: >> >> > If we use SHOULD NOT, as you suggest, there's an implication that there >> > might be a valid reason for >> > non-transactional mail to

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

It has been hard to miss the fact of near-zero participation from mailbox providers, cloud-based email filtering services, and filtering software vendors -- essentially everyone involved in 90+ percent of all email filtering. We do better at acquiring DNS statistics than at acquiring inbound

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> On Apr 1, 2023, at 6:29 AM, Scott Kitterman wrote: > > I think that's not quite it. > > There is clearly a valid reason. There are domains that value the security > properties of p=reject more highly than the negative effects to > interoperability. For many years we knew this would

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> On Apr 1, 2023, at 11:33 AM, Dotzero wrote: > > > > On Sat, Apr 1, 2023 at 3:02 AM Barry Leiba > wrote: >> > If we use SHOULD NOT, as you suggest, there's an implication that there >> > might be a valid reason for >> > non-transactional mail to use

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> On Apr 1, 2023, at 11:25 AM, Dotzero wrote: > Nobody forces a Sender to publish a DMARC record. Nobody forces a receiver to > validate DMARC. Nobody forces mailing lists to accept mail from domains which > publish a DMARC record let alone one which publishes p=reject policy. But it >

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> On Apr 1, 2023, at 7:17 AM, Jim Fenton wrote: > > Not picking on Murray here, but his message was the most recent that talked > about p=reject with respect to non-transactional email: > > On 1 Apr 2023, at 15:53, Murray S. Kucherawy wrote: > >> If we use SHOULD NOT, as you suggest,

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Saturday, April 1, 2023 11:08:00 AM EDT Dotzero wrote: ... > If you feel this strongly, where is the record of your advocating for "MUST > NOT" for domains with end users implementing an SPF policy ending in > "-all"? That certainly breaks interoperability through mailing lists and > various

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

Dotzero skrev den 2023-04-01 17:25: Nobody forces a Sender to publish a DMARC record. Nobody forces a receiver to validate DMARC. Nobody forces mailing lists to accept mail from domains which publish a DMARC record let alone one which publishes p=reject policy. But it interoperates just fine

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

Yours is the most reasoned argument in support of "MUST NOT" vs "SHOULD NOT", even if I disagree with you. You recognize the issues involved with going the "MUST NOT" path even though you ultimately support it. Michael Hammer On Sat, Apr 1, 2023 at 6:30 AM Scott Kitterman wrote: > > > On

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Sat, Apr 1, 2023 at 3:02 AM Barry Leiba wrote: > > If we use SHOULD NOT, as you suggest, there's an implication that there > might be a valid reason for > > non-transactional mail to use "p=reject". Are we okay with that? > > When do folks get to line up so they can plead the case for their

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Fri, Mar 31, 2023 at 8:00 AM Barry Leiba wrote: > > Compare that with the move to https everywhere. Having to get > certificates and > > encrypting and decrypting all stuff is certainly not an interoperability > > improvement. > > Say WHAT? There's no interoperability issue there. > >

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Sat, Apr 1, 2023 at 2:53 AM Murray S. Kucherawy wrote: > On Fri, Mar 31, 2023 at 5:48 PM Dotzero wrote: > >> >> >> >>> >>> >>> But when you deploy DMARC and force lists to change the way they work, >>> the experience is altered in a way users perceive as a degradation. We're >>> taking

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

Not picking on Murray here, but his message was the most recent that talked about p=reject with respect to non-transactional email: On 1 Apr 2023, at 15:53, Murray S. Kucherawy wrote: > If we use SHOULD NOT, as you suggest, there's an implication that there > might be a valid reason for

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On April 1, 2023 6:53:13 AM UTC, "Murray S. Kucherawy" wrote: >On Fri, Mar 31, 2023 at 5:48 PM Dotzero wrote: > >> >> >> >>> >>> >>> But when you deploy DMARC and force lists to change the way they work, >>> the experience is altered in a way users perceive as a degradation. We're >>> taking

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Fri 31/Mar/2023 13:59:40 +0200 Barry Leiba wrote: Compare that with the move to https everywhere. Having to get certificates and encrypting and decrypting all stuff is certainly not an interoperability improvement. Say WHAT? There's no interoperability issue there. Oldish software

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

Depending on the definition of "valid reason", is not "An organization wants unauthenticated mail to be rejected" a valid reason? Although, with the noted interoperability issues, I'm not sure if it qualifies. On Sat, Apr 1, 2023, 1:53 AM Murray S. Kucherawy wrote: > On Fri, Mar 31, 2023 at

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> If we use SHOULD NOT, as you suggest, there's an implication that there might > be a valid reason for > non-transactional mail to use "p=reject". Are we okay with that? I, for one, am not. We often use "SHOULD NOT" incorrectly to mean "MUST NOT, but we know it will be widely violated so

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Fri, Mar 31, 2023 at 5:48 PM Dotzero wrote: > > > >> >> >> But when you deploy DMARC and force lists to change the way they work, >> the experience is altered in a way users perceive as a degradation. We're >> taking something significant away, and the benefit is not perceived to be >>

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

I have a concept for how to solve this, in a form that Big Tech can accept. We ask the intended recipient to arbitrate whether a stream of unauthenticated message (but otherwise innocuous) messages are wanted or not. I hope to have details ready tomorrow. DF On Wed, Mar 29, 2023, 10:23 PM

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> Absolutely a false assertion. When browser providers decided to stop > supporting HTTP and only support HTTPS, there were websites not > reachable that people wanted to reach. That is the very definition of > broken interoperability. Websites that wanted to be reached (which > hadn't already

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Fri, Mar 31, 2023 at 3:05 PM Murray S. Kucherawy wrote: > On Thu, Mar 30, 2023 at 8:34 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> The world has changed. Insecure mailing lists did not matter in the >> days before email became a weapon. >> > > A comparison was

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Thu, Mar 30, 2023 at 8:34 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > The world has changed. Insecure mailing lists did not matter in the days > before email became a weapon. > A comparison was made to the global deployment of HTTPS to replace HTTP. There have been

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

Hector Santos skrev den 2023-03-31 16:30: - SPF make this a milter, its sadly missing, is possible to test in spamassassin 4 with authres - DKIM remove reject code in dkim, so it cant reject any mails, is possible to test in spamassassin 4 with authres - DMARC this still miss to

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> On Mar 29, 2023, at 5:40 PM, Todd Herr > wrote: > > Colleagues, > > Can someone please point me to a mailing list server or other indirect mail > flow that I might somehow engage with so that I can experience the pain of > not having a message reach its destination when sent with a

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> On Mar 30, 2023, at 10:16 AM, Todd Herr > wrote: > > My fear is that adding further text to DMARCbis that says "MUST NOT use > p=reject" along with the new language in Policy Enforcement Considerations > results in a spec that says: > As a domain owner, you can request treatment for

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On 3/29/2023 9:16 PM, John Levine wrote: It appears that Murray S. Kucherawy said: This is laid out in RFC 6377, Section 5.2, if it would be helpful to have something published to reference. Indeed, ADSP threatened the same damage that DMARC "p=reject" causes, which I think was one of the

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On 3/31/2023 12:49 AM, Barry Leiba wrote: I don't see any hope that people will back away from the perceived security benefits of DMARC to accommodate mailing lists, even if we publish Barry's language. But here's where we're missing my main point, so I'll highlight it: The spec needs to say

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> Compare that with the move to https everywhere. Having to get certificates > and > encrypting and decrypting all stuff is certainly not an interoperability > improvement. Say WHAT? There's no interoperability issue there. There's some effort involved in doing it, and one has to weigh that

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Fri 31/Mar/2023 04:10:10 +0200 John Levine wrote: It appears that Todd Herr said: I'm on board with telling those deploying DMARC what interoperability problems can be caused by a choice of p=reject, but I'm not on board with telling them not to do that. I take your point, but IETF's

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

> I don't see any hope that people will back away from the perceived security > benefits of DMARC to > accommodate mailing lists, even if we publish Barry's language. But here's where we're missing my main point, so I'll highlight it: The spec needs to say what the right thing is for the

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

The world has changed. Insecure mailing lists did not matter in the days before email became a weapon. This month I have been fending off attacks from 20,000+ Chinese servers trying to break in using SMTP AUTH. Everyone else's organization is probably doing the same. When nation-state actors

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

It appears that Todd Herr said: >> 3. Even with the workaround, I see, as a list owner, several unsubscribe >> notifications a week due to excessive bounces. > >You lose me here. Are you saying that the workaround doesn't always work? >Can you elaborate, please? Some mail systems reject even

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Fri, Mar 31, 2023 at 2:28 AM Alessandro Vesely wrote: > > I think we've had this discussion before. This argument reduces to: "I > do > > not like what structured mailing lists, which have been around since the > > '90s at least, do with messages, and I now insist that they change their > >

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Thu 30/Mar/2023 01:55:38 +0200 Barry Leiba wrote: 1. IETF has installed a very ugly workaround to the problem, rewriting the "from" header field. It's absolutely a workaround, and not a proper solution. I agree the workaround is ugly. However, I drafted three ways to avoid it and

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Thu 30/Mar/2023 04:23:17 +0200 Murray S. Kucherawy wrote: On Thu, Mar 30, 2023 at 11:01 AM Douglas Foster wrote: Someone please explain to me why everyone should make themselves more vulnerable to ransomware and other attacks so that mailing lists can avoid being inconvenienced and avoid

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

+1 to Todd's statement, this sums up my views on this as well. On 3/30/2023 9:16 AM, Todd Herr wrote: On Wed, Mar 29, 2023 at 7:55 PM Barry Leiba wrote: 1. IETF has installed a very ugly workaround to the problem, rewriting the "from" header field.  It's absolutely a workaround,

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Wed, Mar 29, 2023 at 7:55 PM Barry Leiba wrote: > 1. IETF has installed a very ugly workaround to the problem, rewriting the > "from" header field. It's absolutely a workaround, and not a proper > solution. > Ok. > > 2. Without the workaround, the real pain is not that a message from >

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On March 29, 2023 9:40:39 PM UTC, Todd Herr wrote: >Colleagues, > >Can someone please point me to a mailing list server or other indirect mail >flow that I might somehow engage with so that I can experience the pain of >not having a message reach its destination when sent with a policy of

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Thu, Mar 30, 2023 at 11:01 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Someone please explain to me why everyone should make themselves more > vulnerable to ransomware and other attacks so that mailing lists can avoid > being inconvenienced and avoid having secure

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

If my cigarette smoke inconveniences 100 people on my plane flight, should I come prepared to go smokeless or should they come prepared with masks? The mailing list problem is created by mailing list practices, and it is the mailing lists problem to solve the problem they created. We actually

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

It appears that Murray S. Kucherawy said: >-=-=-=-=-=- > >On Thu, Mar 30, 2023 at 8:56 AM Barry Leiba wrote: > >> 2. Without the workaround, the real pain is not that a message from >> Comcast posted to the list doesn't get to you (though that's true): the >> real pain is that if Valimail

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

It appears that Todd Herr said: >Can someone please point me to a mailing list server or other indirect mail >flow that I might somehow engage with so that I can experience the pain of >not having a message reach its destination when sent with a policy of >p=reject? > >I post to various IETF

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Thu, Mar 30, 2023 at 8:56 AM Barry Leiba wrote: > 2. Without the workaround, the real pain is not that a message from > Comcast posted to the list doesn't get to you (though that's true): the > real pain is that if Valimail rejects (bounces) those messages, the Mailman > software will

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

1. IETF has installed a very ugly workaround to the problem, rewriting the "from" header field. It's absolutely a workaround, and not a proper solution. 2. Without the workaround, the real pain is not that a message from Comcast posted to the list doesn't get to you (though that's true): the

[dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

Colleagues, Can someone please point me to a mailing list server or other indirect mail flow that I might somehow engage with so that I can experience the pain of not having a message reach its destination when sent with a policy of p=reject? I post to various IETF mailing lists from my work