Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT

"John R Levine" <[email protected]>
Newsgroups gmane.ietf.smtp
Message-ID <[email protected]>
It looks like something like this would handle a lot, quite possibly most, 
of the rate limits that receivers are willing to disclose:

   CONNRATE=m/s MSGRATE=m/s

Where m is a number of connections or messages or whatever, and s is a 
number of seconds.

I suppose it could also have something like SCOPE=HOST or SCOPE=GROUP to 
say whether it's for a single host or a group but I don't see any way of 
describing groups that wouldn't be too complicated and I doubt that many 
mail providers would want to tell hostile strangers that much about their 
internal architecture.

R's,
John


On Tue, 20 Apr 2021, Ned Freed wrote:
>>> A little surveying might be in order.
>
>>> I see that Postfix lets you set both the numerator and denominator of
>>> the rate limit, but the denominator defaults to a minute.  It has
>>> separate rate limits for connections and messages.
>
>>> Exim also lets you set both, the examples use an hour.  The
>>> documentation says that if you use a large interval that lets people send bursts.
>
>> Sounds familiar. Oracle Messaging Server lets you set both; the denominator default is one hour.
>
>> We store the limits in memcache or Redis so they can apply across mutiple MTAs.
>> The usual limit is per-IP, but we support per-host and per-domain as well.
>
>> The demoninator in PowerMTA is a string rather than a number, possible values are sec, s, min, m, hr, or h. It supports per-IP and per-host and probably other stuff; my familiarity here is limited.
>
>> I assume the Exim and Postfix limits are per-host, which in most cases translates to per-IP.
>
>> I have to say there's more consistency here than I expected.


Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.