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

Richard Clayton <richard@highwayman.com> Tue, 20 April 2021 14:20 UTC

Return-Path: <richard@highwayman.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 5C9113A25B7 for <ietf-smtp@ietfa.amsl.com>; Tue, 20 Apr 2021 07:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 mM7KUygIm6Zb for <ietf-smtp@ietfa.amsl.com>; Tue, 20 Apr 2021 07:20:47 -0700 (PDT)
Received: from mail.highwayman.com (mail.highwayman.com [82.69.6.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6CAF3A25B4 for <ietf-smtp@ietf.org>; Tue, 20 Apr 2021 07:20:47 -0700 (PDT)
Received: from localhost ([127.0.0.1]:43707 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.94) (envelope-from <richard@highwayman.com>) id 1lYrF3-0008b0-1Y for ietf-smtp@ietf.org; Tue, 20 Apr 2021 14:20:41 +0000
Message-ID: <Dx8j6QnjLufgFAwC@highwayman.com>
Date: Tue, 20 Apr 2021 15:19:15 +0100
To: ietf-smtp@ietf.org
From: Richard Clayton <richard@highwayman.com>
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> <cone.1618877363.380527.55051.1004@monster.email-scan.com> <F8AC11B4-1C30-4DE6-AE70-F91994EE7539@wordtothewise.com>
In-Reply-To: <F8AC11B4-1C30-4DE6-AE70-F91994EE7539@wordtothewise.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Mailer: Turnpike Integrated Version 5.03 M <PCx$+fOD77fsCMKLLWT+duEVc2>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/N5ne980WGu1RDmtVV-AjKvm2AYI>
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 14:20:52 -0000

In message <F8AC11B4-1C30-4DE6-AE70-F91994EE7539@wordtothewise.com>,
Laura Atkins <laura@wordtothewise.com> writes

>> 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.
>
>It’s a limit that was implemented more than a decade ago by some of the highest 
>volume receivers around. I don’t think we have to understand why they did it - 
>if even the folks who made the decision are still around. [1] We can just say: 
>this is commonly occurring behavior and it makes sense for SMTP to document it 
>and have a way to explain it. 

As you will know, the highest volume receivers have complex machine
learning systems which can -- after a number of messages -- come to the
conclusion that sending a SYN-ACK at the start was somewhat of a
mistake... use of resources is more efficient if you make such senders
(which dominate) start at the beginning again and you just refuse to let
them connect "ever again".

>From an engineering standpoint the overhead of 5xx-ing a small number of
emails per session once the sender is understood to be bad may be a
reasonable tradeoff compared with the complexity of chasing round all of
your servers (of which you have rather more than one or two) identifying
which open connections should be aborted.

Other (related) considerations apply to email submitted over
authenticated connections (you may realise as the email piles up that it
is likely that the credentials are being misused)

>What we should be doing is figuring out how to make these limits more clear to 
>senders. 

as I observed before -- don't expect much more than a generic statement
(which comes down to "sending N good emails is the most you can expect
to be able to manage") from such systems. Anything which revealed the
current view ("actually, you've pretty much exhausted our patience")
just is not going to happen (IMO)

-- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755