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

Sam Varshavchik <mrsam@courier-mta.com> Tue, 20 April 2021 00:09 UTC

Return-Path: <mrsam@courier-mta.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41D73A4A6D for <ietf-smtp@ietfa.amsl.com>; Mon, 19 Apr 2021 17:09:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2GdAIA9GmW6 for <ietf-smtp@ietfa.amsl.com>; Mon, 19 Apr 2021 17:09:32 -0700 (PDT)
Received: from mailx.courier-mta.com (mailx.courier-mta.com [68.166.206.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC833A4A6C for <ietf-smtp@ietf.org>; Mon, 19 Apr 2021 17:09:32 -0700 (PDT)
Received: from monster.email-scan.com (monster.email-scan.com [::ffff:192.168.0.2]) (TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384) by www.courier-mta.com with UTF8SMTPS id 00000000002C0037.00000000607E1BB4.00006FEC; Mon, 19 Apr 2021 20:09:24 -0400
Received: from monster.email-scan.com (localhost [127.0.0.1]) (IDENT: uid 1004) by monster.email-scan.com with UTF8SMTP id 00000000000421C8.00000000607E1BB3.0000D773; Mon, 19 Apr 2021 20:09:23 -0400
References: <cone.1615844513.220592.51342.1004@monster.email-scan.com> <20210315234648.563C0708B340@ary.qy> <CAO=DXp-+fJwsNegzu3zgwDLtCcSF104AUF=i+_GMgSYVBAKjWg@mail.gmail.com> <01RY24IJ225Q0085YQ@mauve.mrochek.com> <CAO=DXp-VSxeTsWZFAms7WX-jonkSiyGgKV5T_17VGhq6bcsMdg@mail.gmail.com>
Message-ID: <cone.1618877363.380527.55051.1004@monster.email-scan.com>
X-Mailer: http://www.courier-mta.org/cone/
From: Sam Varshavchik <mrsam@courier-mta.com>
To: ietf-smtp@ietf.org
Date: Mon, 19 Apr 2021 20:09:23 -0400
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="=_monster.email-scan.com-55051-1618877363-0001"; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/dBxI1RZ_T0k6bVWkYnS51ypWH1g>
Subject: Re: [ietf-smtp] [Emailcore] Proposed ESMTP keyword RCPTLIMIT
X-BeenThere: ietf-smtp@ietf.org
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\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=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.