IETF Logo Mail Archive

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

Alessandro Vesely <vesely@tana.it> Fri, 16 June 2023 11:24 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 60C55C14CE5F for <dmarc@ietfa.amsl.com>; Fri, 16 Jun 2023 04:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 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_MED=-2.3, 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="rG6T2ydb"; dkim=pass (1152-bit key) header.d=tana.it header.b="Aey1LAXk"
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 5_JdVFi9Yop4 for <dmarc@ietfa.amsl.com>; Fri, 16 Jun 2023 04:24:17 -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 0B80AC14CF17 for <dmarc@ietf.org>; Fri, 16 Jun 2023 04:24:14 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1686914653; bh=1FdZtRbv+yV7Uh9YtRcLt0zVOy7+wsCHbRtR+M4AcdM=; h=Author:Date:Subject:To:References:From:In-Reply-To; b=rG6T2ydbilN7bH7+S1jyRLMYlkz0pIxUnSawaVjrnML8Vi1MZARcWmTYNU0CEhGaZ CXbR4YNvjPQHfS2TapUAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1686914653; bh=1FdZtRbv+yV7Uh9YtRcLt0zVOy7+wsCHbRtR+M4AcdM=; h=Date:Subject:To:References:From:In-Reply-To; b=Aey1LAXk6hvJ7szTvpOxOebpCgViB3WzvK7PgzBLPF7OVzm2EC0yU5rbobg6lasjE 5wv+6o18/Zx0o1QMr6D8y4cN87HL/PtuIDQoBCO4APxnmjEoe4vKbZy99R9L6MEHa3 XEgewYVC6b7q+zUmr1eyMGFwmhH5t+dhP4SPdmAPXLdpT+/0VjAl6IxF5lpHP
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 00000000005DC13D.00000000648C465C.00005684; Fri, 16 Jun 2023 13:24:12 +0200
Message-ID: <1aa61e5f-4ef7-8819-0d21-b4e895e67d93@tana.it>
Date: Fri, 16 Jun 2023 13:24:12 +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> <7d39aa8e-dacc-05fa-eff1-2cc350d521db@inboxsys.com> <CAH48ZfwyBwfKzG_3R5uyV6tmY0yUtWy=5yAoAOEhUGn_Rz6HNw@mail.gmail.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <CAH48ZfwyBwfKzG_3R5uyV6tmY0yUtWy=5yAoAOEhUGn_Rz6HNw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/a1RoCHhlIrcFWFzTAqiEK9CWkz8>
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: Fri, 16 Jun 2023 11:24:23 -0000

On Fri 16/Jun/2023 13:02:46 +0200 Douglas Foster wrote:
> The solution is to talk about the differences in confidence provided by the 
> different authentication methods, and note that evaluators have reason to 
> distrust some of them.   That distrust could cause a weakly authenticated 
> message to be distrusted by some evaluators.

SPF reliability is not something that an evaluator can automatically learn, at 
least not straightforwardly.  Overbloated SPF settings can make impersonation 
possible, thereby betraying DMARC intent.  Concerned domains should be advised 
to not include such stuff in their SPF record.

If someone set +all in their SPF record, then anyone is authorized to send mail 
on their behalf.  It is not an evaluator's job to syndicate their policy.  The 
problem arises if —as someone voiced— there are cases where a domain is somehow 
forced to publish a bloated SPF record, yet doesn't want to be freely 
impersonated and seeks DMARC protection.  Do such cases exist?


Best
Ale
--

v2.23.0 | Report a Bug | By Email