IETF Logo Mail Archive

Re: [BEHAVE] [spfbis] RFC6147 and RFC7208 interoperability issues

Klaus Frank <klaus.frank@posteo.de> Sun, 06 February 2022 18:39 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 DF22B3A0BD2 for <behave@ietfa.amsl.com>; Sun, 6 Feb 2022 10:39:38 -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=unavailable 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 plaGAFho4c6Q for <behave@ietfa.amsl.com>; Sun, 6 Feb 2022 10:39:34 -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 331973A0BC7 for <behave@ietf.org>; Sun, 6 Feb 2022 10:39:34 -0800 (PST)
Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 128C2240104 for <behave@ietf.org>; Sun, 6 Feb 2022 19:39:29 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1644172770; bh=I/aY/IYgRgULIB2gSLLAwr8r25mFrw3zRCHbekGhddk=; h=Date:Subject:To:Cc:From:From; b=DV4pkqeNtGOpMn+/qJq98FBpj9r3FDq0UCLe6C1DWAgynUUcJj3u1WbaFI3ViQn+T vRkRapUtsV/Bu+KVtnFTJh3Z0Z4R5CriAvZ/hk8YJ6ZcVEDYOTJ0fOGQLrsIFlweaR BkuNJLD4j+uf9cvhCNaczDcrdg3sEjt21vEXNLG7SvOpM3tN1xBp2bhp1NFce3FoPX 8/AdHqd2B9Q2XNzCaopSycZzadIA2lh9IkTe1MNR8TIT2uhJfbDwpZLFYTuKHZgfAB q0/a8qy3W+WRe6rm8A6nZCM6m+7T+VrhMJHAf8mx9axj3VHCWWIFFKqOhVudddyuRo 7Xe8kukrGI5JQ==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4JsJ344PYDz6tn9; Sun, 6 Feb 2022 19:39:28 +0100 (CET)
Message-ID: <5b5f5a2a-8250-4ee5-3560-80e67b540204@posteo.de>
Date: Sun, 06 Feb 2022 18:39:28 +0000
MIME-Version: 1.0
Content-Language: en-US
To: Marc Blanchet <marc.blanchet@viagenie.ca>
Cc: behave@ietf.org, spfbis@ietf.org
References: <45e423cc-4095-cca2-bf8c-aa15e977b19c@posteo.de> <DF73F58F-D33E-495A-B18C-58BC994ADE8B@viagenie.ca>
From: Klaus Frank <klaus.frank@posteo.de>
In-Reply-To: <DF73F58F-D33E-495A-B18C-58BC994ADE8B@viagenie.ca>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms040107010609050604040605"
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/lFi0HHSMhTlUMWua5VfQvRg0JfA>
Subject: Re: [BEHAVE] [spfbis] 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:39:39 -0000

On 2022-02-06 19:35, Marc Blanchet wrote:
>> Le 6 févr. 2022 à 13:09, Klaus Frank <klaus.frank@posteo.de> a écrit :
>>
>> 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.
> I agree there is a problem. However, I can think of “interesting” problems to solve, like: what if the ip4 contains a prefix, like 192.168.1.0/25. How would you translate this into IPv6 prefix by the DNS-64?
Literally, your address of 192.168.1.0 would be e.g. ::ffff:c0a8:0100 
and the prefix would just be 25+96
>
> Marc.
>
>> Sincerely,
>> Klaus Frank
>>
>> _______________________________________________
>> spfbis mailing list
>> spfbis@ietf.org
>> https://www.ietf.org/mailman/listinfo/spfbis

v2.23.0 | Report a Bug | By Email