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] 5322.From Header Rewrite specification

On March 31, 2023 6:50:22 PM UTC, Todd Herr wrote: >On Fri, Mar 31, 2023 at 2:32 PM Hector Santos 40isdg@dmarc.ietf.org> wrote: > >> Is there a specification for rewriting the 5322.From to help resolve DMARC >> p=reject redistribution problems? >> > >RFC 7960 isn't a specification for

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] 5322.From Header Rewrite specification

On Fri, Mar 31, 2023 at 2:32 PM Hector Santos wrote: > Is there a specification for rewriting the 5322.From to help resolve DMARC > p=reject redistribution problems? > RFC 7960 isn't a specification for rewriting 5322.From per se, but section 4.1.3.1 discusses the topic of rewriting that

[dmarc-ietf] 5322.From Header Rewrite specification

Is there a specification for rewriting the 5322.From to help resolve DMARC p=reject redistribution problems? What is the logic the IETF.ORG list using? Thanks in advance — HLS___ dmarc mailing list dmarc@ietf.org

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