Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452?

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 12 March 2021 06:13 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: emailcore@ietfa.amsl.com
Delivered-To: emailcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CC53A00DB for <emailcore@ietfa.amsl.com>; Thu, 11 Mar 2021 22:13:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 yruIvDe4Lf3w for <emailcore@ietfa.amsl.com>; Thu, 11 Mar 2021 22:13:48 -0800 (PST)
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 56A163A00C8 for <emailcore@ietf.org>; Thu, 11 Mar 2021 22:13:48 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 74EECCC4EC; Fri, 12 Mar 2021 01:13:46 -0500 (EST)
Date: Fri, 12 Mar 2021 01:13:46 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: emailcore@ietf.org
Message-ID: <YEsGmgQskutY2OhW@straasha.imrryr.org>
Reply-To: emailcore@ietf.org
References: <c188413b-9337-40d8-8062-9c0f58f6cd98@www.fastmail.com> <CAHej_8kHwEOmq5bf49=Tt6ZEVkuidMhy5s4XPu7JC+k22qraZg@mail.gmail.com> <CAHej_8ma-kDkVh3Oj11R5Fn6BbwJsWfFpx0Zqv61fPL35CJNUA@mail.gmail.com> <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <CAHej_8=deJU1CW2AzDBu5ji3Uir+_zF6Gp59Z-hHRmRipz8Osw@mail.gmail.com> <9A7BDB22F3A0396EF24BF91D@PSB> <397cc52c-5533-12a2-6ca2-e46f5987105c@wizmail.org> <F57F0BCCE67A6D1CE8BC3157@PSB> <6FC2E8E6-334A-4C4B-9FB6-A0F2805C4A31@dukhovni.org> <420176B328E2416BF3351C95@PSB>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <420176B328E2416BF3351C95@PSB>
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/gGC7hgiLQKSXJkaqFSRUr8uLyB4>
Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452?
X-BeenThere: emailcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EMAILCORE proposed working group list <emailcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emailcore>, <mailto:emailcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emailcore/>
List-Post: <mailto:emailcore@ietf.org>
List-Help: <mailto:emailcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emailcore>, <mailto:emailcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2021 06:13:50 -0000

On Fri, Mar 12, 2021 at 12:21:57AM -0500, John C Klensin wrote:

> If SMTP clients are not paying attention to those codes anyway,
> we could save many pages of 5321bis by tearing all the theory
> and details of the specific three-digit codes out, specifying
> that servers MAY reply with the traditional codes if they want
> to but otherwise can just send x99 or some such thing and, if
> they feel like being informative should just use extended codes
> of the RFC 3463 variety, which actually do provide information.

Indeed, but I over-simplified somewhat.  A few of the distinctions
are broadly useful:

    * 40X and 50X codes are syntax errors.

    * 421 and 521 are server-initiated disconnects.

    * IIRC SASL is a bit more picky about some of the codes as well.

    * Otherwise, 4XX and 5XX are what dogs hear, but
      of course these are still useful as a forensic
      after-the-fact diagnostic aid.

So my take is that at the SMTP protocol layer, the fine-grained codes
are mostly cosmetic, the first digit suffices.  But for debugging
problems later, they are somewhat useful, at least to the postmaster of
the site that replied with those code when a problem report includes the
server's response.

> Would you suggest that and, if not, why not?   Or, put
> differently, where is the stopping point between your "what dogs
> hear" model and doing that?

I would not suggest that servers go out of their ways to perversely
invent novel codes.  Aside from syntax errors and "Goodbye" X21
responses, servers can IMHO pretty much otherwise stick to just four
mostly interchangeable response codes: 450, 454, 550 and 554.

I can't say I'd miss most of the rest.  So I would certainly not invest
much energy in adding new precision to the existing codes, or even
necessarily keeping all the current distinctions in place, but I'm
curious to hear what others have to say about that.

Below is the list of all the codes that Postfix has built-in knowledge
of in the SMTP server, and the number of times seen in the source code.
(in addition users can set arbitrary 4XX/5XX codes in access rules):

       4 500 -- Syntax
      49 501
       4 502
      17 503
       2 504

       2 220 -- Connection
       2 221
       9 421
       2 521

       1 235 -- AUTH Success
       1 334 -- AUTH continue
       1 530 -- AUTH FAIL
       1 535

      12 250 -- OK
       1 252 -- VRFY

       1 354 -- DATA continue

       1 452 -- The reason we're here :-)
       1 552 -- The reason we're here :-)

      14 450 -- Sorry, you lose
       6 454
       7 550
       7 554

       3 458 -- ETRN
       1 459

       3 553 -- Mostly EAI misuse
       2 555 -- DSN misuse

The frequency count in lines of code is not necessarily indicative of
actual frequency of use.

So best-effort is made to use the closest approximate standard code to
the reason for a failure (there's not always a good match), but the
client code only cares about [45] and  [45]21 as special
connection-layer termination codes.

The simpler "dog" model works remarkably well.

-- 
    Viktor.