From nobody Mon Feb 14 19:48:50 2022 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EF83A0A80 for ; Mon, 14 Feb 2022 19:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 (1024-bit key) header.d=isc.org header.b=QlLAujRs; dkim=pass (1024-bit key) header.d=isc.org header.b=o1XkW5PJ 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 ewOmEbNcUcno for ; Mon, 14 Feb 2022 19:48:43 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3673A0A7D for ; Mon, 14 Feb 2022 19:48:42 -0800 (PST) Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id C9FA13AB009; Tue, 15 Feb 2022 03:48:41 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org C9FA13AB009 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1644896921; bh=IwydvM37Iu4AFJQzPKr8cjH1rBN7e9s9kDSu46DbgmU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=QlLAujRs1KHw9CqiEVlvz4xWh7EkT3j8iaiCzNtVT/uvLbnX7EKuALVhrxv/Ag9uT bOyuQW9HUSuxogDctPZOfcxDP/pCPv/bym4TMOstn24eaXc/VB7jomRzA3sz+a8XWc u9LsDZ8AuL0cpwj61P0Ba/AgPQlRUKCxYzOnNBO0= Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id B9C70FE8269; Tue, 15 Feb 2022 03:48:41 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 80332FE826D; Tue, 15 Feb 2022 03:48:41 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 80332FE826D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1644896921; bh=yuQIf5PGuMzrRNEc8/F2+Y+MabttzLh76Aa588DsKPg=; h=Mime-Version:From:Date:Message-Id:To; b=o1XkW5PJfvr0+yE+nHWnQOcvGGXIZuxPjo84dnXXBP4wPwZggVbMiJ88B/pZ43gEh HMXSJK4X/90pJvDfx8sYr3TWfXpprxtMgiUnmuWeqPHCKdXdum7Gu0SyQqV2w5/L2N FjpVwHELMjwTqcvCUzjW5lIaIm1FsgLhP8LT+pzI= Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AFD-M2nfioWm; Tue, 15 Feb 2022 03:48:41 +0000 (UTC) Received: from smtpclient.apple (n114-74-26-107.bla4.nsw.optusnet.com.au [114.74.26.107]) by zimbrang.isc.org (Postfix) with ESMTPSA id CB282FE8269; Tue, 15 Feb 2022 03:48:40 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Andrews In-Reply-To: Date: Tue, 15 Feb 2022 14:48:37 +1100 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <32A108DF-E4B9-4D54-82FE-90B95C7BCB42@isc.org> References: To: Klaus Frank X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [v6ops] I-D An Extension to DNS64 for Sender Policy Framework SPF Awareness X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2022 03:48:48 -0000 As I noted in dnsops, there is no way for the DNS64 resolver to achieve = the aims of this draft when the SMTP client is dual stacked. Handling a: and mx: methods depend on A=E2=80=99s = being mapped to AAAA which does not happen for dual stacked clients with DNS64. The presence of the AAAA records will stop = AAAA=E2=80=99s being synthesised from A records. Mark > On 14 Feb 2022, at 19:53, Klaus Frank wrote: >=20 > Hi, >=20 > I wrote an I-D for updating DNS64 to better work for MTA operators. = I'd like to get your opinions on that as some guidance on how to move = forward with it (sorry I'm new to the process). Some background for this = 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 themselves. After some = discussion on the behave and spfbis mailing list I created this I-D. I = was referred to this mailing list as both the behave as well as the = spfbis WG are closed. >=20 > GitHub: = https://github.com/agowa338/IETF-RFC-drafts/blob/main/draft-frank-dns64-sp= f-extension-03.xml >=20 > Sincerely, > Klaus Frank >=20 > Name: draft-frank-dns64-spf-extension > Revision: 03 > Title: An Extension to DNS64 for Sender Policy Framework SPF = Awareness > Document date: 2022-02-14 > Group: Individual Submission > Pages: 6 > URL: = https://www.ietf.org/archive/id/draft-frank-dns64-spf-extension-03.txt > Status: = https://datatracker.ietf.org/doc/draft-frank-dns64-spf-extension/ > Html: = https://www.ietf.org/archive/id/draft-frank-dns64-spf-extension-03.html > Htmlized: = https://datatracker.ietf.org/doc/html/draft-frank-dns64-spf-extension > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-frank-dns64-spf-extension-03 >=20 > Abstract: > This document describes interoperability issues and resolutions > between DNS64 and SPF records for mail transfer agents. This > document also aims to simplify the IPv6 migration for mail transfer > agent operators. >=20 > This document updates [RFC6147] and [RFC7208]. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org