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

Michael Peddemors <> Mon, 19 April 2021 22:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 156C13A454C for <>; Mon, 19 Apr 2021 15:01:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.275
X-Spam-Level: *
X-Spam-Status: No, score=1.275 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_NONE=1.274, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KaCc2I8e_dUT for <>; Mon, 19 Apr 2021 15:01:42 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 8163A3A406D for <>; Mon, 19 Apr 2021 15:01:42 -0700 (PDT)
Received: (qmail 17758 invoked from network); 19 Apr 2021 22:01:41 -0000
Received: from (HELO []) ( by with (DHE-RSA-AES128-SHA encrypted) SMTP (d23e565a-a15a-11eb-a05c-9bf32caabe18); Mon, 19 Apr 2021 15:01:41 -0700
References: <> <20210315234648.563C0708B340@ary.qy> <> <>
From: Michael Peddemors <>
Organization: LinuxMagic Inc.
Message-ID: <>
Date: Mon, 19 Apr 2021 15:01:41 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-MagicMail-OS: Linux 3.11 and newer
X-MagicMail-UUID: d23e565a-a15a-11eb-a05c-9bf32caabe18
X-MagicMail-RegexMatch: 0
X-MagicMail-EnvelopeFrom: <>
X-Archive: Yes
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 22:01:48 -0000

On 2021-04-19 2:18 p.m., Ned Freed wrote:
> 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.

The question is, in many cases the rate limits will change during the 
course of the SMTP connection..

And we may not have enough information to declare a rate limit, and 
declaring a rate limit that isn't accurate means it isn't smart to 
advertise a limit that is not guaranteed.

That rate limit may change on many variables that occur during the SMTP 

And because of this, many MTA's will not be able to advertise one 
correctly, I know that in our MTA's that will be the case, and of course 
we expect that any sender properly handles any form of instruction to 
stop sending, whether any pre-advertised limit is in place or not.

Given that, (MTA's ability to respond to a 'stop sending' (4xx or 5xx)) 
we will continue using dynamic rate limits, rather than preset limits, 
instead of implementing two mechanisms.

I am sure others out there with advanced SMTP architectures are facing 
the same concerns.

"Catch the Magic of Linux..."
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at @linuxmagic
A Wizard IT Company - For More Info
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.