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
<ned(_dot_)freed(_at_)mrochek(_dot_)com> 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) george(_at_)sparkpost(_dot_)com
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp