Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

Todd Herr <todd.herr@valimail.com> Fri, 08 March 2024 14:48 UTC

Return-Path: <todd.herr@valimail.com>
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 63B5BC14F61D for <dmarc@ietfa.amsl.com>; Fri, 8 Mar 2024 06:48:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, 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 x5LoYgYgRoVn for <dmarc@ietfa.amsl.com>; Fri, 8 Mar 2024 06:48:20 -0800 (PST)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 B4BEFC14F5F8 for <dmarc@ietf.org>; Fri, 8 Mar 2024 06:48:20 -0800 (PST)
Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-dcc4de7d901so1953476276.0 for <dmarc@ietf.org>; Fri, 08 Mar 2024 06:48:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; t=1709909299; x=1710514099; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=nnTHzfiMJEpKH94ijBRP0bbCVoKzXaiDyGSls9KDIds=; b=PQHZ0lyPUfjdjSj9v03cO+sZINN36Y9msFFhufZuwYm3Xgh/1b3sBTxdDIvG3dswRl EucdmCCtB2NBXZNhH1zUvmwyrASZxoGvFQ8mR2x+GAIVjtDrzVV9I84TiZ10LDFOMBta 7TTbgC1HaV0hGGNgJQRUFu76WbzdGAsw6cJHoKOERTkYsqip8qTG5Ns/a4wguUkOnpJx BDQl/Egbu4cYH/x3B2Hpkm9KEZYyz+gXWzKkDEfa0v5ZYvw6V3QX+Uks10rxOVOBhsWN JEfJF/owor+GiLPdHf/GPJ6h7bOQxJxjo52YB1Nr2LqELAJ505mS/Y8h8mOFQIsbhNML PgZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709909299; x=1710514099; h=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=nnTHzfiMJEpKH94ijBRP0bbCVoKzXaiDyGSls9KDIds=; b=Y0IKKgA4kaXykA/lG7DkXMJII8RRRg8PQ5wcdBiQCvAJyiLfXSKAXB5jMy/JM3iPtu NwcP6Lmft+gwF8RnksB1+c5quARKP9GgyWmejk/uTVXsPgJekOLKeB6i9Ccu1an7R5zG p/8AQPoaL89SCNnOrW/H6gOC1rKHO98hHjVPFys5urzjA/h6g/0wcyybAbG4fy4DNmDM tdY2qbXrJAjxgh7AHx2pHwyGx3QPrYWDLj/Iv6/C22YDt/N9+Rj6fLg/jDWqc8zjDxI1 YcDiTrFM4K9YSJqRxznIGSrN7AE0QlKb6wThRB/6NEPtdVP6PYkE46qBGaCoaWFsnBKp TyIA==
X-Gm-Message-State: AOJu0YzP4qj6v88BElzAzYAmipmqdNjJk3bK4mTYlchHD//T3aOmmFpG U+JuxDbWWh6uFZqnUEVac4B9KnCKZLyU8IYtOrVqG2TUeP1+s4Hp+r2J0dtx+ZkMUxTDOo6VLJ9 zlIZxPzymTdQA36DAMumzk/Pv19OqE4j7J6mDSg5uHncdETH9
X-Google-Smtp-Source: AGHT+IHN1L6MKacXqhFRNj7p0Z+IIhUa2sAKssPkI1cfuG/L6dARRHE5FNfNKtE59IWFYKt9EZP5rbQog5xjQ1EP5dg=
X-Received: by 2002:a25:790e:0:b0:dc2:4f34:c964 with SMTP id u14-20020a25790e000000b00dc24f34c964mr18700611ybc.23.1709909299509; Fri, 08 Mar 2024 06:48:19 -0800 (PST)
MIME-Version: 1.0
References: <CAHej_8k_6CWH=iOFCwYr02eAnGsXRtb+cuAffPMEBS87RONgeg@mail.gmail.com> <BB63C6A6-2B5F-4C06-AEC0-25949716E4DA@kitterman.com> <CAHej_8k3eBQVk-R9Mrd0k0Jw8QXvZuYcOxmQiZrNjn4=o1EeyQ@mail.gmail.com> <3D8C0167-1BDC-4FE9-875E-09E0023177D8@kitterman.com> <CAOZAAfPfM-0utvO9aiMV4NYvQmbq_rx+GgYKNP6mp0-zGQ7Urg@mail.gmail.com> <CAJ4XoYeohikMOQX+7v=UMeZDryB1=4y71EQcEJrz8kgk1uZjeQ@mail.gmail.com> <0ADA05DF-183F-47A8-919F-F4C3D1848888@kitterman.com> <CAOZAAfNk5ifXz=rzv_iQmkphp9LnCbdmsTfkcN2Q2ho4JNeg6g@mail.gmail.com> <40642B68-8694-47D6-B50B-A45270B6E163@kitterman.com> <CAOZAAfN9xBnyci6N0_e6vcC6HDgVcKzXa9zuYWTK2NyQ46gFAA@mail.gmail.com> <CAL0qLwYpHwq1vW0UUDAJ=+P9C2OBqorexHc4c4Pvwk=5zx=qcA@mail.gmail.com> <CALaySJ+YGkLxv5Egv3mdOj1--KgPwdBG+dQ-oLp=puyzuPTg5g@mail.gmail.com> <CAHej_8=F4XZwFGA2_=8RGnZXgPuw4vukoBL4OD1cxMqGJqx_Qg@mail.gmail.com> <296a2070-922b-445a-9181-ec95f6a2d60c@tana.it>
In-Reply-To: <296a2070-922b-445a-9181-ec95f6a2d60c@tana.it>
From: Todd Herr <todd.herr@valimail.com>
Date: Fri, 08 Mar 2024 09:48:03 -0500
Message-ID: <CAHej_8n3UvUR9A-6AWeNd3K4ecYtuMNm48nXkhjneXAZbA3_CQ@mail.gmail.com>
To: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="00000000000065599d061327486e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/viavC3sEWa0U3iv3vmLjMLcfFCg>
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\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Mar 2024 14:48:24 -0000

On Fri, Mar 8, 2024 at 4:52 AM Alessandro Vesely <vesely@tana.it> wrote:

> On 06/03/2024 15:42, Todd Herr wrote:
> > On Tue, Mar 5, 2024 at 10:45 PM Barry Leiba <barryleiba@computer.org>
> wrote:
> >
> >> SHOULD NOT was the consensus call, and the correction Todd
> >> proposes is just making that sentence consistent with that.
>
>
> Yet, Section 7.6 still has:
>
>     In particular, this document makes explicit that domains for general-
>     purpose email MUST NOT deploy a DMARC policy of p=reject.
>
>
>
Yes, due to an oversight on my part, one that I identified during my Last
Call read of DMARCbis, and subsequently opened this thread to transparently
confirm that I had indeed overlooked that phrase in 7.6 during previous
releases and that I believed that it was an oversight and should be
corrected.

The chairs have confirmed that it was an oversight on my part, and the
language will be changed to SHOULD NOT in rev -31, as per the discussion in
this thread and the previous consensus.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.herr@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

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.