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

Ned Freed <> Wed, 17 March 2021 18:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5EB53A1041 for <>; Wed, 17 Mar 2021 11:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 12347z-a3pzu for <>; Wed, 17 Mar 2021 11:19:00 -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 C55853A103F for <>; Wed, 17 Mar 2021 11:19:00 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <> for; Wed, 17 Mar 2021 11:13:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=201712; t=1616004837; bh=nI7cQ0G9+HgRcpYnkB/GvtqHBVy9GgaL48E+sn+3uZ0=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=FYTAVygpYV75di+vuA2VeoVqXtkJ2PuGhazYaZk28IghDlf6Hl6rHI0BymAbYjbQv T0NMYwZPVQp+B1MHULKyHtdDKKUHB1Ha8ddT8bzf4/ocTs6W8wGXYR+bDXNQjCXQCt 3mfZinQo9s3YYcSc5IVhurubIRELy8O7fhZGbBT8=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Received: from by (PMDF V6.1-1 #35243) id <>; Wed, 17 Mar 2021 11:13:54 -0700 (PDT)
Cc:, Ned Freed <>
Message-id: <>
Date: Wed, 17 Mar 2021 10:44:04 -0700 (PDT)
From: Ned Freed <>
In-reply-to: "Your message dated Wed, 17 Mar 2021 11:46:25 +0100" <>
References: <> <20210312203224.F3739701E4C5@ary.qy> <> <> <> <CF0247A810AF9482CBB155E8@PSB> <> <> <>
To: Alessandro Vesely <>
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: Wed, 17 Mar 2021 18:19:02 -0000

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 {{GREYLISTING}}

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.