Re: [ietf-smtp] parsing SMTP replies (was: Proposed ESMTP keyword RCPTLIMIT}

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 18 March 2021 02:54 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 CC5AC3A1C65 for <ietf-smtp@ietfa.amsl.com>; Wed, 17 Mar 2021 19:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 1zB4WPEsO7fy for <ietf-smtp@ietfa.amsl.com>; Wed, 17 Mar 2021 19:54:57 -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 BA75A3A1C63 for <ietf-smtp@ietf.org>; Wed, 17 Mar 2021 19:54:57 -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 3BB0AD0B95 for <ietf-smtp@ietf.org>; Wed, 17 Mar 2021 22:54:55 -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: <7d448367-d5a0-7baf-3df4-dcafe1859437@network-heretics.com>
Date: Wed, 17 Mar 2021 22:54:54 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: ietf-smtp@ietf.org
Message-Id: <1B7BC0D7-5D34-4688-9D8A-BEA925D0ACCD@dukhovni.org>
References: <CF0247A810AF9482CBB155E8@PSB> <01RWP85B98S4005PTU@mauve.mrochek.com> <20210316061139.GA26514@kiel.esmtp.org> <0d5912b5-6aba-728b-00de-a75397ad8ad8@tana.it> <01RWRTQUWB8Q005PTU@mauve.mrochek.com> <4EC92B6CFDD4220E0F692CF0@PSB> <cone.1616031446.909688.90196.1004@monster.email-scan.com> <7d448367-d5a0-7baf-3df4-dcafe1859437@network-heretics.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/kxzMZCJQN96poVFsu9RCSU3PmLo>
Subject: Re: [ietf-smtp] parsing SMTP replies (was: Proposed ESMTP keyword RCPTLIMIT}
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, 18 Mar 2021 02:55:00 -0000

> On Mar 17, 2021, at 10:39 PM, Keith Moore <moore@network-heretics.com> wrote:
> 
> It's been a long time but I'm pretty sure I've seen situations in which it made sense for the recipient limit to be 1.   For example: a special-purpose device (e.g. email to fax, email to printer) or a gateway to a dissimilar mail system, or anything for which it makes sense to insist that per-recipient errors get immediately reported to the client.

That's really the realm of LMTP, final delivery, not relaying.

But much as I agree that MTAs should avoid going below the 5321 limits,
I don't know that we can realistically win in the face of the clout of
the my way or the highway crowd of Gmail, Outlook.com and perhaps still
even Yahoo.

So long as they are willing to reply with 452 as many as (100-N) times
when enforcing a limit of N, things mostly work out provided N is not
so small that one ends up deferring some of the message recipients more
than a couple of times in order to deliver the remaining recipients.

The real question is what to do when you have prepared an envelope of
say 100 recipients, and encounter an MTA with a limit of 5?  Do you
then open 20 parallel connections (they'll hate you for that too),
or do serially transmit the same message over the existing connection
(they may also have an unannounced message per connection limit), or
finally serially open new connections, without deferring, but then
this destination ends up hogging multiple delivery agent cycles out
of turn (this matters when a queue manager is trying to manage
some semblance of fairness).

So limits below the expected limit are damaging to sender performance,
and should not be routinely applied.  The problem is that by the usual
suspects many independently operated smaller MTAs are treated with
suspicion...

-- 
-- 
	Viktor.