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

Sam Varshavchik <> Tue, 20 April 2021 00:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F41D73A4A6D for <>; Mon, 19 Apr 2021 17:09:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.558
X-Spam-Level: ***
X-Spam-Status: No, score=3.558 tagged_above=-999 required=5 tests=[RCVD_IN_PBL=3.558, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i2GdAIA9GmW6 for <>; Mon, 19 Apr 2021 17:09:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7CC833A4A6C for <>; Mon, 19 Apr 2021 17:09:32 -0700 (PDT)
Received: from ( [::ffff:]) (TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384) by with UTF8SMTPS id 00000000002C0037.00000000607E1BB4.00006FEC; Mon, 19 Apr 2021 20:09:24 -0400
Received: from (localhost []) (IDENT: uid 1004) by with UTF8SMTP id 00000000000421C8.00000000607E1BB3.0000D773; Mon, 19 Apr 2021 20:09:23 -0400
References: <> <20210315234648.563C0708B340@ary.qy> <> <> <>
Message-ID: <>
From: Sam Varshavchik <>
Date: Mon, 19 Apr 2021 20:09:23 -0400
Mime-Version: 1.0
Content-Type: multipart/signed; boundary=""; micalg=pgp-sha1; protocol="application/pgp-signature"
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: Tue, 20 Apr 2021 00:09:37 -0000

George Schlossnagle writes:

> The common limits we see in the real world (in order of most common  
> occurrence/impact) are:
> Messages per connection
> Recipients per message
> Simultaneous connections per sending IP (this would be my number one  
> suggested add)

This is surprising: that messages per connection is more commonly checked  
than everything else.

I would expect that a receiving server would prefer reusing the same  
connection, to send consecutive messages, than have the sender establish a  
connection, send one message, then tear it down.

A long time ago that was Qmail's well-known bad rep: its simplistic  
implementation, how it created a connection for every individual message.  
So, a dozen messages to the same domain resulted in dozens of concurrent  
connections, all to send one message and disconnect.

I see nothing to gain from forcing a sending server to artificially limit  
itself; how after every N sent messages it has to close its socket, and  
reconnect again. What is that supposed to accomplish? I don't get it.