Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

Alessandro Vesely <vesely@tana.it> Tue, 27 June 2023 10:36 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 7D5B3C1522CD for <dmarc@ietfa.amsl.com>; Tue, 27 Jun 2023 03:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level:
X-Spam-Status: No, score=-7.099 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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="mnDUhh6U"; dkim=pass (1152-bit key) header.d=tana.it header.b="AOesygsc"
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 3l1JqH0N-a86 for <dmarc@ietfa.amsl.com>; Tue, 27 Jun 2023 03:36:02 -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 50BD4C14F74A for <dmarc@ietf.org>; Tue, 27 Jun 2023 03:35:59 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1687862158; bh=K3VSmFPmh1nvFbfFN3BXKnH0GnGuWCRzK9TW97LX7X0=; h=Author:Date:Subject:To:References:From:In-Reply-To; b=mnDUhh6UxTQrc4VswBeCj0g6EwHdtRla7eci4aIhIwfeS7NtuokKXG3jpPEkhI11d kL9vkX8X3Rl3PTmzSMpCw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1687862158; bh=K3VSmFPmh1nvFbfFN3BXKnH0GnGuWCRzK9TW97LX7X0=; h=Date:Subject:To:References:From:In-Reply-To; b=AOesygscnF/lpGH1vFkQFVWWdObexO9k257L+wb0E64Ouvn488nJSdjnnnZHaQW9r Z05Btx57WZFnperlx0Gcb+U8mR5kTX3j9Geyr8VJRRk429npXdeoOLov1EvXiDs8s9 R0hGMXsu1QKL9S4x883/OKgfz2+yZ/uBQtXgmgMkfy5KEI5S1cd5VOxW0/AUT
Original-Subject: Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
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 00000000005DC04A.00000000649ABB8E.00002C30; Tue, 27 Jun 2023 12:35:58 +0200
Message-ID: <99e1ef2d-053b-8cfe-f369-fa8475d142ae@tana.it>
Date: Tue, 27 Jun 2023 12:35:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US, it-IT
To: dmarc@ietf.org, Barry Leiba <barryleiba@computer.org>
References: <20230623021810.E5F8DF9B3B94@ary.qy> <6495D504.4090809@isdg.net> <839aa10b-f7fa-c7a2-76db-6441189afca2@dusatko.org> <CALaySJ+gcVvpzJcrpUbOkOvjUFAhzw=pZovpZC7BhW_x7VW7nA@mail.gmail.com> <CAL0qLwasxzqJt7Hr7gZd86C=ivCrDUci_i6pkJJUTnqzL1pHMA@mail.gmail.com> <CALaySJ+gjR6D-OSE_07iSH2zXa7wypUQwPN1cL-1s+NC2S4L8g@mail.gmail.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <CALaySJ+gjR6D-OSE_07iSH2zXa7wypUQwPN1cL-1s+NC2S4L8g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/K9DPSGJyLbs4P3_yXUe9itdug2Q>
Subject: Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
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: Tue, 27 Jun 2023 10:36:11 -0000

On Mon 26/Jun/2023 20:13:53 +0200 Barry Leiba wrote:
> I'm saying I don't want "and" to be an option, because I think it's
> damaging to DMARC.  There is no reason anyone should ever want to say
> that, and providing the option asks for misconfigurations because
> people think it's somehow "more secure".  It's not more secure.  It
> would be very bad for deliverability of legitimate mail and would
> provide no additional security.  It would be a terrible mistake.


I've been sporting spf-all for years, and seldom experienced bounces, mostly 
due to misconfigured secondary MXes.  Out of 39 domains whose posts to this 
list in the past year are still in my inbox, 14 have spf-all.  So, while I'm 
not the only one, not many published -all even though it may seem to be somehow 
more secure.

I think it can be worth to compare SPF and DMARC.  Another sender policy a 
decade and an authentication method after.  What adoption, what hype.

Both policies ask receivers to reject a domain identifier in some cases.  RFC 
7208 explicitly suggests to consider whitelisting (Appendix D).  DMARC provides 
for overrides but is less clear about how to handle exceptions.  After SPF 
broke forwarding, the reaction was split between some changing identifier and 
turning to ~all; after DMARC broke mailing lists, between changing identifier 
and not altering messages.  In my limited experience, the ratio seems to be 
higher for DMARC than SPF, but I may be wrong.

In theory, domains that currently have a strict DMARC policy and spf-all, 6 of 
the above, should have their messages blocked when either method fails, up to 
changing identifiers.  Why would it be so bad for deliverability to 
additionally require DMARC alignment, which is the difference between that and 
the "and"?

And, it seems to me that an ESP not having a bloated SPF record could stop a 
good deal of DKIM replay by resorting to auth=dkim+spf.  Besides collateral 
deliverability problems, why wouldn't that work?

Wht would "and" damage DMARC more than -all damaged SPF?

I hope we can discuss detailed criticism rather than vague ostracism.


Best
Ale
--