Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT

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

George

On Mon, 19 Apr 2021 at 17:43, Ned Freed <[email protected]> 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
> MAILMAXRATEPERIP,
> that suffices to establish minimal conventions for such things.
>
> Thoughts?
>
>                                 Ned
>


-- 
*GEORGE SCHLOSSNAGLE*
chief evangelist
www.sparkpost.com
(el) [email protected]

_______________________________________________
ietf-smtp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp