From seth@valimail.com Thu Feb 29 14:14:04 2024 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A067FC14F694 for ; Thu, 29 Feb 2024 14:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ8vy-BqFY7V for ; Thu, 29 Feb 2024 14:14:00 -0800 (PST) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689F4C14F602 for ; Thu, 29 Feb 2024 14:14:00 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-6e59bbdd8c7so937629b3a.3 for ; Thu, 29 Feb 2024 14:14:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; t=1709244840; x=1709849640; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NxXbUwZmKmghhqkXvWvBNScWCG2wR6oxgvR6sQrhnBQ=; b=gWDw73ePvLa+5JvjQp3uz9l24dXedfhCcnx0tF62H0CHlj8N6S+kvC8LbIt7x13kPq VSVjNfqIDWdtVsvuAlOPQnvpN2RS3UIes3645FSmHD/ldEVUcWe3c4c6UNyah8eK10hv AIBwxRx+OjrXTlSQt/pw0Wgso7oPrF6u4oWoJlyf7jfSlN+i2FePxdTf3cz+8HL7Nt/6 5OCpUsp5pr+wjg6XgPR7fvnBHB+VGL6nS2RAyA4+BiWSCMumFop36aISXzQqzPcGTG6w 1oiwYchtQZtD4JwL6KC1CCCsrfGnMmuXRmXCyztO/Ha9WdC3jnyAhbEOx0b9yG7lDPAI 0bdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709244840; x=1709849640; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NxXbUwZmKmghhqkXvWvBNScWCG2wR6oxgvR6sQrhnBQ=; b=ZIJBeAR0qYXkY4z4gtVJj5qYudJU8xmgBXbK1ZM6TqfdS/9KrZvEQsrdlTMpUbfZ1w E/A18d6ib41kAkMVT2Ea2IgZEEyacysXlS8BWmGZVDrKCYR80F1vKqTNWn/PEBLKi9W+ uAZwbuGnfeQ+N7eKpLOzYpr1jXNkl9YB98gaRVft8zyrgjSC9W/D/iSUYuF03pHfKJiw R10ZbxEmhk92zh0HTR0HEv2q8xY2GvDDSKa6Yyj6YjQvjBqN9dN6HcxY61xynHe3y66K nJpNBea+ElMKEDgAKpxoZe51nh1GYN6lY0e/6r+lR/w9UP8Oynd4dxkhk5cEV1GbSGLy gx5A== X-Gm-Message-State: AOJu0Yzp3wT7NybJLstmw+gK5iJEd29aFBrvobHANcbN6YEJNztdG0C2 /GaA985g4uY6k1xLdHSb010yEiJqjQXLSmEsP9p3C6gj9YkZVVlZKFUBjxZQ/HuZw73sNX8VGer EZarr3NqT+pF+kbuN9c84epKMvwyLLGUhbM5fkp7Kyed8tDTb X-Google-Smtp-Source: AGHT+IEXn84JKijUUSSFuwLtDA2ZJ7HX0e1D2vhUk3rzPD489umb4ty/YV08KVdOlzT/1KpacGPmY9deOYlwEye1FyU= X-Received: by 2002:a17:902:eccc:b0:1dc:2d37:98be with SMTP id a12-20020a170902eccc00b001dc2d3798bemr3949990plh.36.1709244839721; Thu, 29 Feb 2024 14:13:59 -0800 (PST) MIME-Version: 1.0 References: <3D8C0167-1BDC-4FE9-875E-09E0023177D8@kitterman.com> <0ADA05DF-183F-47A8-919F-F4C3D1848888@kitterman.com> <40642B68-8694-47D6-B50B-A45270B6E163@kitterman.com> In-Reply-To: <40642B68-8694-47D6-B50B-A45270B6E163@kitterman.com> From: Seth Blank Date: Thu, 29 Feb 2024 17:13:48 -0500 Message-ID: To: Scott Kitterman Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000819a7006128c9349" Archived-At: Subject: Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Feb 2024 22:14:04 -0000 --000000000000819a7006128c9349 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As Chair: Consensus was already called. Todd just wants the wording consistent in the document. There's no need for another decision here. On Thu, Feb 29, 2024 at 4:36=E2=80=AFPM Scott Kitterman wrote: > Right, I understand that view, but since the chairs have already stepped > back on this issue, who should make that call? > > Scott K > > On February 29, 2024 9:26:42 PM UTC, Seth Blank 40valimail.com@dmarc.ietf.org> wrote: > >It was already resolved, Todd's point is that the text in 7.6 was never > >updated to match, which was a mistake he wants to fix transparently. > > > >On Thu, Feb 29, 2024 at 4:04=E2=80=AFPM Scott Kitterman > >wrote: > > > >> I think it ought to be resolved by the same AD that made the consensus > >> call. > >> > >> Scott K > >> > >> On February 29, 2024 8:58:21 PM UTC, Dotzero wrote= : > >> >I agree that the rough consensus landed on "SHOULD NOT" even though > there > >> >were some who felt "MUST NOT" was "purer". I was one of those who > >> >(reluctantly) supported "SHOULD NOT". Todd is simply trying to get > >> >consistency within the document to match the outcome that there was > rough > >> >agreement on. That is the new issue he is opening and not rehashing t= he > >> >previously closed issue. > >> > > >> >Hopefully the chairs will rule on this so we don't have a previous > issue > >> >reopened during last call. > >> > > >> >Michael Hammer > >> > > >> >On Thu, Feb 29, 2024 at 2:53=E2=80=AFPM Seth Blank >> >40valimail.com@dmarc.ietf.org> wrote: > >> > > >> >> I thought we landed on SHOULD NOT, there was strong resistance to > MUST > >> NOT > >> >> > >> >> On Thu, Feb 29, 2024 at 2:48=E2=80=AFPM Scott Kitterman < > sklist@kitterman.com> > >> >> wrote: > >> >> > >> >>> Okay. I think 8.6 is the one in error. You see how this is going > to > >> go, > >> >>> right? > >> >>> > >> >>> Scott K > >> >>> > >> >>> On February 29, 2024 7:45:15 PM UTC, Todd Herr >> >>> 40valimail.com@dmarc.ietf.org> wrote: > >> >>> >It is not my intent here to relitigate any issues. > >> >>> > > >> >>> >Rather, I believe that the text in 7.6 is wrong, likely due to an > >> >>> oversight > >> >>> >on my part when the new text in 8.6 was published, and I just wan= t > to > >> >>> >confirm that 7.6 is indeed wrong. > >> >>> > > >> >>> >On Thu, Feb 29, 2024 at 2:10=E2=80=AFPM Scott Kitterman < > sklist@kitterman.com > >> > > >> >>> >wrote: > >> >>> > > >> >>> >> In what way is this a new issue that has not already been argue= d > to > >> >>> death > >> >>> >> in the WG? I think for WGLC, we've already done this. We will, > no > >> >>> doubt > >> >>> >> get to have this conversation during the IETF last call, but fo= r > the > >> >>> >> working group, this strikes me as exactly the type of > relitigation > >> of > >> >>> >> issues we've been counseled to avoid. > >> >>> >> > >> >>> >> Scott K > >> >>> >> > >> >>> >> On February 29, 2024 6:54:57 PM UTC, Todd Herr >> >>> >> 40valimail.com@dmarc.ietf.org> wrote: > >> >>> >> >Colleagues, > >> >>> >> > > >> >>> >> >I've been reading DMARCbic rev -30 today with a plan to collec= t > the > >> >>> first > >> >>> >> >set of minor edits and I came across a sentence that I believe > goes > >> >>> beyond > >> >>> >> >minor, so wanted to get a sanity check. > >> >>> >> > > >> >>> >> >Section 7.6, Domain Owner Actions, ends with the following > >> sentence: > >> >>> >> > > >> >>> >> >In particular, this document makes explicit that domains for > >> >>> >> >general-purpose email MUST NOT deploy a DMARC policy of > p=3Dreject. > >> >>> >> > > >> >>> >> > > >> >>> >> >I don't believe this to be true, however. Rather, Section 8.6, > >> >>> >> >Interoperability Considerations, says SHOULD NOT on the topic > >> (e.g., > >> >>> "It > >> >>> >> is > >> >>> >> >therefore critical that domains that host users who might post > >> >>> messages to > >> >>> >> >mailing lists SHOULD NOT publish p=3Dreject") > >> >>> >> > > >> >>> >> >Section 7.6 therefore should be updated to read "domains for > >> >>> >> >general-purpose email SHOULD NOT deploy a DMARC policy of > >> p=3Dreject", > >> >>> yes? > >> >>> >> > > >> >>> >> > >> >>> >> _______________________________________________ > >> >>> >> dmarc mailing list > >> >>> >> dmarc@ietf.org > >> >>> >> https://www.ietf.org/mailman/listinfo/dmarc > >> >>> >> > >> >>> > > >> >>> > > >> >>> > >> >>> _______________________________________________ > >> >>> dmarc mailing list > >> >>> dmarc@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/dmarc > >> >>> > >> >> > >> >> > >> >> -- > >> >> > >> >> *Seth Blank * | Chief Technology Officer > >> >> *e:* seth@valimail.com > >> >> *p:* > >> >> > >> >> This email and all data transmitted with it contains confidential > and/or > >> >> proprietary information intended solely for the use of individual(s= ) > >> >> authorized to receive it. If you are not an intended and authorized > >> >> recipient you are hereby notified of any use, disclosure, copying o= r > >> >> distribution of the information included in this transmission is > >> prohibited > >> >> and may be unlawful. Please immediately notify the sender by > replying to > >> >> this email and then delete it from your system. > >> >> _______________________________________________ > >> >> dmarc mailing list > >> >> dmarc@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/dmarc > >> >> > >> > >> _______________________________________________ > >> dmarc mailing list > >> dmarc@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmarc > >> > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --=20 *Seth Blank * | Chief Technology Officer *e:* seth@valimail.com *p:* This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000819a7006128c9349 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As Chair: Consensus was already called. Todd just wants th= e wording consistent in the document. There's no need for another decis= ion here.

On Thu, Feb 29, 2024 at 4:36=E2=80=AFPM Scott Kitterman <sklist@kitterman.com> wrote:
Right, I understand t= hat view, but since the chairs have already stepped back on this issue, who= should make that call?

Scott K

On February 29, 2024 9:26:42 PM UTC, Seth Blank <seth=3D40valimail.com@dmarc.iet= f.org> wrote:
>It was already resolved, Todd's point is that the text in 7.6 was n= ever
>updated to match, which was a mistake he wants to fix transparently. >
>On Thu, Feb 29, 2024 at 4:04=E2=80=AFPM Scott Kitterman <sklist@kitterman.com>=
>wrote:
>
>> I think it ought to be resolved by the same AD that made the conse= nsus
>> call.
>>
>> Scott K
>>
>> On February 29, 2024 8:58:21 PM UTC, Dotzero <dotzero@gmail.com> wrote:
>> >I agree that the rough consensus landed on "SHOULD NOT&qu= ot; even though there
>> >were some who felt "MUST NOT" was "purer".= I was one of those who
>> >(reluctantly) supported "SHOULD NOT". Todd is simply= trying to get
>> >consistency within the document to match the outcome that ther= e was rough
>> >agreement on. That is the new issue he is opening and not reha= shing the
>> >previously closed issue.
>> >
>> >Hopefully the chairs will rule on this so we don't have a = previous issue
>> >reopened during last call.
>> >
>> >Michael Hammer
>> >
>> >On Thu, Feb 29, 2024 at 2:53=E2=80=AFPM Seth Blank <seth=3D=
>> >40valimail.com@dmarc.ietf.org> wrote:
>> >
>> >> I thought we landed on SHOULD NOT, there was strong resis= tance to MUST
>> NOT
>> >>
>> >> On Thu, Feb 29, 2024 at 2:48=E2=80=AFPM Scott Kitterman &= lt;sklist@kitterm= an.com>
>> >> wrote:
>> >>
>> >>> Okay.=C2=A0 I think 8.6 is the one in error.=C2=A0 Yo= u see how this is going to
>> go,
>> >>> right?
>> >>>
>> >>> Scott K
>> >>>
>> >>> On February 29, 2024 7:45:15 PM UTC, Todd Herr <to= dd.herr=3D
>> >>> 40valimail.com@dmarc.ietf.org> wrote:
>> >>> >It is not my intent here to relitigate any issues= .
>> >>> >
>> >>> >Rather, I believe that the text in 7.6 is wrong, = likely due to an
>> >>> oversight
>> >>> >on my part when the new text in 8.6 was published= , and I just want to
>> >>> >confirm that 7.6 is indeed wrong.
>> >>> >
>> >>> >On Thu, Feb 29, 2024 at 2:10=E2=80=AFPM Scott Kit= terman <sklist= @kitterman.com
>> >
>> >>> >wrote:
>> >>> >
>> >>> >> In what way is this a new issue that has not= already been argued to
>> >>> death
>> >>> >> in the WG?=C2=A0 I think for WGLC, we've= already done this. We will, no
>> >>> doubt
>> >>> >> get to have this conversation during the IET= F last call, but for the
>> >>> >> working group, this strikes me as exactly th= e type of relitigation
>> of
>> >>> >> issues we've been counseled to avoid. >> >>> >>
>> >>> >> Scott K
>> >>> >>
>> >>> >> On February 29, 2024 6:54:57 PM UTC, Todd He= rr <todd.herr=3D
>> >>> >> 40valimail.com@dmarc.ietf.org> wrote:
>> >>> >> >Colleagues,
>> >>> >> >
>> >>> >> >I've been reading DMARCbic rev -30 t= oday with a plan to collect the
>> >>> first
>> >>> >> >set of minor edits and I came across a s= entence that I believe goes
>> >>> beyond
>> >>> >> >minor, so wanted to get a sanity check.<= br> >> >>> >> >
>> >>> >> >Section 7.6, Domain Owner Actions, ends = with the following
>> sentence:
>> >>> >> >
>> >>> >> >In particular, this document makes expli= cit that domains for
>> >>> >> >general-purpose email MUST NOT deploy a = DMARC policy of p=3Dreject.
>> >>> >> >
>> >>> >> >
>> >>> >> >I don't believe this to be true, how= ever. Rather, Section 8.6,
>> >>> >> >Interoperability Considerations, says SH= OULD NOT on the topic
>> (e.g.,
>> >>> "It
>> >>> >> is
>> >>> >> >therefore critical that domains that hos= t users who might post
>> >>> messages to
>> >>> >> >mailing lists SHOULD NOT publish p=3Drej= ect")
>> >>> >> >
>> >>> >> >Section 7.6 therefore should be updated = to read "domains for
>> >>> >> >general-purpose email SHOULD NOT deploy = a DMARC policy of
>> p=3Dreject",
>> >>> yes?
>> >>> >> >
>> >>> >>
>> >>> >> ____________________________________________= ___
>> >>> >> dmarc mailing list
>> >>> >> dmarc@ietf.org
>> >>> >> https://www.ietf.org/mailm= an/listinfo/dmarc
>> >>> >>
>> >>> >
>> >>> >
>> >>>
>> >>> _______________________________________________
>> >>> dmarc mailing list
>> >>> d= marc@ietf.org
>> >>> https://www.ietf.org/mailman/listin= fo/dmarc
>> >>>
>> >>
>> >>
>> >> --
>> >>
>> >> *Seth Blank * | Chief Technology Officer
>> >> *e:* seth@valimail.com
>> >> *p:*
>> >>
>> >> This email and all data transmitted with it contains conf= idential and/or
>> >> proprietary information intended solely for the use of in= dividual(s)
>> >> authorized to receive it. If you are not an intended and = authorized
>> >> recipient you are hereby notified of any use, disclosure,= copying or
>> >> distribution of the information included in this transmis= sion is
>> prohibited
>> >> and may be unlawful. Please immediately notify the sender= by replying to
>> >> this email and then delete it from your system.
>> >> _______________________________________________
>> >> dmarc mailing list
>> >> dmarc= @ietf.org
>> >> https://www.ietf.org/mailman/listinfo/d= marc
>> >>
>>
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org=
>> https://www.ietf.org/mailman/listinfo/dmarc<= br> >>
>
>

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--

Seth Blank <= /b> | Chief Technology Officer
e:<= /b> seth@valimail.com
p:

This email and a= ll data transmitted with it contains confidential and/or proprietary inform= ation intended solely for the use of individual(s) authorized to receive it= . If you are not an intended and authorized recipient you are hereby notifi= ed of any use, disclosure, copying or distribution of the information inclu= ded in this transmission is prohibited and may be unlawful. Please immediat= ely notify the sender by replying to this email and then delete it from you= r system.

--000000000000819a7006128c9349--