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

Laura Atkins <laura@wordtothewise.com> Sat, 15 April 2023 05:42 UTC

Return-Path: <laura@wordtothewise.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 C5339C14CEFD for <dmarc@ietfa.amsl.com>; Fri, 14 Apr 2023 22:42:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level:
X-Spam-Status: No, score=-1.202 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_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.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 rw4giK-dYs_Z for <dmarc@ietfa.amsl.com>; Fri, 14 Apr 2023 22:41:58 -0700 (PDT)
Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C32C14EB17 for <dmarc@ietf.org>; Fri, 14 Apr 2023 22:41:58 -0700 (PDT)
Received: from smtpclient.apple (unknown [176.61.50.187]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 531269F21A; Fri, 14 Apr 2023 22:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1681537317; bh=QqB9WSxbdT+/i6WdJ5holG5nOLAnOvk4z9K2KqdK/Cw=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=cH5ty5By6NgLBNipbK14M71OMPugjWYpBxGTT4WOv/Ju93r2z9H/WxXeIQ5m2LaJt BJOgocdU17XQJqMMKksV+RnbvAj3h9s8f0tvjYAHL+Hnid7/jqEphj69iIs3gj4z1w cx87fnml3bFQHOUAIvv88v7Ze/vfWJ0tPHl2sgQQ=
Content-Type: multipart/alternative; boundary="Apple-Mail-6C712F7C-F858-4A1E-97B8-584E0CFEF8BD"
Content-Transfer-Encoding: 7bit
From: Laura Atkins <laura@wordtothewise.com>
Mime-Version: 1.0 (1.0)
Date: Sat, 15 Apr 2023 06:41:45 +0100
Message-Id: <A9794FE6-464C-40C8-B192-50627C53A23D@wordtothewise.com>
References: <CAJ4XoYftxv21D7mhXdRzg+f4Qo99Y=qcZ+eK5_PvPv62hVbM_A@mail.gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
In-Reply-To: <CAJ4XoYftxv21D7mhXdRzg+f4Qo99Y=qcZ+eK5_PvPv62hVbM_A@mail.gmail.com>
To: Dotzero <dotzero@gmail.com>
X-Mailer: iPhone Mail (20E252)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/lUgmkDNuvgKGUCBEh-cCLOBZ2F8>
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: Sat, 15 Apr 2023 05:42:02 -0000



On Apr 14, 2023, at 8:37 PM, Dotzero <dotzero@gmail.com> wrote:




On Fri, Apr 14, 2023 at 2:00 PM Laura Atkins <laura@wordtothewise.com> wrote:


On 14 Apr 2023, at 18:38, Alessandro Vesely <vesely@tana.it> wrote:

On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote:
On 12 Apr 2023, at 12:21, Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:
Any form of security creates inconvenience.
Yes. And we make tradeoffs between that. In this case, the security is ensuring that users at specific domains can and should only send mail through approved channels managed by those domains. Many users have violated those security policies, by participating in mailing lists. This caused problems for other folks on the mailing lists - as they were the ones removed from the list due to the security policy. The lists responded by rewriting. This causes yet more inconvenience to other subscribers and, additionally, allows the users to bypass their domain security policy.
I am not seeing how this creates an arena of security.


Security is not From: munging.  That's the workaround that security requires.

No security (at least in the viewpoint of some people) is using a p=reject for mail from their domain. In that context, From: munging is actively subverting the security  settings of domains. 


Based on the header rewriting done by IETF, I have a hard time seeing how its rewrite of Comcast addresses can cause any of the problems that you cite.
That’s how the IETF rewrites, it’s not how everyone rewrites.

Couldn't the IETF say how to rewrite?

There’s currently a deployed base where there are many different ways to munge. "It is a _fact_.”
 
But does your domain require even headers to be rewritten?    Why doesn't IETF ask you, and omit rewrite if that is what your domain wants?
Because that doesn’t scale for the IETF.

Mailman options do scale.  From: rewriting is going to fade off by first allowing single subscribers to disable it, for the posts
directed to them, after their MX set up some kind of agreement with the MLM.

The _fact_ still remains that From: rewriting is actively subverting the security of domains that choose to publish p=reject. 

It is hard for me to cry over mailing lists when they cannot ensure that a post comes from the asserted poster and they cannot adapt their DMARC defenses to the preferences of the recipient domains.   Life is hard.   It only gets harder if I wait for someone else to solve problems that I can solve myself.
I don’t understand how header rewriting ensures the authenticity of a poster. Given the data is being modified by the MLM, it seems to me that rewriting compounds the problem.


It doesn't.  The authenticity should be checked on entry.  THIS IS ABUSE post had dkim=fail by http://ietfa.amsl.com" target="_blank" rel="nofollow">ietfa.amsl.com, but they didn't bother rejecting for that, which is what they should have done.  We are suffering all the damage caused by DMARC but don't enjoy any of the advantages it could bring.

I encourage you to think very hard about why, after more than a decade, we still don’t see any of the advantages to DMARC.

While the you part of "we" may not see any advantages, quite a few financials, greeting card sites, retailers AND many receivers have seen the advantages, including p=reject.

One thing I've learned over the years is that it is presumptuous to speak on behalf of "everyone" when you don't actually have their authorization to speak on their behalf. It's kind of like sending email claiming to be from someone else's domain without their permission.

I was using the terminology of the poster I was replying to. Perhaps I should have been clearer and put “we” in quotes to ensure my reply was not misunderstood.

Laura


Michael Hammer