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

Neil Anuskiewicz <neil@marmot-tech.com> Mon, 10 April 2023 00:10 UTC

Return-Path: <neil@marmot-tech.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 71C60C1524A3 for <dmarc@ietfa.amsl.com>; Sun, 9 Apr 2023 17:10:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, 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 (2048-bit key) header.d=marmot-tech.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 nbm7owCm1s9G for <dmarc@ietfa.amsl.com>; Sun, 9 Apr 2023 17:10:16 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 E9766C1522C6 for <dmarc@ietf.org>; Sun, 9 Apr 2023 17:10:15 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id kh6so1820026plb.0 for <dmarc@ietf.org>; Sun, 09 Apr 2023 17:10:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marmot-tech.com; s=google1; t=1681085415; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=+M0pfOqAdIBmDgFrBG93dpH3b7Ewv7MOtvV6I8Jn9vE=; b=OGOoVz1sCbb4h8PoIGoGc2n1FlNyS1hObeNDFZ2vSDJuElIaOgI1NllHWSyKJa0gcU Q36NZI88GF7RIHxaa0/eKjCsdkylhSxEJsLEeni5Gt4arKiIHKO76D32wyVAXCF7PE9i wSQwxO5uC2WDTiD3hkqN4aOKlaeCCorw2V5Ccj+w1Gd/nBqQ2AtBc4wYtvWBr01xImxT uyamWrbduNxaiQThn4zSHX+zWoE798rqM+r6/I69n4KcsIBDJja0T4JpaV/mDtN9V1e4 I8pQVrxUZ6lvGW9cNWd4a3lSHhfgYGizD0VfsOiHTR3YbiWVnq+sioNjmWkdfOstcZUi krVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681085415; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+M0pfOqAdIBmDgFrBG93dpH3b7Ewv7MOtvV6I8Jn9vE=; b=CXNtBGWhcEk52nzGvOpg18mt6GgPqOScP/kTofQLZS+yHu99o8YCy4BT/iRRAg3wvy RL1uuj54pgm+gBlJnOwUI5DNhZ/qPlM3BkHQ5wR3y6FWCF9rrN8IumYtwu+mfO1QVEgd ISVsZ8PMeJrc595jNG/IAIDPQanaZR894NOsQC2IHOrBlflU5a+D7VW0bdSlDhg3eIhS 8cUf4S6XhgBqC1t2oeKDBmNSJyb2ONdFA6nW7yV1+UnJ5aq55gJj4WvxddV78wffq+Nw /3zecVT6xCIR3AsJTfdcMgy4AxvlQ/UtAQ/BYIh8Q3RfP8mwd9TTGbrMVuD4jfEnkQ30 AMHQ==
X-Gm-Message-State: AAQBX9d7mEuIXJ8XA6Y4d4rrf2kanpTd1faIqO7Nw7RViCieh4JiKaUN xvV3Fw4JfqbBKHXaZzt/A6XjQebpLFfh66aTBNc=
X-Google-Smtp-Source: AKy350ZPfzX5k3q37yupZlpTDJAKsXebgPghPbFrHSEGQzWnV+6vibOEQGq8sMSahDTV5MFVrFxX3g==
X-Received: by 2002:a05:6a20:4fa2:b0:da:5e10:799b with SMTP id gh34-20020a056a204fa200b000da5e10799bmr7838378pzb.10.1681085414850; Sun, 09 Apr 2023 17:10:14 -0700 (PDT)
Received: from smtpclient.apple ([2601:1c0:cb02:fad0:d446:3bd8:2f0d:91e9]) by smtp.gmail.com with ESMTPSA id n9-20020a62e509000000b00580e3917af7sm6547406pff.117.2023.04.09.17.10.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 Apr 2023 17:10:14 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-F936AEB0-5D20-4BC8-ABB8-7EFF42F9A3DF"
Content-Transfer-Encoding: 7bit
From: Neil Anuskiewicz <neil@marmot-tech.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 09 Apr 2023 17:10:03 -0700
Message-Id: <1652C025-2364-4514-BF71-BF8E6D25EC72@marmot-tech.com>
References: <7b599a98-922a-44db-af91-2f8aa0f74181@app.fastmail.com>
Cc: dmarc@ietf.org
In-Reply-To: <7b599a98-922a-44db-af91-2f8aa0f74181@app.fastmail.com>
To: Jesse Thompson <zjt@fastmail.com>
X-Mailer: iPad Mail (20D67)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/d8Sfkneye5jyNkwK8H5d_ICQQsE>
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: Mon, 10 Apr 2023 00:10:21 -0000


> On Apr 9, 2023, at 6:33 AM, Jesse Thompson <zjt@fastmail.com> wrote:
> 
> 
>> On Sat, Apr 8, 2023, at 8:17 PM, Mark Alley wrote:
>> Personally, I prefer the latter of the two, quoted below.
>> 
>> "to preserve interoperability, domains SHOULD NOT publish p=reject unless they are [not general purpose]* domains"
>> 
>> "Publishing DMARC records with restrictive policies does cause interoperability problems for some normal email usage patterns. Potential impacts MUST be considered before any domain publishes a restrictive policy."
> 
> I like the latter, as well. I was going to suggest something similar.
> 
> As Todd previously stated, my preference is for language that acknowledges the primacy of the domain owner over interoperability. CISOs have been sold (arguably, by the DMARC deployment companies' marketing) on the idea that there are security benefits. Maybe oversold, but there are benefits and the motivation will not change. Let's not also overlook the primary benefit of _the process of deploying DMARC_ gives to an organization: increased management and governance (enabled by the observability from the reports). In any case, the domain owner is motivated to deploy DMARC and gain the perceived benefits. If we are going to tell these motivated domain owners to MUST do something, at least make it something they might consider doing.
> 
> "Before a general purpose domain publishes p=reject|quarantine, the domain owner MUST emit mail from, or provide to their stakeholders/end-users, an alternative domain or subdomain with a p=none policy for any email that needs to traverse a non-DMARC-mitigating MLM or (more generally) from any 3rd party that cannot be authorized by SPF or DKIM alignment."
> 
> That, combined with Mark's language, I think would resonate with domain owners more than MUST NOT 

Yes, I think presenting solutions is better than stay exposed. No security folks are going to go for a plan that doesn’t have a path to protection.

N