Re: [ietf-smtp] [dispatch] Forced SMTP redirects

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 16 March 2021 19:26 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 15D853A044A for <ietf-smtp@ietfa.amsl.com>; Tue, 16 Mar 2021 12:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Be3SMNo5YY4K for <ietf-smtp@ietfa.amsl.com>; Tue, 16 Mar 2021 12:26:50 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 BD1533A03FC for <ietf-smtp@ietf.org>; Tue, 16 Mar 2021 12:26:50 -0700 (PDT)
Received: from [192.168.1.177] (unknown [192.168.1.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 4DDFDCF837 for <ietf-smtp@ietf.org>; Tue, 16 Mar 2021 15:26:49 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <81d0132b-3ebf-2b0b-756b-503bb5afdb37@dcrocker.net>
Date: Tue, 16 Mar 2021 17:26:49 -0200
Content-Transfer-Encoding: quoted-printable
Reply-To: ietf-smtp@ietf.org
Message-Id: <8E2D8138-EE61-486A-B957-A922F0C6F4B3@dukhovni.org>
References: <CAKFo7wkawgk-Yj676kE5MqK8XuebuArMexH-eOdq_Uo7ijdimQ@mail.gmail.com> <20200710015947.0BE2D1C78A2F@ary.qy> <CAKFo7w=MJBt0FdnCcOZCXZWdkd6Jinv4TqwdpefdoaCncbZH3Q@mail.gmail.com> <6AEA7D44C8037B32BC1F3810@PSB> <81d0132b-3ebf-2b0b-756b-503bb5afdb37@dcrocker.net>
To: ietf-smtp@ietf.org
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/R9n00WPbTQoniLhzRNK6OB068mo>
Subject: Re: [ietf-smtp] [dispatch] Forced SMTP redirects
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: Tue, 16 Mar 2021 19:26:52 -0000

> On Mar 16, 2021, at 1:26 PM, Dave Crocker <dhc@dcrocker.net> wrote:
> 
> Recent list discussion prompted me to look back for earlier reference to the first digit 'rule', concerning test in Section 4.2 of RFC 5321.
> 
> The above logic escapes me.
> 
> While it gives direction when the full code is not (yet) understood, it says nothing about adoption processes that might or might not eventually lead to support for new codes.
> 
> That is, new codes will of course not be understood by any implementation initially, but useful codes are likely to be understood by 'most' implementations eventually.
> 
> As such, the first digit rule, in RFC 5321, really has nothing at all to do with the efficacy of adding code or adding text to codes.  It only has to do with behavior of implementations that do not (yet) understand a full code.

Postfix has been around since 1997 (alpha), or if you prefer 2001 (1.0 prod).
The SMTP client in Postfix only ever[1] looks at the first digit.  I expect this
is fairly common.  There isn't yet any known response code where we'd expect
the rest to matter.  I'd prefer to keep it that way.  The remaining digits are
useful for forensics.

-- 
	Viktor.

[1]  There is one special case, 421 in response to EHLO is taken as a no
     service indication, rather than a reason to try HELO instead.  This
     should probably include 521 (perhaps an oversight).