Re: [dmarc-ietf] Summary: Search for some consensus, was: Proposed text for p=reject and indirect mail flows

Hector Santos <hsantos@isdg.net> Sat, 29 April 2023 15:01 UTC

Return-Path: <hsantos@isdg.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 9EEEEC151981 for <dmarc@ietfa.amsl.com>; Sat, 29 Apr 2023 08:01:36 -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_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=pass (1024-bit key) header.d=isdg.net header.b="k0jukj3h"; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b="QxrIX3PV"
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 gl1iZZaGiYdW for <dmarc@ietfa.amsl.com>; Sat, 29 Apr 2023 08:01:32 -0700 (PDT)
Received: from mail.winserver.com (mail.winserver.com [3.137.120.140]) (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 ADF28C151530 for <dmarc@ietf.org>; Sat, 29 Apr 2023 08:01:18 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2685; t=1682780474; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:From:Subject:Date:To: Message-Id:Organization:List-ID; bh=49lgZCxoDYqSVt3eSxXycKVMbh2M 3qIb5WSrTNqb9yQ=; b=k0jukj3hXIUdxiHxxhG+otfHsBrgQFii/U+1Uj+HCxxV MqcPNC3M7umBZ3LzrwTZk6qLtLoftHkUcqG8oI0exNETc18cWFZOJJHigpQNUv/Y GPOpPaKWzFMLvrOwKFt2mzFxea2LENHeScuTCMjT8n9lqxBG26SilZIKmt4OpFU=
Received: by winserver.com (Wildcat! SMTP Router v8.0.454.13) for dmarc@ietf.org; Sat, 29 Apr 2023 11:01:14 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=none author.d=isdg.net signer.d=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from beta.winserver.com ([3.132.92.116]) by winserver.com (Wildcat! SMTP v8.0.454.13) with ESMTP id 3173248395.1.7656; Sat, 29 Apr 2023 11:01:13 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2685; t=1682780473; h=Received:Received:From: Subject:Date:To:Message-Id:Organization:List-ID; bh=49lgZCxoDYqS Vt3eSxXycKVMbh2M3qIb5WSrTNqb9yQ=; b=QxrIX3PVQoEI4OfjoQVnNHoxlA7r Fyw7JmprSTB817b4rrwFYow9ZCUrCC/wU4GLzYmVUuBiPc1jVUD21esj7CDTnTYZ iB8wmHsDs0o+n5uhYIrSk+lOx7BXign142m8T0CqX14Ac+TBlXXjhXuE3771Oxbo uoMLL9UeZOmCWf4=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.12) for dmarc@ietf.org; Sat, 29 Apr 2023 11:01:13 -0400
Received: from smtpclient.apple ([99.122.210.89]) by beta.winserver.com (Wildcat! SMTP v8.0.454.12) with ESMTP id 3619288848.1.20596; Sat, 29 Apr 2023 11:01:12 -0400
From: Hector Santos <hsantos@isdg.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Date: Sat, 29 Apr 2023 11:01:01 -0400
References: <CALaySJ+NBg9vzqa0_t-sBf7EKXQ3A=DTyy-Vc7M-ZK9-vfJxmw@mail.gmail.com> <29216533.CRhL9lMF2B@localhost> <3141092.K83ThNGNZP@zini-1880> <CAH48ZfzS+MCC4-Dk3mZhF_bwc9hzWowApgPG3am14bjB9ZDz3Q@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
In-Reply-To: <CAH48ZfzS+MCC4-Dk3mZhF_bwc9hzWowApgPG3am14bjB9ZDz3Q@mail.gmail.com>
Message-Id: <630A8A65-E04D-4C48-AE80-516F610EB93A@isdg.net>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/LCNz73F5C55dp--OYNQA0MlAhkw>
Subject: Re: [dmarc-ietf] Summary: Search for some consensus, was: 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, 29 Apr 2023 15:01:36 -0000

> Given that lists are expected to (A) continue making content changes, and (B) continue accepting all comers, I think we need to embrace From Rewrite as a necessary consequence of A and B.    Unlike Hector, I don't have a problem with From Rewrite because the act of altering the content makes it a new message, and the modifying entity becomes responsible for the whole thing.   So we need a caveat to list owners which lays out the real risks and the better alternatives.


Douglas,

Just a few points.

It is more accurate to state, "Unlike others," because I am not the only one who has a problem with altered mail authorship, and worse, when done for the purpose of a security teardown it potentially introduces a new security threat with Display Name attacks.  I believe I am “IETF” correct to raise this security concern where IETF security folks would agree.
 
It is often stated that it is unfair to MLS/MLM folks who have worked unchanged for over 30+ years to be required to change.  Please understand I have a commercial MLS product since 1996 and I don’t like changes just like the next MLS developer. I’ve extremely conservative but I do adapt when necessary. My MLS is a legacy product but it is still actively supported. 

Well, for the MLS or MLM refusal to adopt the protocol, the refusal to adopt measures known to resolve the DKIM secured with Policy mail stream, caused an immediate need by one MLM to create a hack to alter list submissions from restrictive domains. It resolved the immediate problem. The MLM could have adopted subscription/submission controls as outlined in 2006 and discussed many times in the WGs. It  was not  unknown. These correct methods would have pushed the burden back to the domain seeking exclusive mail security once they began to publish and honor p=reject. The MLM could have supported any of the many ADID::SDID association authorization proposals too, but it did not. So here we are with the DMARC rewrite problem where in my view, needs to be explained and corrected. 

The "new message" angle is one view, but not the definitive one to suggest it is okay to alter list submission copyrighted authorships. It is not a normal thing to do, but what you can do as an MLS/MLM developer depends widely on the type of list distribution. If you are just broadcasting to a list of people as a read-only list, then the preparation of required headers is a legitimate instance where it completes a new secured message with the proper secured business addresses.


—
HLS