From seth@valimail.com Thu Feb 29 11:02:30 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 F2C82C1519B2 for ; 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 ; 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 ; Thu, 29 Feb 2024 11:02:26 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-1d7232dcb3eso10423175ad.2 for ; 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: In-Reply-To: From: Seth Blank Date: Thu, 29 Feb 2024 14:02:14 -0500 Message-ID: To: Todd Herr Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000681bab061289e6de" 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 19:02:31 -0000 --000000000000681bab061289e6de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Todd Herr 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 beyon= d > 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 message= s > 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", ye= s? > > -- > > *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 prohibit= ed > 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 > --=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. --000000000000681bab061289e6de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This statement is patently false, though, and the guidance= goes well beyond operational reality. I think the statement should be stru= ck in its entirety.

All the major free mail providers ar= e moving to have DMARC policies on their domains. Yahoo has it, 1und1 has i= t, Gmail has committed to do it. That's 2.5bn+ inboxes protected by DMA= RC. Why would we have text says MUST or SHOULD NOT against a practice that&= #39;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=E2=80=AFPM Todd Herr <todd.herr=3D<= a href=3D"mailto:40valimail.com@dmarc.ietf.org">40valimail.com@dmarc.ietf.o= rg> 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.

Sec= tion 7.6, Domain Owner Actions, ends with the following sentence:

In partic= ular, this document makes explicit that domains for general-purpose email= =C2=A0MUST NOT=C2=A0deploy a DMARC policy of p=3Dreject.

I don'= t believe this to be true, however. Rather, Section 8.6, Interoperability C= onsiderations, says SHOULD NOT on the topic (e.g., "It is therefore critica= l that domains that host users who might post messages to mailing lists=C2= =A0SHOULD NO= T=C2=A0publish p=3Dreject")

Section 7.6 therefore should be u= pdated to read "domains for general-purpose email SHOULD NOT deploy a = DMARC policy of p=3Dreject", yes?

--

Todd Herr | Technical Director, Standards & Ecosyste= m
p: 703-220-4153
m:<= span> 703.220.4153
=

This email and all data transmitted w= ith it contains confidential and/or proprietary information intended solely= for the use of individual(s) authorized to receive it. If you are not an i= ntended and authorized recipient you are hereby notified of any use, disclo= sure, copying or distribution of the information included in this transmiss= ion 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 <= /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.

--000000000000681bab061289e6de--