IETF Logo Mail Archive

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

Jim Fenton <fenton@bluepopcorn.net> Tue, 18 April 2023 22:25 UTC

Return-Path: <fenton@bluepopcorn.net>
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 C3467C151530 for <dmarc@ietfa.amsl.com>; Tue, 18 Apr 2023 15:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 (1024-bit key) header.d=bluepopcorn.net
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 CUqpbmefDx8L for <dmarc@ietfa.amsl.com>; Tue, 18 Apr 2023 15:25:03 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB190C14CE39 for <dmarc@ietf.org>; Tue, 18 Apr 2023 15:25:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=auJnDkRFVmez+WDTnEJWi2faxQNhP+3O8ik+nBiSdMc=; b=I+WWwL6mIYq9y1y9w3naBV2imA CmoGAKgMSQdHfQ4wB/nri6/V/0HdsQ3ex9ZuHWNmyUGRlHRDYFvAz43K9GabcuYLtX6z8UKg9myGv Pw/cwnZIhJsfLmLNBX+3kvbJG423XJT2UD/LLGD4bYqLfS1zExvxY943qMUVpJwDhHhc=;
Received: from [2601:647:6880:ac1:68f0:9743:9966:1124] (helo=[10.10.20.192]) by v2.bluepopcorn.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <fenton@bluepopcorn.net>) id 1potkz-0008BI-Vl; Tue, 18 Apr 2023 15:25:01 -0700
From: Jim Fenton <fenton@bluepopcorn.net>
To: Barry Leiba <barryleiba@computer.org>
Cc: dmarc@ietf.org
Date: Tue, 18 Apr 2023 15:25:00 -0700
X-Mailer: MailMate (1.14r5852)
Message-ID: <65C7C985-DC0C-4A10-9348-F149143F67DA@bluepopcorn.net>
In-Reply-To: <CALaySJJQ-Mh+=EsmA7QatrcCbCSSTGHt6fRGWequ+KCH3adYUg@mail.gmail.com>
References: <20230409005207.DCA8BBD1CC17@ary.qy> <4a0dba74-3e25-b9cb-dd64-20bf04ae76ba@tekmarc.com> <7b599a98-922a-44db-af91-2f8aa0f74181@app.fastmail.com> <CALaySJJQ-Mh+=EsmA7QatrcCbCSSTGHt6fRGWequ+KCH3adYUg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/4437iTgZRGghO0T1T1ncuBNPMNc>
Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
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: Tue, 18 Apr 2023 22:25:07 -0000

On 9 Apr 2023, at 11:33, Barry Leiba wrote:

> There is an alternative, though: we can acknowledge that because of how
> those deploying DMARC view their needs over interoperability, DMARC is not
> appropriate as an IETF standard, and we abandon the effort to make it
> Proposed Standard.
>
> I see that as the only way forward if we cannot address the damage that
> improperly deployed DMARC policies do to mailing lists.

Unfortunately, much of the world outside IETF sees an RFC number and assumes Standards Track. We have RFC 7489, which is Informational, which then resulted in a mandate [1] for all executive-branch US Government domains to publish p=reject. I have to believe that they thought it was Standards Track when they did this.

-Jim

[1] https://cyber.dhs.gov/assets/report/bod-18-01.pdf

v2.23.0 | Report a Bug | By Email