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

Seth Blank <seth@valimail.com> Thu, 29 February 2024 19:02 UTC

Return-Path: <seth@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 F2C82C1519B2 for <dmarc@ietfa.amsl.com>; Thu, 29 Feb 2024 11:02:30 -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_DNSWL_NONE=-0.0001, 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 sCJ0GbpmJM1n for <dmarc@ietfa.amsl.com>; Thu, 29 Feb 2024 11:02:26 -0800 (PST)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 BC015C14F6A0 for <dmarc@ietf.org>; Thu, 29 Feb 2024 11:02:26 -0800 (PST)
Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-1d7232dcb3eso10423175ad.2 for <dmarc@ietf.org>; Thu, 29 Feb 2024 11:02:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; t=1709233346; x=1709838146; 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=56X9FTp4EtXYBZ4qY05hSq0V5MUlR/5NSVNRphwLeL4=; b=eTDI3Dnk8Uma4F3kVBNiRil/MTPsGv24ffs8BJqHlgiCJlbNgmf3RvU1rzMX98wWVs ZbpgPC/XgvBS9c4rbwQsP5g8X4BLIdNjwTsestNjkhmit9Ah2eo52Y2rqPOjrMP4t36G FFfe0yVTCHRZGLXPWmx66Nix5lRFHwWsyesv0aKVLRWD2lXswYv+XJVaJoAZCnc6aD5d 4OriQ8c1+cKbcI21nC81oM8EfAKQdngxhrq1Dyf+nGAHEUXrQYRD6HYkwc8loxB378m9 RNlMzk3SMv3GLnYjDMj/jdRDyAwq/VUk7S+omk90ZvEz4BxVWj8+ntULYtdM7psAzlSP EEDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709233346; x=1709838146; 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=56X9FTp4EtXYBZ4qY05hSq0V5MUlR/5NSVNRphwLeL4=; b=k4F9NTawJxP6BFxk2WFGU8kk/gmWqthw+/O51vSWN8RVG0Rgp0xJrP1XFwEMvV79BJ pM9aw2kYxrtB2+vnH9Nv76qulduefe0v06xkYx5EeKDXzk3o5iz04MGE60+4RyUzuEKu 6w3261fs7+9uiullG6cbVq0wYEGWawWkiPpXIxZ5Zv+QAx8r1qZrGujSfr0qSyflPWg8 6Hn5qPskdYsHXH0M+8mFZ2zdCqaX6y+ZcuhOmDvYDdrxrg+Z+XJadTRDhQ5s1Su1sUXt 8GRHIZ1EvhfE4nKNrMJwoOKqWhhMJmTk6uruiYfN61WSOx6KtcnE6pQSv/TuGmb4VY6C EcoQ==
X-Gm-Message-State: AOJu0YzZwqJhtaG3orIJosGY6KTl58Zm7JC6fC/FES3/Maa9R8RVuhrK lu9V/HSgeQxaDDu/P0VrbT8ZYXfNyio3l9rbB397qwsQkX84S6u7MfWv0WTyQSaqLsc3LFJGkob WXUFC2gYe6ZxM59Z6ds1lgh25v27kQikoqwqU/MPVHe4Y2pUo
X-Google-Smtp-Source: AGHT+IFo5yy33FGO5o3mdiTKyukpd8e1cUoBEd1f4ZW3BL/eqAgV783NLpeCH36VblWpBXgaYGPumsSn+AFk2R3JJLw=
X-Received: by 2002:a17:902:a5c7:b0:1d8:eb2b:7b26 with SMTP id t7-20020a170902a5c700b001d8eb2b7b26mr2647562plq.49.1709233345657; Thu, 29 Feb 2024 11:02:25 -0800 (PST)
MIME-Version: 1.0
References: <CAHej_8k_6CWH=iOFCwYr02eAnGsXRtb+cuAffPMEBS87RONgeg@mail.gmail.com>
In-Reply-To: <CAHej_8k_6CWH=iOFCwYr02eAnGsXRtb+cuAffPMEBS87RONgeg@mail.gmail.com>
From: Seth Blank <seth@valimail.com>
Date: Thu, 29 Feb 2024 14:02:14 -0500
Message-ID: <CAOZAAfMo18r8WUUwbqogV0uX=ad1uKFzrB+m7UZy5JMO0+Xokg@mail.gmail.com>
To: Todd Herr <todd.herr=40valimail.com@dmarc.ietf.org>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000681bab061289e6de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/8wC7QcZQr8YCbZTW4zs5Pc1cTkI>
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: Thu, 29 Feb 2024 19:02:31 -0000

This statement is patently false, though, and the guidance goes well beyond
operational reality. I think the statement should be struck in its entirety.

All the major free mail providers are moving to have DMARC policies on
their domains. Yahoo has it, 1und1 has it, Gmail has committed to do it.
That's 2.5bn+ inboxes protected by DMARC. Why would we have text says MUST
or SHOULD NOT against a practice that's protecting inboxes worldwide and is
picking up steam across them all due to the very real security benefit of
the document this guidance is in...?

On Thu, Feb 29, 2024 at 1:55 PM Todd Herr <todd.herr=
40valimail.com@dmarc.ietf.org> wrote:

> Colleagues,
>
> I've been reading DMARCbic rev -30 today with a plan to collect 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=reject.
>
>
> 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=reject")
>
> Section 7.6 therefore should be updated to read "domains for
> general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", yes?
>
> --
>
> *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.
> _______________________________________________
> 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 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.