Re: [dmarc-ietf] Signaling MLMs

Alessandro Vesely <vesely@tana.it> Fri, 14 April 2023 17:20 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 B1C1AC1522BE for <dmarc@ietfa.amsl.com>; Fri, 14 Apr 2023 10:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 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, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_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="xbc6wpDa"; dkim=pass (1152-bit key) header.d=tana.it header.b="Di1EtTDP"
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 3Isn8NaISgHZ for <dmarc@ietfa.amsl.com>; Fri, 14 Apr 2023 10:20:34 -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 93481C151B09 for <dmarc@ietf.org>; Fri, 14 Apr 2023 10:20:30 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1681492828; bh=fxv5i2ep7WrsI7nrYMpMzpO86dN9wBmXTGRw3GI3CNU=; h=Author:Date:Subject:To:References:From:In-Reply-To; b=xbc6wpDagLIM+c0UGf8lKqkUWVUryfzdM7eqyoB1rB/YBO5975A/hQkmTxed0ELHU Rm0hqtrX3DLbboTRy+FBw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1681492828; bh=fxv5i2ep7WrsI7nrYMpMzpO86dN9wBmXTGRw3GI3CNU=; h=Date:Subject:To:References:From:In-Reply-To; b=Di1EtTDPBItOJNutYSh14hi3HyS8eZr1giJsoiiAb9vxBCFsK+xh3xIHuzLQHdlAy bh9ck/BV3yBbzCGZ/XePhfDmTSB8qktP/xVIMH1eMuaMtwGIDTvVDKohaYMlZ0/zHX aozeJY5gdeT/kP+rjgnweVLhBFaSnkwYUWZfJrdFXY1rYKS69m0ecwwzwFQwS
Original-Subject: Re: [dmarc-ietf] Signaling MLMs
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.0000000064398B5C.00004E1E; Fri, 14 Apr 2023 19:20:28 +0200
Message-ID: <329db752-fdeb-7633-ede1-06e435db1c0e@tana.it>
Date: Fri, 14 Apr 2023 19:20:28 +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: <CAL0qLwZc2X7tyP+_8vvL3Yb7uJk6td3XGbsXUB68BNUEMhV4yQ@mail.gmail.com> <8d970e6b-8fa7-da85-5c47-d485abbc43be@crash.com> <CAL0qLwZJjBq0T8kODJifTT10ttJJE2Bof5kJZACRTwyauzwQ6A@mail.gmail.com> <CAJ4XoYcHeFe0kS9QHz4fP5TbOMOiW8mJaiNYx+Yk8keZYW-yDQ@mail.gmail.com> <b6a2b444-de02-9833-fe7b-fc9ad542f900@tana.it> <CAL0qLwYwcXTBzqd=3sKwtZJUsEYO5kfv9V-CZtVHz2TQ78v=0g@mail.gmail.com> <909C826B-2745-4BE8-AD16-920E6DE86D1C@kitterman.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <909C826B-2745-4BE8-AD16-920E6DE86D1C@kitterman.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/-MJEUsc__inqXDyUHosRPw_zuGc>
Subject: Re: [dmarc-ietf] Signaling MLMs
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:20:42 -0000

On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
> On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" <superuser@gmail.com> wrote:
>> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely <vesely@tana.it> wrote:
>>
>>> Heck, MLMs should start rejecting messages sent from domains that publish a 
>>> blocking policy *when they fail authentication on entry*!!
>>
>> That's not enough to avoid the damage we're talking about.


Agreed.  Yet, it is a sane half-way between crazy rejecting always and 
completely ignoring ABUSE.


>>> From: rewriting is the de-facto standard.  In DMARCbis we can only 
>>> substitute "de-facto" with "proposed".  Better methods, implying 
>>> different, possibly experimental, protocols are to be defined in 
>>> separate documents. >>
>> Are you suggesting we put that forward as our Proposed Standard way of 
>> dealing with this problem?  It's been my impression that this is not a 
>> solution that's been well received.


I agree there are better solutions, but they're not yet developed.  As ugly as 
it may be, From: munging is the emerged solution.  It is a _fact_.  Now repeat 
again that the IETF standardized facts, not theories...


>>> Let me recall that when I proposed something like that, I was told that 
>>> that was phase II and the WG was then already in phase III.  So, let's 
>>> complete DMARCbis /without cannibalizing the spec/ by saying that it 
>>> MUST NOT be used (as it is being used already).
>>
>> What you describe as "cannibalizing" is actually a matter of presenting the 
>> correct normative advice about interoperability.


It is nonsensical.  It means DMARC is only useful for looking at the reports. 
If that's really what we think, we'd be better off deprecating p= completely. 
Otherwise, let's wait until next April 1st and publish it as such.  It's 
ridiculous.


>>  So I don't agree at all with that characterization.
> 
> Agreed.  If people can't get over saying some domains will have 
> interoperability problems when that's demonstrably a technically accurate 
> statement (and I don't see anyone claiming it isn't), I don't see how 
> progress is possible.

I agree that we have to say that some domains have interoperability problems as 
a consequence of DMARC.  Let's say that MLMs MUST do From: munging unless (or 
until) better solutions arise, or unless they don't alter messages.

We're proposing email authentication, not anything less.


Best
Ale
--