IETF Logo Mail Archive

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

Alessandro Vesely <vesely@tana.it> Tue, 20 June 2023 08:55 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 C772EC14CF1F for <dmarc@ietfa.amsl.com>; Tue, 20 Jun 2023 01:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.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_HI=-5, 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="9YBQ9FQf"; dkim=pass (1152-bit key) header.d=tana.it header.b="AvebGxkf"
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 SDTrEbrjXMnu for <dmarc@ietfa.amsl.com>; Tue, 20 Jun 2023 01:55:31 -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 BAC20C14CF09 for <dmarc@ietf.org>; Tue, 20 Jun 2023 01:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1687251326; bh=916QyovwCr9q5c0wi3OS2k76bIJbI10U+1y4PYCAvn8=; h=Author:Date:Subject:To:References:From:In-Reply-To; b=9YBQ9FQfF9tqBNSMw+3UA6bHRALgc0dqoAHnxRijIVQdRSKdtyO1ctbO31U6Erw2z cVVb4T1YmRA4muh+OFlBw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1687251326; bh=916QyovwCr9q5c0wi3OS2k76bIJbI10U+1y4PYCAvn8=; h=Date:Subject:To:References:From:In-Reply-To; b=AvebGxkf+uJnIYYjyREYbc0VWzMtpSxJcT0HU+ZDcwtkHt+FRU54khJZnwNw7eC0Z PtiLp+Wdozc7zk3Av2F+vpV2+kB9eCn7Oci5kDixDxI5hmUu3N4WRjB51S+vkMpQfc GR4H3PjMkFjA8Fcywso0atbWXdGoBwa9f6ktpMf83+Pya7ka4vd1h2D7C5ana
Original-Subject: Re: [dmarc-ietf] 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 00000000005DC119.000000006491697E.0000549A; Tue, 20 Jun 2023 10:55:26 +0200
Message-ID: <4577ce34-5495-65f9-8a22-59af9597c898@tana.it>
Date: Tue, 20 Jun 2023 10:55:26 +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
References: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de> <D225D7FC-C570-4B63-A694-9F16DB1F33E1@kitterman.com> <CALaySJKwuOK-81dW2H9dtURxa5mLQDUNo+MWcs+Hho8N+yP9qg@mail.gmail.com> <2817813.dRqVH37e0G@localhost> <CALaySJJbPFBAV_7mZaARYWuMzuX+74r2Cm0jD+z92_iuFRn_MQ@mail.gmail.com> <25736.57534.195344.782189@fireball.acr.fi> <1ec42959-977a-9ce0-907a-83a5eb2b6ef2@tana.it> <25739.5435.550786.601699@fireball.acr.fi> <25739.33240.127804.524371@fireball.acr.fi> <5d9a0b0f-8777-2494-d779-376c6ab8b37d@tana.it> <xtudkqv5sqxs4c2nnilna5lf4b266br4xwdjwoq4fdyjpgzjln@xdb5rldfeini>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <xtudkqv5sqxs4c2nnilna5lf4b266br4xwdjwoq4fdyjpgzjln@xdb5rldfeini>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/wH7aO7S5J5Q2YXwltbE4W7wnNuY>
Subject: Re: [dmarc-ietf] 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, 20 Jun 2023 08:55:38 -0000

On Mon 19/Jun/2023 20:42:28 +0200 Patrick Ben Koetter wrote:
> 
> The number of IP addresses in SPF-Records published by VLMPs foils the idea of 
> "a controlled and limited number of host allowed to send on behalf of a 
> senderdomain". Given the (internal routing) challenges you face when you try 
> to publish a limited, dedicated IP range per tenant only, I do not see the 
> current problem we have with SPF, when it comes to use SPF as identity 
> anchor for email authentication, go away in the future.


On the other hand, there are domains whose mail is sent from a small number of 
IPs, exclusively used by such domain's dedicated servers.  SPF works very well 
in those cases.

I'm well aware that the global tendency is to outsource anything IT, including 
mail.  However, I'd continue to support independent sending, avoiding to burn 
bridges behind us.  Gmail security team's proposal, to express allowed 
authentication mechanisms as a policy provides for the best possibilities.  We 
can do it also without a version bump.


Best
Ale
--

v2.23.0 | Report a Bug | By Email