Re: [dmarc-ietf] Solving DMARC damage with User quarantine and Steram-Info tag

Thank you Jesse for your comments. You are focusing on the ESP problem, which I had not given much thought. ESP messages My approach to ESP traffic is simple. I assume that the ESP has authorized the account indicated by the From address, so I don't worry about Sender Authentication as long

Re: [dmarc-ietf] Solving DMARC damage with User quarantine and Steram-Info tag

On Sat, Apr 1, 2023, at 8:04 AM, Douglas Foster wrote: > For purposes of the following discussion, assume that messages from known-bad > senders and messages with unacceptable content have already been blocked. > The question at hand is how to handle Sender Authentication failure when a >

Re: [dmarc-ietf] 5322.From Header Rewrite specification

It appears that Todd Herr said: >RFC 7960 isn't a specification for rewriting 5322.From per se, but section >4.1.3.1 discusses the topic of rewriting that header, including this text: > > Another option for ReSenders is to rewrite the RFC5322 >.From

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

[dmarc-ietf] Solving DMARC damage with User quarantine and Steram-Info tag

For purposes of the following discussion, assume that messages from known-bad senders and messages with unacceptable content have already been blocked. The question at hand is how to handle Sender Authentication failure when a message has no other objectionable characteristics. There are three

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 >>