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

John C Klensin <> Thu, 18 March 2021 13:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 609D73A2C26 for <>; Thu, 18 Mar 2021 06:58:50 -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 qylxCbbz890Z for <>; Thu, 18 Mar 2021 06:58:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EABE63A2C25 for <>; Thu, 18 Mar 2021 06:58:48 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1lMtAj-000MhA-4D; Thu, 18 Mar 2021 09:58:45 -0400
Date: Thu, 18 Mar 2021 09:58:39 -0400
From: John C Klensin <>
To: Alessandro Vesely <>, Ned Freed <>,
Message-ID: <0BEE6B0072CA657CBBD724E8@PSB>
In-Reply-To: <>
References: <> <20210312203224.F3739701E4C5@ary.qy> <> <> <> <CF0247A810AF9482CBB155E8@PSB> <> <> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [ietf-smtp] parsing SMTP replies (was: 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: Thu, 18 Mar 2021 13:58:50 -0000

--On Thursday, March 18, 2021 11:37 +0100 Alessandro Vesely
<> wrote:

>> That said, I don't see why this limit necessarily has
>> anything to do  with greylisting. It's about how to long to
>> wait before retying after a transient failure, irrespective
>> of why the delay occurred. If could be greylisting, it could
>> be exceeding a rate or connection limit, it could be one of
>> the sources for validating recipients is down, it could be
>> the spam filtering system is down, etc. RETRYDELAY would be a
>> much better name for it.

> Good point.  By observing RCPTLIMIT, a client can avoid
> re-queuing delays.  It stops just before reaching the limit
> and then starts a new transaction right away.  However, this
> won't work if 452 was issued to split recipients according to
> a different criterion than the local max number.

"Avoid" and "stops"?  Only maybe.  If some variation on
greylisting is applied because the server doesn't approve of,
e.g., the IP address of the sender or the combination of the
reverse-path and one or more of the recipients, a published
maximum on the number of RCPT commands doesn't have anything to
do with it.   And, for a variety of reasons, that might result
in a 4yz code after DATA, not anything but 250 codes after the
RCTP commands.

I see this feature as useful, but we should not over-sell it,
even to each other.