Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

Keith Moore <moore@network-heretics.com> Mon, 07 February 2022 02:24 UTC

Return-Path: <moore@network-heretics.com>
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 390D03A11D6 for <behave@ietfa.amsl.com>; Sun, 6 Feb 2022 18:24:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com
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 jSn5-eLU6fJC for <behave@ietfa.amsl.com>; Sun, 6 Feb 2022 18:23:58 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58EBA3A120B for <behave@ietf.org>; Sun, 6 Feb 2022 18:23:49 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id AE4ED5C00B9; Sun, 6 Feb 2022 21:23:48 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 06 Feb 2022 21:23:48 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=KrcfDB4EQUGU1ZwDHOu0LLjUkZSoC7yMZuAA1NH9ho0=; b=lh1l89v4 HBxZKW59Ew9BX8wNaNmSafL1GBhBsHD8P/WDTTcihvyU7hLngNOjoxwUeOY9VPFD DadjsPrNZPk5fFQ6SYdaAW3nw/sIcPU7W3EKCcMB+TEm9e9sqZ8fWa5mXnx34/Pw AURNo1EMG0NirMyjjpsooAnjnG12heCjoQ7O1QdHgQhnjbDkMGzHrKIMnu2uei61 Kl87GikRIhaSTFE+PsX4Kw31dC9oGBxX08/VFEalvoMUYIN7qzGSh1zieqVMiR8V rCZ3clJOUDh6cQ0pVgrRAJT04jr12eIgDPYy1rKEyX2T5Lgwk46Nx/Tufl68olDB LfRfuhFl4LWU5Q==
X-ME-Sender: <xms:tIIAYvRvhCC6T2B-7aEHbE4zZjDEE88shCMSXOdZM_AOFuhqJRr2tg> <xme:tIIAYgz_3ukzqjtkX-4Jppjh-vJ2u_Hp_xkajhQO7V9reb8ROLNcZ9epIZ0tVtwJv d8yGgvnRcVk0Q>
X-ME-Received: <xmr:tIIAYk24h2tzCAfxHUAK4wIMjZNMFTc-w-nj-bRsIshAHbLuh9iPjvZkFz4gShUayGNT6SwPF1zAmanMFsEK6QUUXh-CCN0sRzVx>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrheeggdegvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpefmvghithhh ucfoohhorhgvuceomhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhmqe enucggtffrrghtthgvrhhnpeeftddvleeijeevkeejhfeuudehveeihfejfedvgfduhfff hfduuddufeeggfetveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:tIIAYvASPqqUZhsAGTg5eo7ru-qqgCU1K_DJSVOeF8pSQhFDnqPQ2A> <xmx:tIIAYoh09RIAyl_bAylZnrE1pDB1uJhChFh2epZVF7JNxlL6QE51Mg> <xmx:tIIAYjpqe3dqjeuRVDYDTpbGn38BYC8UvxTY1B-rst3l2IiFkAgQqg> <xmx:tIIAYgKyZMYHIu6rNvLQnhRjEIko5L4AB9wz6iGTsBuOb_VRva0LqA>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 6 Feb 2022 21:23:48 -0500 (EST)
Message-ID: <0c9399a8-5b79-0016-7418-6a6fae79860e@network-heretics.com>
Date: Sun, 06 Feb 2022 21:23:47 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-US
To: Christian Huitema <huitema@huitema.net>, behave@ietf.org, Klaus Frank <klaus.frank@posteo.de>
References: <45e423cc-4095-cca2-bf8c-aa15e977b19c@posteo.de> <ff858dee-a21a-a50d-72a5-da7915ac2de4@network-heretics.com> <71b5cdb0-78af-0f77-debc-84e178fe5e3a@posteo.de> <7a008cc2-e8a3-f91d-c782-96866c36a9db@network-heretics.com> <ee760818-a3c4-3755-6bdf-afcec6fcaaad@posteo.de> <B7DFC369-E7B7-4171-9C85-F75986B5AEF6@gmail.com> <6123a322-e9a7-7f90-391f-9b4c4461ce45@network-heretics.com> <e95993e4-4166-4b3d-1637-8ca451b093b6@huitema.net>
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <e95993e4-4166-4b3d-1637-8ca451b093b6@huitema.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/CQQpm4pXEpdaxXXWiyhUFypaoJ8>
Subject: Re: [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: Mon, 07 Feb 2022 02:24:14 -0000

On 2/6/22 21:13, Christian Huitema wrote:

> Of course, doing that require special code in the SMTP server to 
> handle NAT64. But that's pretty much the only solution. 

Fortunately about the only consumers of SPF records are SMTP servers and 
spam filters.   And assuming that SPF is still in significant use (sigh) 
the developers of those products will be motivated to add support for 
SPF rewriting in the presence of NAT64.   It seems much better to put 
that optional/configurable fix in SMTP servers and spam filters than to 
burden every NAT64 with it.   Especially since the current trend seems 
to site SMTP servers for inbound mail "in the cloud" or at least in a 
rack somewhere completely outside the enterprise network, or even more 
likely, to outsource the inbound mail service entirely to somewhere that 
probably still has native IPv4 access should it be needed.    (And I 
suspect that trend will last longer than IPv4 does or NAT64 is needed.)

Keith