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

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 19 March 2021 07:40 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 AA08B3A15D2 for <ietf-smtp@ietfa.amsl.com>; Fri, 19 Mar 2021 00:40:04 -0700 (PDT)
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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 GFoMzT_AkkyO for <ietf-smtp@ietfa.amsl.com>; Fri, 19 Mar 2021 00:40:03 -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 188763A15D1 for <ietf-smtp@ietf.org>; Fri, 19 Mar 2021 00:40:02 -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 1AA64D159E for <ietf-smtp@ietf.org>; Fri, 19 Mar 2021 03:39:59 -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: <C7297FCD-DA5A-43D1-972C-537171D4330F@wordtothewise.com>
Date: Fri, 19 Mar 2021 03:39:58 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: ietf-smtp@ietf.org
Message-Id: <B258F7AA-3FC4-47C7-8DB1-98BA423D597E@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> <8E2D8138-EE61-486A-B957-A922F0C6F4B3@dukhovni.org> <20210318003233.DC44C70A8F5D@ary.qy> <e90d22da-e124-4542-8ef6-83798f5725de@gulbrandsen.priv.no> <F5461844610EDF6715D08D1B@PSB> <503e5ae8-71a1-8c9e-33b3-5c475d0ad76f@pscs.co.uk> <C7297FCD-DA5A-43D1-972C-537171D4330F@wordtothewise.com>
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/T7qs3D6NsvoD9Z8vCXY7yuV6GI8>
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: Fri, 19 Mar 2021 07:40:05 -0000

> On Mar 18, 2021, at 10:55 AM, Laura Atkins <laura@wordtothewise.com> wrote:
> 
> MTAs that send high volumes of email do pay attention to the other digits and the extended codes. In fact, many of them do full text parsing to try and determine how they should handle future mail to that address. https://smtpfieldmanual.com is one example. 

Is this "paying attention" really happening *during* delivery, to
guide further progress of the SMTP transaction, or, as seems more
likely, rather an after-the-fact forensic analysis to keep lists
in good hygiene.

Detailed SMTP server replies are certainly useful forensically,
what's under discussion in this thread, is to what extent the SMTP
protocol engine in the sending client really needs to be concerned
with such details.

Occasionally, an MTA with an uncertain reputation may choose to
conditionally soften a 5XX reply to a 4XX reply, if it has another
means to reach the destination (from a different IP address, ...).
Perhaps that's the every-day reality for some sending systems, and
in that case I can see these closely scrutinising the server reply.
In most other cases, there's little reason to look beyond the first
digit.

-- 
	Viktor.