IETF Logo Mail Archive

Re: [spfbis] RFC6147 and RFC7208 interoperability issues

Alessandro Vesely <vesely@tana.it> Tue, 08 February 2022 14:44 UTC

Return-Path: <vesely@tana.it>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0C73A0E67 for <spfbis@ietfa.amsl.com>; Tue, 8 Feb 2022 06:44:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.812
X-Spam-Level:
X-Spam-Status: No, score=-2.812 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.714, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=9mY4e1w8; dkim=pass (1152-bit key) header.d=tana.it header.b=AQobNAUm
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W541b_7V1OWF for <spfbis@ietfa.amsl.com>; Tue, 8 Feb 2022 06:44:30 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A86E3A0E62 for <spfbis@ietf.org>; Tue, 8 Feb 2022 06:44:16 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1644331450; bh=0Z0MnEYYDi9SMuDVvUB006kSjOl6YcmghliQl4xrDY0=; h=Date:Subject:To:References:From:In-Reply-To; b=9mY4e1w8UzjCyXX2BZ/eBBRMneSuvwPmBH2DgT9LCOdDhkSPXWtBdUtSlOJum0vPX FTPe9/kGVaCkDlI7186CQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1644331450; bh=0Z0MnEYYDi9SMuDVvUB006kSjOl6YcmghliQl4xrDY0=; h=Date:To:References:From:In-Reply-To; b=AQobNAUmcgsMUrOe10SqnQpkQueV4zMl7mlmNq3nTeP1IBL+lTjK1wEeO3n5gAkxA uRPoWrlSJOgRvPbLkRFPMLNfiATLFgRwx0qwVVANJ10UHgsRap4qqsajO6O1+iIzz7 KdZ0mG7lampwKIuORmYM+wk1tI2RyrYSAxWVOSBbqFdbKtWmgAmLWHtIKXjhE
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [192.168.1.108] (host-95-249-175-244.retail.telecomitalia.it [95.249.175.244]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0DD.00000000620281BA.00006AA6; Tue, 08 Feb 2022 15:44:10 +0100
Message-ID: <622e97dd-09ec-21f4-a561-e9aa5328c2bc@tana.it>
Date: Tue, 08 Feb 2022 15:44:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-US
To: spfbis@ietf.org
References: <45e423cc-4095-cca2-bf8c-aa15e977b19c@posteo.de> <DF73F58F-D33E-495A-B18C-58BC994ADE8B@viagenie.ca> <5b5f5a2a-8250-4ee5-3560-80e67b540204@posteo.de> <e061ff19f8bf10bef43399d82a29bee48fbcee5d.camel@16bits.net> <e0f53dcc-a909-9476-691b-84184ba8761c@posteo.de> <b7fe33e0f8982bb5f4560ed546ac35bdff25e03b.camel@16bits.net> <1fc6a0d819c1872624dcae1e15af0384@leibzon.org> <3f9e531c-3b78-2c9d-3776-bf2ab297dead@posteo.de> <20716dc8319f4d931e2346a24ccb4440@leibzon.org>
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <20716dc8319f4d931e2346a24ccb4440@leibzon.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/8fkWVLiEraeNgE-qFUa9G7yvXas>
Subject: Re: [spfbis] RFC6147 and RFC7208 interoperability issues
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spfbis/>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Feb 2022 14:44:47 -0000

On Tue 08/Feb/2022 01:36:31 +0100 William wrote:
> On 2022-02-07 15:31, Klaus Frank wrote:
>> On 2022-02-08 00:22, william@leibzon.org <mailto:william@leibzon.org> wrote:
>>>
>>> SPF macro tricks: 
>>> https://www.jamieweb.net/blog/using-spf-macros-to-solve-the-operational-challenges-of-spf/ 
>>> I wonder how many people actually use SPF macros....
>>>
>> We don't have to. This is all done by the SPF library and we just 
>> need to care about the DNS requests it'll perform because of this. 
>> The new dns queries are also SPF records. And also start with 
>> "v=spf1 ", so no problems as long as we'd rewrite all ip4's within 
>> it and that's the same as we'd already do anyway. Therefore no 
>> change to macros needed.
> The macros don't need to be changed if the library knows real IPv4 
> address.


Right.


> I wonder if there even are people doing ip6 exist macros...


Macros like the one Ángel cited, exists:%{ir}.list.dnswl.org, 
explicitly require to lookup a white list.  RFC 7208 suggest receivers 
do so implicitly, in order to account for forwarding, but not all 
receivers comply.  A white list lookup is required if the record 
terminates with -all.  With IPv6, it is even more required, IMHO.


Best
Ale
--

v2.23.0 | Report a Bug | By Email