IETF Logo Mail Archive

Re: [spfbis] RFC6147 and RFC7208 interoperability issues

Klaus Frank <klaus.frank@posteo.de> Mon, 07 February 2022 02:30 UTC

Return-Path: <klaus.frank@posteo.de>
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 404C43A11CE for <spfbis@ietfa.amsl.com>; Sun, 6 Feb 2022 18:30:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=posteo.de
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 Wj1mchcMJy8c for <spfbis@ietfa.amsl.com>; Sun, 6 Feb 2022 18:30:11 -0800 (PST)
Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) (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 20DE63A11CB for <spfbis@ietf.org>; Sun, 6 Feb 2022 18:30:10 -0800 (PST)
Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id E0B0F240101 for <spfbis@ietf.org>; Mon, 7 Feb 2022 03:30:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1644201008; bh=KiSv9Bneoyv+BtzjAJL2ub3MtSOng0i7ul3yNTME0jI=; h=Date:Subject:To:From:From; b=obSCDuuvcWWBv4+JwuB7TJUtF3e4lrvlWQVEr3/CMPoci7m6ceyEs4S2pWRaAnZzC QN5Ok+FEV/AcJj0GSK08croq3YEB/cNssFW7hGIf9w45X9g0HXh7I0OPDEr78AB8IH BPsONk8DiLsQVIgXwG8aLyYjK1Jl+obhtOt8bJTzFUyZuqNkgIzyfERA4WFEbtQAye BcIJOkoLJbTjOcl9scZoucpbciXA2ibMUJn4qQUKOqNdu5ZA2xmtvtcWbuX87Ndxps 1KgWzpg250Hr+KBXgz323sXbL93ZhUFvgn0oWiRij9HuDa9kz6kAuTy2T9zQbcBme/ z9XinNWQHmR9w==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4JsVV84TDmz9rxG for <spfbis@ietf.org>; Mon, 7 Feb 2022 03:30:08 +0100 (CET)
Message-ID: <e0f53dcc-a909-9476-691b-84184ba8761c@posteo.de>
Date: Mon, 07 Feb 2022 02:30:06 +0000
MIME-Version: 1.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>
From: Klaus Frank <klaus.frank@posteo.de>
In-Reply-To: <e061ff19f8bf10bef43399d82a29bee48fbcee5d.camel@16bits.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms050807070408050004070902"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/gQMPrgb1vR33M2QPgp4c9yLvHlk>
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: Mon, 07 Feb 2022 02:30:18 -0000

Why? Such a query would resolve in the mailserver would make the DNS 
lookup. The DNS64 server than would synthetically add an AAAA-RR to the 
response.

But now when reading the RFC7208 Section 5.7 again. We would need to 
extend that section to also validate the AAAA record. Currently it even 
states the limitation:

    The resulting domain
    name is used for a DNS A RR lookup (even when the connection type is
    IPv6).  If any A record is returned, this mechanism matches.

So the issue here is missing IPv6 support. Nothing no other special 
handling is required by the DNS64 server and it also doesn't need to be 
parsed. But the SPF library would need to also check the AAAA-RR, which 
considering future proving it should be doing anyway...

The DNS64 would only have to rewrite ip4 into ip6.

On 2022-02-07 03:21, Ángel wrote:
> A rewriting DNS64 dns server would need to keep track of spf queries,
> learn that *.list.dnswl.org is special with a %{ir} pattern

v2.23.0 | Report a Bug | By Email