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

John C Klensin <> Thu, 18 March 2021 01:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B9483A19B2 for <>; Wed, 17 Mar 2021 18:06:36 -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 NDj0RUdIgLio for <>; Wed, 17 Mar 2021 18:06:34 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 738CA3A19B1 for <>; Wed, 17 Mar 2021 18:06:34 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1lMh7M-000J4R-SE; Wed, 17 Mar 2021 21:06:28 -0400
Date: Wed, 17 Mar 2021 21:06:21 -0400
From: John C Klensin <>
To: Ned Freed <>, Alessandro Vesely <>
Message-ID: <4EC92B6CFDD4220E0F692CF0@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=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] 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 01:06:36 -0000

--On Wednesday, March 17, 2021 10:44 -0700 Ned Freed
<> wrote:

> Typos fixed.
>> +-------------
>> +
>> +
>> +Value syntax:  %x31-39 0*5DIGIT ; 0 not allowed, 6 digit
>> maximum +
>> +Description: GREYLISTING specifies the minimum number of
>> seconds +that a client should wait before retrying to submit
>> the same message. +The presence of this limit implies that
>> the client MAY receive a +transient 4xx response.  See
> The primary purpose of this document is to create the
> extension and associated
> registry. The only reason some initial entries are included is
> that it's very
> helpful to have some examples to emulate. Building the entire
> registry is not
> the goal, because doing so requires that we reach consensus on
> every limit
> people can think of. This is a sure-fire recipe for document
> failure.
> If past discussions are any indication, getting consensus on
> how to handle
> greylisting is going to be difficult. I don't want to make
> this document
> dependent on that.
> 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.
> The question then becomes is such an announcement - one that
> applies to all
> transient failures, useful. My sense is that the utility is
> marginal given the
> lengthy list of possible causes and the fact that the best
> retry period for
> different causes could be very different, which I note that
> the approach taken
> in the original proposal allows.

FWIW, strong agreement.

And, before we go overboard on this, I would encourage everyone
to review and think about the wise advice [1] in the last two
paragraphs of Section 2.2.1 or RFC 5321.

Personally and wearing no hats, I like the idea of a new
"LIMITS" extension and EHLO keyword.   However, I think we could
easily go overboard and start adding limits parameters on a
principle closer to "might be a neat idea" than to "strong
demonstrated need and evidence of willingness to both advertise
and use".     

If I thought anyone would pay attention, I'd argue for a much
stronger requirement for a new parameter than "Specification
required".  I don't, but I think that, not only should we be
careful that any parameters included in the spec are of clear
applicability and usefulness but that text discouraging vanity
parameters or parameters that would be of value to only one
implementation model would be desirable.  That text might be as
simple as a reference to that statement in 5321 -- perhaps
either at the end of Section 1 or as part of new comments in
Section 6 encouraging people to not go overboard.


[1] While that text is carried forward from RFC 1425, I didn't
write or even suggest it (IIR, Marshall Rose did), so I claim no
> 				Ned
> _______________________________________________
> ietf-smtp mailing list