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

Ned Freed <ned.freed@mrochek.com> Mon, 19 April 2021 21:43 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 0FAD93A4578 for <ietf-smtp@ietfa.amsl.com>; Mon, 19 Apr 2021 14:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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 f7TSAxSouO_4 for <ietf-smtp@ietfa.amsl.com>; Mon, 19 Apr 2021 14:43:18 -0700 (PDT)
Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 A098C3A4576 for <ietf-smtp@ietf.org>; Mon, 19 Apr 2021 14:43:18 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RY24IKLWZ400H19K@mauve.mrochek.com> for ietf-smtp@ietf.org; Mon, 19 Apr 2021 14:38:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1618868294; bh=nCIv+DewqX+sM0g3kSnohiixtED+9qu6Ut9+NARtLJU=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=liTf2JJftA3+QkupGTucr5e47+VxJU3HmJAg4nZBi01G+zAcrwpQig4xyBbiI0eOl EKzWzidu+9EvabCk2lo9u2GkeKOQoJi0xBA4ehxicIGpNGx6TLGeEEpJmTf79He/8z 9fM8e/enTiZ3dtu1PF+FarA8az4lByD//bSA9UrQ=
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>; Mon, 19 Apr 2021 14:38:12 -0700 (PDT)
Cc: John Levine <johnl@taugh.com>, mrsam@courier-mta.com, ietf-smtp@ietf.org
Message-id: <01RY24IJ225Q0085YQ@mauve.mrochek.com>
Date: Mon, 19 Apr 2021 14:18:17 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sun, 18 Apr 2021 19:47:15 -0400" <CAO=DXp-+fJwsNegzu3zgwDLtCcSF104AUF=i+_GMgSYVBAKjWg@mail.gmail.com>
References: <cone.1615844513.220592.51342.1004@monster.email-scan.com> <20210315234648.563C0708B340@ary.qy> <CAO=DXp-+fJwsNegzu3zgwDLtCcSF104AUF=i+_GMgSYVBAKjWg@mail.gmail.com>
To: George Schlossnagle <george=40sparkpost.com@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/8nsGg0rA9mU3JbEq61gXeXR1Cx4>
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: Mon, 19 Apr 2021 21:43:23 -0000

> As a commercial MTA and ESP provider, this proposal is very exciting to
> me.  Today we guess at these things and largely guess at things based off
> of either observed behavior or out-of-band discussion with those operating
> the receiver side of the email exchange.  Having this defined in the
> session would be great.

Thanks for the support. 

A question for you: Are there any additional limits you think are sufficiently
important, and perhaps more to the point, in some sense foundational, that they
warrant being in the base specification?

I'm especially interested in people's thoughts on rate limits. The problem I
have with rate limits is, well, how to express them. For example, a rate limit
of 10 transactions a minute is not the same as 600 transactions an hour: In the
former case it's unlikely that a sender will be allowed to bang out 600 messages
in a minute followed by 59 minutes of silence, whereas the latter allows that.

This suggests using a vulgar fraction whatever/second as a means of expressing
rate limits.

Then there's the question of what the limit applies to: Is it by IP, by
(possibly DKIM authenticated) sending domain, by a combination of both, or 
something else?

And all this glosses over the fact that there are any number of ways for
servers to determine a rate.

My personal preference would be to defer this to a subsequent specification -
one which I'm happy to coauthor and even edit, but one where I'd be a lot more
comfortable not being the sole author. But there's an argument to be made that
having a limit that's not a simple integer in the base specification would be a
good thing, in order to prevent people from making assumptions in their
implementations that turn out to be false.

A middle ground would be to put one simple rate limit, say MAILMAXRATEPERIP,
that suffices to establish minimal conventions for such things.

Thoughts?

				Ned