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

Laura Atkins <laura@wordtothewise.com> Wed, 12 April 2023 11:41 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 E0871C15154E for <dmarc@ietfa.amsl.com>; Wed, 12 Apr 2023 04:41:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.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, 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=ham 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 iKTZ4t_iGZC6 for <dmarc@ietfa.amsl.com>; Wed, 12 Apr 2023 04:41:29 -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 93735C1516EA for <dmarc@ietf.org>; Wed, 12 Apr 2023 04:41:29 -0700 (PDT)
Received: from smtpclient.apple (unknown [176.61.50.187]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 5186F9F21A for <dmarc@ietf.org>; Wed, 12 Apr 2023 04:41:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1681299688; bh=WdrCQXMWx7oGoyOi+lFxYMMeI6PYCYThU6Zu3ynvpUo=; h=From:Subject:Date:References:To:In-Reply-To:From; b=KxhfbhovPfBm5RXJoeBr5/aM+IUjaYBSnuZ7yYyCYgjbS2e5kX6bz4kJ7wkiVEpUk ohxDa81YLQ7LgvlgjCRG+EWGy5xerkIf6RwIDylJgqm5BIsv+aadlSqbRcaJvLszT1 A+Iqr6F4bOFlu5d8e3tmvWjcJeO1SGhlRK7lFoLQ=
From: Laura Atkins <laura@wordtothewise.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E96A25FA-E7F4-425F-B456-B4EA6ED7D891"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Date: Wed, 12 Apr 2023 12:41:16 +0100
References: <CALaySJ+NBg9vzqa0_t-sBf7EKXQ3A=DTyy-Vc7M-ZK9-vfJxmw@mail.gmail.com> <13603D87-4FDE-4768-9712-E6DB0818C802@kitterman.com> <CALaySJLY-9O1Wauk50WMMobNs3cKUzmB+=np080nYCHEZa32UA@mail.gmail.com> <3129648.WqDQmVRvLn@localhost> <CAJ4XoYe3Z8=G8H6hQFuiMMwfZQt1JvLpK3bQmrtGCz=b-w=CJA@mail.gmail.com> <86E22FA6-759F-40F3-AEA3-119EE90F64A0@kitterman.com> <80086446-effa-7ee2-91c7-1f44449d92fb@tekmarc.com> <CAL0qLwaKO5A_OSjod00msw+8EALOUqYzeXb_aPjVhQ2R1wZKJg@mail.gmail.com> <def03c2f-25ec-d3f1-1ea5-678b16369f61@tana.it> <8D2F4B6A-2E72-4763-8B1F-719236B21D1E@wordtothewise.com> <CAH48ZfxP3F0jueQwsFyXBUojQryO2NOhCZzKxbLiZMHW3h10Zg@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
In-Reply-To: <CAH48ZfxP3F0jueQwsFyXBUojQryO2NOhCZzKxbLiZMHW3h10Zg@mail.gmail.com>
Message-Id: <5ABFFAF7-4B03-4CCC-81C2-303A6B6F506E@wordtothewise.com>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/rTViUvcL04ROT3EDzBdKj6iBH3s>
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: Wed, 12 Apr 2023 11:41:34 -0000


> 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.

> 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. 

> But does your domain require even headers toi 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. 

> 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. 

laura 

> 
> Doug Foster
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, Apr 12, 2023 at 6:23 AM Laura Atkins <laura@wordtothewise.com <mailto:laura@wordtothewise.com>> wrote:
>> 
>> 
>>> On 12 Apr 2023, at 10:45, Alessandro Vesely <vesely@tana.it <mailto:vesely@tana.it>> wrote:
>>> 
>>> On Sun 09/Apr/2023 09:50:46 +0200 Murray S. Kucherawy wrote:
>>>> Mike Hammer asks, reasonably, whether an IETF standard containing a "MUST NOT" that we know people will ignore calls into question the IETFs relevance or legitimacy.  But I submit that the IETF issuing a standards track document which fails to take the strongest possible stance against deploying DMARC in a way that knowingly imposes substantial breakage, for any reason, is irresponsible and is the greater threat to our legitimacy.  Keep in mind that improper deployment of DMARC results in damage to innocent third parties: It's not the sender or the MLM that's impacted, it's everyone else on the list.  It's breathtaking to me that we can feel comfortable shrugging this off under the banner of "security" or "brand protection".
>>> 
>>> 
>>> It is not clear whether the damage is caused by those who publish p=reject rather than by those who honor it.  For the protocol to work, both are needed.
>>> 
>>> History ratified that mailing lists are the refractory element.  At the time, John compiled a list of possible DMARC workarounds[*].  Out of inertia, From: rewriting emerged as the de-facto standard.  It works.  It's amendable, though; there are cooperative solutions for example.  And ARC.
>>> 
>>> Rather than considering how to better the coordination between senders and receivers, we disregard the mailing lists adaptation as undue.  Thus we're stuck at crossroads.  DMARC breaks mailing lists.  SPF breaks forwarding.
>>> 
>>> For a possible way forward, senders can coordinate with receivers by identifying mail streams, pivoting on users who subscribe to mailing lists or require forwarding for email address portability.  Just like the classic, one-sided whitelisting of specific email addresses, but using email authentication.
>>> 
>>> Can we stop longing for the 1980s?  Let's accept the damaged we caused.  It's been mended already.
>> 
>> I would disagree that the mailing list adaptation (header rewriting) works well and is benign. In fact, it causes problems for list participants. From my own experience: 
>> 
>>  It makes it difficult to implement filters based on poster address. 
>> 
>> It makes it difficult to search for posts by certain authors. 
>> 
>> It makes it difficult to respond to someone privately or to reach out to them for non-list related reasons. 
>> 
>> It can even make it difficult to identify who is speaking as some folks don’t sign their messages and they don’t provide .sig files to identify them. 
>> 
>> laura 
>> 
>> -- 
>> The Delivery Experts
>> 
>> Laura Atkins
>> Word to the Wise
>> laura@wordtothewise.com <mailto:laura@wordtothewise.com>		
>> 
>> Email Delivery Blog: http://wordtothewise.com/blog	
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org <mailto:dmarc@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dmarc
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
laura@wordtothewise.com		

Email Delivery Blog: http://wordtothewise.com/blog