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

Alessandro Vesely <vesely@tana.it> Fri, 14 April 2023 17:38 UTC

Return-Path: <vesely@tana.it>
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 4E7F7C151B09 for <dmarc@ietfa.amsl.com>; Fri, 14 Apr 2023 10:38:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=tana.it header.b="0dImiaSH"; dkim=pass (1152-bit key) header.d=tana.it header.b="AtMDxK7n"
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 JbsC-xX6FOq3 for <dmarc@ietfa.amsl.com>; Fri, 14 Apr 2023 10:38:52 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [94.198.96.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3E7C14CE55 for <dmarc@ietf.org>; Fri, 14 Apr 2023 10:38:47 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1681493923; bh=dqyTP6zqC671HEov9ztYByFeSfCnBgAK9MKEN8VPZD4=; h=Author:Date:Subject:To:References:From:In-Reply-To; b=0dImiaSHJUZEjoI1isCtust76kejZR6q8BIiK16663uSeL/SPw8TctTesLc7qZsKj yXY09TL7RjbsV+pKaMsBw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1681493923; bh=dqyTP6zqC671HEov9ztYByFeSfCnBgAK9MKEN8VPZD4=; h=Date:Subject:To:References:From:In-Reply-To; b=AtMDxK7n7XPXIrf4besSQcnGndAHZzOkO9TAsAkMbXosDkpEVGfK3ozUijkdS1v36 Q3xCAoY93cAgcRBJGvN9TacXWE8hLMapoBDxKvwlVxRwgPedXM+1KgN5pAmwxYBOuv mrxnf9G4tS7zx0i00oyknHB1Ba2rCF8rg/mRTdoZE2oGqdPTu785t9pGWavdk
Original-Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
Author: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0CE.0000000064398FA2.0000513E; Fri, 14 Apr 2023 19:38:42 +0200
Message-ID: <f5a510b6-553c-e07c-c249-03a68c3cc60e@tana.it>
Date: Fri, 14 Apr 2023 19:38:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0
Content-Language: en-US, it-IT
To: dmarc@ietf.org
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> <5ABFFAF7-4B03-4CCC-81C2-303A6B6F506E@wordtothewise.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <5ABFFAF7-4B03-4CCC-81C2-303A6B6F506E@wordtothewise.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/sAS-PqbeU0OCYxcXtQqZ_FUTFiU>
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:38:56 -0000

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.


Best
Ale
--