[BEHAVE] RFC6147 and RFC7208 interoperability issues

Klaus Frank <klaus.frank@posteo.de> Sun, 06 February 2022 18:09 UTC

Return-Path: <klaus.frank@posteo.de>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E001A3A0B1F for <behave@ietfa.amsl.com>; Sun, 6 Feb 2022 10:09:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level:
X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, 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 SYAmdhUfjI3s for <behave@ietfa.amsl.com>; Sun, 6 Feb 2022 10:09:19 -0800 (PST)
Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (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 E05883A0B9B for <behave@ietf.org>; Sun, 6 Feb 2022 10:09:18 -0800 (PST)
Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 61A8D240028 for <behave@ietf.org>; Sun, 6 Feb 2022 19:09:16 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1644170956; bh=rnzPtNVVEr4g7RWlAU/mtH90s4IagqICOEYD2omDIy0=; h=Date:To:From:Subject:From; b=gQQA0lmmIEnEDvP7LATptI1VGjJpN716lIDKlOYP4Z60RRemeuiSDOeAS2tLG/GZ2 WpXDBYtNiRk17qd1UYUPp/UD5sJSoLE4nZqGfp6UA2tyWKA2pzLcR1A6JyJ15QQsoK BCC+YVKro2K7vkXwdT7NdAuVvyLb7sFIvHXAqniwF8DyrlaXGDPSTyXcNU956nXTd1 djsl9+aTXeM2YsQggOHYk//O4TaxWi5aMQi01nUQP21uaoM5Te/O7D1Dgmb9GD8fPR WkCiktAm8eVbPDp6+QwCDPVF36l+cGD58waOQ0Rfd7LmwQCU1NLn7QvEmG/G6KfDGA isjOnFp8LgK8A==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4JsHND0CMQz6tmG; Sun, 6 Feb 2022 19:09:16 +0100 (CET)
Message-ID: <45e423cc-4095-cca2-bf8c-aa15e977b19c@posteo.de>
Date: Sun, 06 Feb 2022 18:09:13 +0000
MIME-Version: 1.0
Content-Language: en-US
To: behave@ietf.org, spfbis@ietf.org
From: Klaus Frank <klaus.frank@posteo.de>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms090706070609010002080607"
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/uf_s_Tp7sKf8dlTadnYJKzJ8-IM>
Subject: [BEHAVE] RFC6147 and RFC7208 interoperability issues
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Feb 2022 18:11:41 -0000

Hi,

we had some issues with SPF and a mail server that was behind 
NAT64+DNS64. I at first thought that it was just a misconfiguration. But 
after the DNS64 server seamed to work as intended I went to the 
implementation and the RFC. Thereby while reading RFC6147 I stumbled 
across section 5.3.3 which says "All other RRs MUST be returned 
unchanged." which is the cause of my issues. This section is basically 
ignoring SPF records (RFC7208 section 5.6) and also preventing DNS64 
implementations from addressing this limitation.

Would it be possible to create an extension to RFC6147 that mandates SPF 
record rewrites as well? Otherwise Mail servers behind NAT64+DNS64 in 
IPv6 only environments won't be able to work as expected.

Like:
If the DNS64 server receives a SPF-record (within either the TXT-RR or 
the SPF-RR [RFC4408]) containing the "ip4" mechanism it MUST rewrites 
the ipv4 address according to the same rules as A-records are and 
synthesizes a new SPF record within the response that contains 
additional "ip6" entries. The original "ip4" should not be removed from 
the response.

Sincerely,
Klaus Frank