IETF Logo Mail Archive

Re: [spfbis] RFC6147 and RFC7208 interoperability issues

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 07 February 2022 18:39 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 9D5A73A112E for <spfbis@ietfa.amsl.com>; Mon, 7 Feb 2022 10:39:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=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=yitter.info header.b=ey0UCbhF; dkim=pass (1024-bit key) header.d=yitter.info header.b=hG6kQjHO
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 smpez76UAJSC for <spfbis@ietfa.amsl.com>; Mon, 7 Feb 2022 10:39:43 -0800 (PST)
Received: from mx5.yitter.info (mx5.yitter.info [159.203.31.152]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41FBF3A10D7 for <spfbis@ietf.org>; Mon, 7 Feb 2022 10:39:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx5.yitter.info (Postfix) with ESMTP id 329CFBD5C8 for <spfbis@ietf.org>; Mon, 7 Feb 2022 18:38:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1644259125; bh=kso+dcZfI+tSWdM6Am7oGQZn8s86oclza1LEc8yxMAU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ey0UCbhFdcuM7VyME8/T96I0MCdfLZMkq/2bAQbpucQEyQVvDgucMwo9VW+eQZrRp XQu5WzAuoJxT2gqcVbaz+xwex94keTUX4lq+82wnAuCOwreY5E/dGSkV1ApdzW1YDV kW34zaJIEA700xgqrJwOTXiCe9s+AoIW/ESeisi8=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx5.yitter.info ([127.0.0.1]) by localhost (mx5.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMVfDbGEiyTm for <spfbis@ietf.org>; Mon, 7 Feb 2022 18:38:43 +0000 (UTC)
Date: Mon, 07 Feb 2022 13:38:41 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1644259123; bh=kso+dcZfI+tSWdM6Am7oGQZn8s86oclza1LEc8yxMAU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=hG6kQjHOe9EBQg3PNcc681CMIN4Uae6qBFNiDo9zE3bGXELVzF3aBRBmIdXGC7KL3 WlyR6IEPstsOISDZkJhWNthbbDUllDSI6gxgPsBzSCBx+ffpp8rjvXt0mtVSbTEc9S 1SgADXPvvyJkru+4q5unxpmqY9b86TjXoJKI2+Lw=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: spfbis@ietf.org
Message-ID: <20220207183841.jhx67gokm63xp2d3@crankycanuck.ca>
Mail-Followup-To: spfbis@ietf.org
References: <20220207175206.rfxlt5s5rxhubjyg@crankycanuck.ca> <20220207182947.92BB13670E02@ary.qy>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline
In-Reply-To: <20220207182947.92BB13670E02@ary.qy>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/EFZIuDNFvEZPdOUCysvapdBBMmo>
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 18:39:49 -0000

On Mon, Feb 07, 2022 at 01:29:46PM -0500, John Levine wrote:
>Of course, if you can expect the endpoint to know that much about
>what's going on, you might as well skip the DNS hackery ahd do the
>address translation in the endpoint's socket routines. I probably
>should stop now lest someone think that was a serious suggestion.

There's effectively a mode for that in RFC 6147: it's called DNS64 in
stub-resolver mode, and it's really the only way to get validation on
the endpoint working.  I spent a fair amount of time thinking about
that sort of thing, and it's what convinces me you can't really build
the scaffolding correctly in DNS64 to handle embedded v4 literals in
TXT records.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

v2.23.0 | Report a Bug | By Email