Re: [ietf-smtp] Possible cont4ibution to moving forward with RFC5321bis SMTP

Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Thu, 02 January 2020 19:09 UTC

Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32E3120118 for <ietf-smtp@ietfa.amsl.com>; Thu, 2 Jan 2020 11:09:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no
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 mKGlktqCx8mT for <ietf-smtp@ietfa.amsl.com>; Thu, 2 Jan 2020 11:09:38 -0800 (PST)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4661120113 for <ietf-smtp@ietf.org>; Thu, 2 Jan 2020 11:09:38 -0800 (PST)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 62D9AC008D; Thu, 2 Jan 2020 19:13:46 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1577992426; bh=JtvR1btdeExszT+THDJqQpkUZnrqpb6dNTFfcC4wrdg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BXw9Jeo8gap3BihKodxyyINaja/fjJx9GR+D9gQkH/ykkrOm2ig6rrd5lVkc7PEmO FBuyvTH21FddmfxXQuB/zopbZkPu/OBGyT5pIZ7Qvu91fx3+woux+tkm2om/ajD3LP A8fGWSFia9sL7FGc9TWYaAJNCL3+auNFLjr5LVwI=
Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1577992425-27479-27476/9/18; Thu, 2 Jan 2020 19:13:45 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: ietf-smtp@ietf.org
Date: Thu, 02 Jan 2020 20:09:35 +0100
Mime-Version: 1.0
Message-Id: <501e94b2-1f76-442a-8c3e-a3bc46c51aca@gulbrandsen.priv.no>
In-Reply-To: <ddad210b-90b7-1e51-281f-5fcca6c31ac0@network-heretics.com>
References: <20191230013034.2C3E111D376E@ary.qy> <f894c448-ac91-6d27-98d6-0803de4ea535@network-heretics.com> <alpine.OSX.2.21.99999.374.1912292129450.44159@ary.qy> <d3dc48b0-332b-c2fe-704a-d6dc69eb5424@network-heretics.com> <5E0B8658.2060703@isdg.net> <fc8d4d71-39a4-6ca0-608a-d2113b206c5f@network-heretics.com> <5E0E10AF.30808@isdg.net> <3a106d9d-7be9-f6d4-b6e6-0103372ae227@network-heretics.com> <de71c2ed-adb6-7cf7-8f6b-a933677dc89f@dcrocker.net> <ddad210b-90b7-1e51-281f-5fcca6c31ac0@network-heretics.com>
User-Agent: Trojita/0.7; Qt/5.7.1; xcb; Linux; Devuan GNU/Linux 2.1 (ascii)
Content-Type: text/plain; charset="utf-8"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/hsIrKCqPFRpGRKpRHw5W7v6lLLQ>
Subject: Re: [ietf-smtp] Possible cont4ibution to moving forward with RFC5321bis SMTP
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jan 2020 19:09:41 -0000

On Thursday 2 January 2020 19:51:09 CET, Keith Moore wrote:
>  It's when the mail is relayed between mail domains that the 
> standards need to provide guidance, because when sending domain 
> and receiving domain have different assumptions about what is 
> right, it causes unnecessary failures.

I feel that a brief digression might help to prolong this discussion.

One way to disagree is about IP address family.

If I remember correctly, nothing (else) in 5321/2 requires a v6-only host 
to understand anything about v4. Running a v6-only host is stupid at this 
point, perhaps slightly less stupid in five years, but even so I don't 
think the next RFCs should feature an IPv4 requirement for address 
literals, and nothing for the main parts of the protocols.

Arnt