Re: [dmarc-ietf] AOL-compatible mailing lists

On Sun, Apr 9, 2023 at 2:28 PM Murray S. Kucherawy wrote: > On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> As an evaluator, what I can accept is that "Some intermediaries could be >> allowed to make some changes y do want unrestricto messages, i

Re: [dmarc-ietf] AOL-compatible mailing lists

What is the operational experience with domains that stop at o=quarantine? On Sun, Apr 9, 2023, 5:28 PM Murray S. Kucherawy wrote: > On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> As an evaluator, what I can accept is that "Some intermediaries

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 an

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

Re: [dmarc-ietf] AOL-compatible mailing lists

Those are all valid points, and I don't have a solution for them which preserves the status quo. I see the world moving to more Sender Authentication, not less. Mandatory Sender Authentication is my expected end-state. ARC is an acknowledgement of this trend. ARC may not add much value to list

Re: [dmarc-ietf] AOL-compatible mailing lists

On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > As an evaluator, what I can accept is that "Some intermediaries could be > allowed to make some changes y do want unrestricto messages, if I have a > list of intermediaries that should be allowed, suffici

Re: [dmarc-ietf] AOL-compatible mailing lists

This discussion is based on a mixture of theory and pragmatism. The pragmatism side is that AOL has created a problem, is unlikely to change, and we have to deal with life as it is rather than the way I would like it to be. The theoretical side is more difficult. I would like to be more sympath

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

Re: [dmarc-ietf] AOL-compatible mailing lists

On Sat, Apr 8, 2023 at 2:13 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > It becomes a simple choice: Lists can adapt to operate the way AOL and > others want them to work, or they can keep to the old ways and live with > the consequences.When the old ways cause damage, I

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 t

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 been

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 s

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 u

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 stil

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 cau

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 why

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 9 06:00:05 2023

Count| Bytes | Who ++--- 64 ( 100%) | 796721 ( 100%) | Total 12 (18.8%) | 96343 (12.1%) | Scott Kitterman 10 (15.6%) | 204726 (25.7%) | Douglas Foster 7 (10.9%) | 88202 (11.1%) | Jesse Thompson 7 (10.9%) | 35691 ( 4.5%) | John Levine

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