Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT

> 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