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

Sam Varshavchik <> Thu, 18 March 2021 01:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8C8F3A1A34 for <>; Wed, 17 Mar 2021 18:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o3AoBlLE91rH for <>; Wed, 17 Mar 2021 18:37:32 -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 9452D3A1A33 for <>; Wed, 17 Mar 2021 18:37:32 -0700 (PDT)
Received: from ( [::ffff:]) (TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by with UTF8SMTPS id 00000000002C0037.000000006052AED7.0000A6A5; Wed, 17 Mar 2021 21:37:27 -0400
Received: from (localhost []) (IDENT: uid 1004) by with UTF8SMTP id 000000000001E836.000000006052AED7.00016327; Wed, 17 Mar 2021 21:37:27 -0400
References: <CF0247A810AF9482CBB155E8@PSB> <> <> <> <> <4EC92B6CFDD4220E0F692CF0@PSB>
Message-ID: <>
From: Sam Varshavchik <>
Date: Wed, 17 Mar 2021 21:37:26 -0400
Mime-Version: 1.0
Content-Type: multipart/signed; boundary=""; micalg=pgp-sha1; protocol="application/pgp-signature"
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:37:34 -0000

John C Klensin writes:

> Personally and wearing no hats, I like the idea of a new
> "LIMITS" extension and EHLO keyword.   However, I think we could

This reminded me of something that I wanted to mention. In whichever form  
the eventual specification of recipient limits takes place: I believe that  
the specification should set a minimum recipient limit. In other words: the  
minimum number of recipients that can be advertised.

I believe that the generally good track record of historical  
interoperability of SMTP implementations goes back to what's in section  
4.5.3 of RFC 821, that gives the minimal limits of various things, like line  
lengths. And, incidentally, the minimum number of recipients that an SMTP  
server should accept is 100 recipients.

I don't remember if this was discussed, but this should be called out in any  
eventual recipient limit specification: the minimum value is 100, as per  
2821 and 821.