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

Ned Freed <ned.freed@mrochek.com> Tue, 20 April 2021 14:45 UTC

Return-Path: <ned.freed@mrochek.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 BDD743A2693 for <ietf-smtp@ietfa.amsl.com>; Tue, 20 Apr 2021 07:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
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 K_bHyZsnDuIW for <ietf-smtp@ietfa.amsl.com>; Tue, 20 Apr 2021 07:45:33 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 AB1FA3A2692 for <ietf-smtp@ietf.org>; Tue, 20 Apr 2021 07:45:33 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RY347N1NSG00EMYB@mauve.mrochek.com> for ietf-smtp@ietf.org; Tue, 20 Apr 2021 07:40:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1618929613; bh=HENwSL9m66kfQ7pZr4jRqctPWC1AQdKVVpfJ4gPZ9yk=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=hiV/6gsT3dokluW4ntg+KcpXWaXXGbyT203BI7ErRJMm4yw+3dezBaSFy2Md5uXzy gG+LvqO2qUTYdq4mYaL4hOtJ/ImzGhx9iHZqU5HEYEp50yUuOmIcoZeNjeGS1tjzQe JXfx+vE/3+Fyz7rzNEBjBwEPAaj56VwasKgIjTws=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RY1UKIVTTC0085YQ@mauve.mrochek.com>; Tue, 20 Apr 2021 07:40:10 -0700 (PDT)
Cc: ietf-smtp@ietf.org
Message-id: <01RY347LHNBA0085YQ@mauve.mrochek.com>
Date: Tue, 20 Apr 2021 07:28:03 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 20 Apr 2021 15:19:15 +0100" <Dx8j6QnjLufgFAwC@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> <Dx8j6QnjLufgFAwC@highwayman.com>
To: Richard Clayton <richard@highwayman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/3wESudG1SZpTjuceyYfy3koeiQY>
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:45:39 -0000

> 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".

True, but it's also the case that such conclusions can be reached
by an all-too-human staff; no fancy ML required.

> > 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.

Especially since you can do it at the MAIL FROM, and if the sender proceeds to
send the message anyway or otherwise misbehave rely on the server's built-in
logic to deal with that.

(We actually support both approaches.)

> 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)

I don't really understand the concern here, and more importantly, how to address
it. Any time you connect to someone else's SMTP server there's a implicit
understanding that it will only accept what you send as long as you send what it
considers to be good stuff. The LIMITS extension operates within this context;
all it does is let the server add to the client's understand of what's
acceptable; in no way does it change that basic understanding.

				Ned