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

Tero Kivinen <kivinen@iki.fi> Fri, 30 June 2023 02:08 UTC

Return-Path: <kivinen@iki.fi>
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 75CBAC14CE5D for <dmarc@ietfa.amsl.com>; Thu, 29 Jun 2023 19:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.1
X-Spam-Level:
X-Spam-Status: No, score=-7.1 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi
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 8AqRN2pmQKzw for <dmarc@ietfa.amsl.com>; Thu, 29 Jun 2023 19:07:56 -0700 (PDT)
Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (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 C638CC151066 for <dmarc@ietf.org>; Thu, 29 Jun 2023 19:07:55 -0700 (PDT)
Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (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) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id 4Qsdxx3gKjzyRy; Fri, 30 Jun 2023 05:07:48 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1688090870; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Rn0ES5rbNy/X/I+t0/ctGza9yKFcqylG+yonN8W04Fw=; b=OCEDPyAiDa65nq0FjeMHB2N48LPeVJWkBJC2LB9pUekG1vjEXMGTRo0MoP2AJt5Non7c1E Mj6DLFrR4uDLLdT1M5aA2uzuv9nc5KF/AvALycPfSUao1ZTVB0IIWexKruVjwxeHpKk+WG ReFO4ptTHDo9iK1vHIUlxFbOHQwsZC8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1688090870; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Rn0ES5rbNy/X/I+t0/ctGza9yKFcqylG+yonN8W04Fw=; b=wDL9YvQtOZLxkGnAqNErT3m0FZoDUbDO+0KMWA5G7+ChDRnMq1NkFuPxQDQbD+2d3M34TL DcRtHHfBxIvDzETwopgdnTWFHaYLVl+FCN9j1k+Ti6tz+/Cn00nqbsr88PfuOwd7aCPmfT 3SXJ2WwDn3kMGZoY+y5cAbMqVE3/v68=
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi
ARC-Seal: i=1; s=meesny; d=iki.fi; t=1688090870; a=rsa-sha256; cv=none; b=x2e8Z3PIOEyQ3UZn1+GaFZ+5gCFLHwhWLwp3sUBv4nycPuCeDabOblrqiFS5Jdl9dixP8J tJOf4rJZjv7Cx99of8frDXVtS+f1LYA0DHsiIlIKMWGZMGO1pB1UVtngrDZhxLKWVOl4BC Cahei04zLnvUrSuaZTIRjTBRYg2YTZk=
Received: by fireball.acr.fi (Postfix, from userid 15204) id 5411B25C130D; Fri, 30 Jun 2023 05:07:46 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <25758.14578.231174.628994@fireball.acr.fi>
Date: Fri, 30 Jun 2023 05:07:46 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Alessandro Vesely <vesely@tana.it>
Cc: dmarc@ietf.org
In-Reply-To: <89205d6b-4d5b-326e-c0d6-a6001997ab9c@tana.it>
References: <20230623021810.E5F8DF9B3B94@ary.qy> <6495D504.4090809@isdg.net> <839aa10b-f7fa-c7a2-76db-6441189afca2@dusatko.org> <CALaySJ+gcVvpzJcrpUbOkOvjUFAhzw=pZovpZC7BhW_x7VW7nA@mail.gmail.com> <b78cb14a-d641-fabd-a67c-f099b8fae3f9@tana.it> <CAH48Zfwm4YZ1Px4NG-Vo8n-S1Gj7vps=JrYw0-zyHx4N8qWhkw@mail.gmail.com> <89205d6b-4d5b-326e-c0d6-a6001997ab9c@tana.it>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 6 min
X-Total-Time: 5 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Ilte21dZWRAZoAe6qeSpqv6NK2o>
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: Fri, 30 Jun 2023 02:08:00 -0000

Alessandro Vesely writes:
> On Mon 26/Jun/2023 19:32:53 +0200 Douglas Foster wrote:
> > DKIM+SPF says "our domain, including subdomains covered by this policy,
> > will never use an ESP".  (Since most ESP messages pass SPF based on the ESP
> > domain)

That is incorrect. It would also mean we will NEVER send email to
anybody who would want to forward that email to some other place. How
is that adminstrator putting the DKIM+SPF policy be sure of that? If
they ever send any emails to customers, contractors, friends etc, they
can never be sure those emails are not forwarded, thus they can't say
DKIM+SPF.

I can easyly see some big companies wanting to lock in their customers
by making it hard to change email addresses, but we should build or
protocols for those companies, but instead allow freedom of movement
where people are reading their emails. 

> ESPs can provide include files for those who wish otherwise.

I know that some companies in finland has included the iki.fi
IP-addresses ranges to their SPF records, because they had several
complains from people of SPF failures when they were sending emails to
iki.fi addresses. We even added _spf.iki.fi DNS record for them to use
for their include when it was requested, but I do not consider that
good practice for solving issues of the SPF.
-- 
kivinen@iki.fi