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

Scott Kitterman <sklist@kitterman.com> Fri, 14 April 2023 17:50 UTC

Return-Path: <sklist@kitterman.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 9B55BC151B09 for <dmarc@ietfa.amsl.com>; Fri, 14 Apr 2023 10:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, 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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b="jbuQ+2pZ"; dkim=pass (2048-bit key) header.d=kitterman.com header.b="gdJrB+IL"
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 cln5BLj49yeL for <dmarc@ietfa.amsl.com>; Fri, 14 Apr 2023 10:50:30 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 B377CC151B0B for <dmarc@ietf.org>; Fri, 14 Apr 2023 10:50:30 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id D6E91F802E4 for <dmarc@ietf.org>; Fri, 14 Apr 2023 13:50:18 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1681494603; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=gIlBMhgRxBdldF7LneohhAosLc1sd+tEmkFIJhlRErc=; b=jbuQ+2pZhhZW6UzleLzhgXd9tn5XOQVMGGLES809hzhmStwgrque/NYWnsybw4aEmrSmp 6LI0n7fxGt0NtjQCA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1681494603; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=gIlBMhgRxBdldF7LneohhAosLc1sd+tEmkFIJhlRErc=; b=gdJrB+IL0qT1aIizknatBTokdAYsAxslvKwf9arqN6x9yMu/bj2rgVFQVFJRdp7XY9Onx 62BsgZ0K4TwdEqflpF+LTSjNZVfVgSMIqat/kxCTnZ9LA/tSce07DJR2kL2Yak/fQSWbMn2 HNDWl+vhELb4VvZUcES3wgdhScMOTJ7QRt/w20mvDhfZVmqODYKp1UVKy0rcLPXkoWi6Sf1 /7t8VVSXpJAHZAPo8KlI+gO3cdtDUgYPcgeBrphcAPcAPfWjJWgaqHEDVpwIw628D9qfXyg HxPd3/ZKPpaAaed8sLuqcSH3rAJg1mVqZ9VYsgx1Q2ZBhfF/uu+69hWjHhtA==
Received: from localhost.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 854EBF80221 for <dmarc@ietf.org>; Fri, 14 Apr 2023 13:50:03 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Fri, 14 Apr 2023 13:49:57 -0400
Message-ID: <10254425.lgQr3lQme0@localhost>
In-Reply-To: <f5a510b6-553c-e07c-c249-03a68c3cc60e@tana.it>
References: <CALaySJ+NBg9vzqa0_t-sBf7EKXQ3A=DTyy-Vc7M-ZK9-vfJxmw@mail.gmail.com> <5ABFFAF7-4B03-4CCC-81C2-303A6B6F506E@wordtothewise.com> <f5a510b6-553c-e07c-c249-03a68c3cc60e@tana.it>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/_x8nx923peF2m967ubjnXTqgaxA>
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: Fri, 14 Apr 2023 17:50:35 -0000

On Friday, April 14, 2023 1:38:42 PM EDT Alessandro Vesely 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.
> >> 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?
> 
> >> 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.
> 
> >> 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 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 think that's a distinct case.  I don't think there's significant controversy 
that mail which fails DMARC at the MLM's MTA can be rejected.  I think this 
would be relatively safe as it's less common to have indirect mail flows going 
into mailing lists than it is going out of them.

I thought what was being suggested for the mailing list case was not that.  I 
thought the suggestion was that mailing lists should check prospectively and 
not accept mail that would fail DMARC checks performed by mailing list 
recipients.  It's not particularly novel (I implemented an equivalent check 
for SPF in 2008), but it's different than the garden variety reject on DMARC 
fail that's relevant to that message.

Scott K