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

George Schlossnagle <> Mon, 19 April 2021 23:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E82E3A4955 for <>; Mon, 19 Apr 2021 16:33:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L5SNuA3nxtrc for <>; Mon, 19 Apr 2021 16:33:34 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68E803A4957 for <>; Mon, 19 Apr 2021 16:33:34 -0700 (PDT)
Received: by with SMTP id mh2so33962924ejb.8 for <>; Mon, 19 Apr 2021 16:33:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HFq+2TUZzobkJJBOYp62KwkU3FUHU/MWMQw1ny9w6Hg=; b=EkbAvH30USHq4WhUIBwC29t2SVIYc7Xvnb1KGVjuEZgS8q91mzpDeL9z2UyoFx0pvh bYdwsIjZIz8clw3jm1yXX0i2L+GuitH3tAuzKCcZP7BV9YNXBzOwhP9XIA+u/UzfTpt+ mf/9JXhpTmDHcP0jM0eLxRragjR2omgRLPSfM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HFq+2TUZzobkJJBOYp62KwkU3FUHU/MWMQw1ny9w6Hg=; b=nsK8qFZX/ZzfdBAfaSkUpKWu31oYfq/XKvYBecwZoOteye9agA8/I7ByVHjS85+pPR 1NCilZOeXttPZGjfPyaS6bpuhlNTaGVj6RinLQ3wWlMmU3NGVPf4DCPEYKsA4InHZIpQ vUwIxxFPwdzgiKtc8ef/aPkIe8TUd98KLpfCnBUygw0F+U2jWyWFECS5bdcqKjuK9tJT CNJ9yxKua8FJTaBfNI53r9Y5bMSCjXwC8/seB06W7dT7OudiYiyhAfe22QkIZRYaxKmX IpRV4Nw3v+VpTPGZm1/tNgzDrW9PwNMrW0mmVv6d7lTN9cWlK9Tf82T/1iXTkPt2e1ay L10A==
X-Gm-Message-State: AOAM530XSO+nbKM8xNIrAz95+efCPOzsB7Gs/9DED2wLjOAatfDY3Ms+ 7hyK6vGCvu1REWAdUH5fuACLHYvksf3u1npckwto
X-Google-Smtp-Source: ABdhPJxU3z9yh5oPmg9GB4ULUlnhTCYy2CJIPFVUVIlrSXZUY33VAf+WOREJBWtg4oNbYRRujczaUm3w2NoyxI7uwhs=
X-Received: by 2002:a17:906:5fc2:: with SMTP id k2mr25086432ejv.354.1618875211900; Mon, 19 Apr 2021 16:33:31 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210315234648.563C0708B340@ary.qy> <> <>
In-Reply-To: <>
From: George Schlossnagle <>
Date: Mon, 19 Apr 2021 19:32:55 -0400
Message-ID: <>
To: Ned Freed <>
Cc: John Levine <>,,
Content-Type: multipart/alternative; boundary="000000000000f1047205c05bc14e"
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: Mon, 19 Apr 2021 23:33:39 -0000

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)
Message throughput rate (messages/time period where time period is
typically per second, per minute or per hour)
Connection establishment rate (connections/time period where time period is
typically per second, per minute or per hour)
Simultaneous connections per sending IP block (seems particularly hard to
handle here)
Recipients per connection (aggregated across all messages in that
Bytes sent per time period.

While I agree with Michael that these things can change during the session,
in my experience that's uncommon and that a method of signaling that works
in a majority of cases but still recognizes that providers can 'change the
rules' on the fly in the ways they do now (sending often provider-specific
SMTP response codes) is still a much better place to be.

Thanks again for taking this up.


On Mon, 19 Apr 2021 at 17:43, Ned Freed <> wrote:

> > 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
> that suffices to establish minimal conventions for such things.
> Thoughts?
>                                 Ned

chief evangelist