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

John C Klensin <> Mon, 15 March 2021 20:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C4653A09E7 for <>; Mon, 15 Mar 2021 13:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r38TB9szabIO for <>; Mon, 15 Mar 2021 13:28:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D1ED3A09C7 for <>; Mon, 15 Mar 2021 13:28:48 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1lLtpS-0002zP-OL; Mon, 15 Mar 2021 16:28:42 -0400
Date: Mon, 15 Mar 2021 16:28:36 -0400
From: John C Klensin <>
To: Ned Freed <>, Dave Crocker <>
Message-ID: <CF0247A810AF9482CBB155E8@PSB>
In-Reply-To: <>
References: <> <20210312203224.F3739701E4C5@ary.qy> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
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 20:28:50 -0000

--On Monday, March 15, 2021 08:58 -0700 Ned Freed
<> wrote:

>>       SMTP servers have always been able to announce a limit,
>>       in a reply, which means that the client first needed to
>> issue a command.  The mechanism specified here avoids the
>> overhead of that interactions, by announcing limits prior to
>> any substantive interaction.
> Nice. Added.

I wonder.  Along with the "first digit" rule, SMTP has been
fairly clear that SMTP clients should not depend on trying to
parse or interpret reply text except for VRFY and EXPN for which
syntax is actually given for replies.  Assuming this is the sort
of announcement you and Dave have in mind, suppose the client
and the server responds
   250 OK.  No more than 20 recipients
would we seriously expect the client to interpret and use that

In addition, if the answer were "yes", what would prevent a
connection-opening response of 
  220 SNAFU SMTP Server, v 666, no more than 25 recipients

which is no less an announcement and of course avoids having to
wait for any commands to be issued, even EHLO.