Re: [ietf-smtp] [Emailcore] Proposed ESMTP keyword RCPTLIMIT

Sam Varshavchik <> Mon, 15 March 2021 21:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C76BE3A0FF7 for <>; Mon, 15 Mar 2021 14:41:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wfk4Gx7AB-XZ for <>; Mon, 15 Mar 2021 14:41:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D0F03A0FEA for <>; Mon, 15 Mar 2021 14:41:58 -0700 (PDT)
Received: from ( [::ffff:]) (TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by with UTF8SMTPS id 00000000002C0037.00000000604FD4A2.000055E2; Mon, 15 Mar 2021 17:41:53 -0400
Received: from (localhost []) (IDENT: uid 1004) by with UTF8SMTP id 000000000001E836.00000000604FD4A1.0000D399; Mon, 15 Mar 2021 17:41:53 -0400
References: <> <20210312203224.F3739701E4C5@ary.qy> <> <> <> <>
Message-ID: <>
From: Sam Varshavchik <>
Date: Mon, 15 Mar 2021 17:41:53 -0400
Mime-Version: 1.0
Content-Type: multipart/signed; boundary=""; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [ietf-smtp] [Emailcore] Proposed ESMTP keyword RCPTLIMIT
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\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Mar 2021 21:42:00 -0000

Dave Crocker writes:

> Most of the time, enhancement mechanisms, like this, already have  
> significant adoption barriers.  So keeping them as simple as possible is to  
> be highly preferred, over making them more nuanced.

That's my take too. I am not sure what I'll gain from doing this in the  
first place, not to mention any extra complexity of this sort.

Without explicitly defined limits: I'm just picking a reasonable cap and  
duplicating each message, so their number of recipients is under the cap.  
This happens much earlier in the processing, even before attempting to find  
a willing MX to talk to.

MXes which do not announce their limits are going to dominate for some time.  
So, I still need to do this for the foreseeable time. So, what does this  
SMTP extension buy me? The only thing I can think of: not duplicating  
messages when I don't need to.

But the thing is: I don't recall anyone raising this to me, as a problem.  
This is not on my radar screen as a problem that wants to be solved.