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

Dave Crocker <> Mon, 15 March 2021 16:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B86223A1622 for <>; Mon, 15 Mar 2021 09:29:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EuUMmFIsDQoy for <>; Mon, 15 Mar 2021 09:29:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 325BC3A161B for <>; Mon, 15 Mar 2021 09:29:24 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailforward.nyi.internal (Postfix) with ESMTP id 7FB8A194198C; Mon, 15 Mar 2021 12:29:23 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Mon, 15 Mar 2021 12:29:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=hj+0x/sPMB7HBmFAVB+2c4tv2mWlY k826diW/PM0Iio=; b=bjIukHl53DINdomjFUG7e0+amSAQ3cLmnQFMp2Ezy6yaF oGZcd7KUj6EgnglUEbgWulr/osvE0ApqcFjfF+nwEo+eBFIG4N2cD8j1TMgKZn0b T8v8i8klNibiorfAOOveCDt6SRf9RTHR+0A8V2rNgVNkWV5QiyYP0xMhqHUoX9tX VNPPFVaBCrC77ADxDtDI/b8MmCc6/KEEi/R2Ha6A4JJS2QhxSnFfzYXtHrcrE0aS TgEr0Cq6tPAiLNEPPP4/UJQNfxy30X2/aF7macaOwX0xwS+cklvPQJX9YUdHLXeG 4vOHkHmhyp/7TdlY7sC4xPPtodqPBvCZiJO9haAJg==
X-ME-Sender: <xms:YotPYL5ALTL_qlanQgeVK8MxhNDQuDL7-Ut_FfywPvy7nSiMDUtvsw> <xme:YotPYIU8aSqSVuij234wclBk-B8jFDJzujas6ovY1GD-3uaNpLYDIBRdaZmpubZKP I4nQRlnueopzGqiwQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvledgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheprhfuvfhfhfhokffffgggjggtgfesthejredttdefjeenucfhrhhomhepffgr vhgvucevrhhotghkvghruceoughhtgesuggtrhhotghkvghrrdhnvghtqeenucggtffrrg htthgvrhhnpeektdelfffgvdeiudfhvdehhfejvddvudeikedvueefiefgteehfeegfeev ffetudenucffohhmrghinhepsggsihifrdhnvghtnecukfhppedutdekrddvvdeirdduie dvrdeifeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm peguhhgtsegutghrohgtkhgvrhdrnhgvth
X-ME-Proxy: <xmx:YotPYP1KSPCySwc0uDEnTnUXNDHWo1mGiWPmSJQ1BKr1E9QTAQIKxw> <xmx:YotPYF2_LbKhgrCrQst3VscHJIaw26BVeUW9eahvGQGGWG1gSxB22A> <xmx:YotPYC-EhXEEkIXkgY9__kdqBoJ8s2sO40P39JjTIvZgiYPmTvqtkA> <xmx:Y4tPYEPuFrEdVKX4T_qON_Mz_Oi8Prxekjp62Cg1_qTT_cpk9pQ25w>
Received: from [] ( []) by (Postfix) with ESMTPA id 00734240054; Mon, 15 Mar 2021 12:29:21 -0400 (EDT)
To: Ned Freed <>
References: <> <20210312203224.F3739701E4C5@ary.qy> <> <> <>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Mon, 15 Mar 2021 09:29:20 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 16:29:26 -0000

On 3/15/2021 8:58 AM, Ned Freed wrote:
> However, I did have another idea here: It would be possible for a server to
> indicate that a limit change has occured through the use of a special 
> enhanced
> status code - probably limited to ones on successful repsonses. This would
> instruct the client to reissue EHLO at the next opportunity to obtain 
> updated
> limits.
> I think this is overengineered and opted not to include it, but I'd like
> feedback from others on the point.

I'll amend your assessment:  I think this would be /extremely/ 

Specifying mechanisms for highly nuanced behavior is worthwhile when 
there is a well-understood problem, widely viewed as being substantial, 
and therefore, there is good motivation for adopting the added complexity.

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.


Dave Crocker
Brandenburg InternetWorking