Date: 2021-01-10
Accepted (lazy consensus).
Not yet implemented.
Rate limiting is one of the common features expected from an email system. Examples: SaaS is one https://www.fastmail.help/hc/en-us/articles/1500000277382-Account-limits#sending/receiving , https://support.google.com/mail/answer/22839
They limit how many emails users can send/receive from/to each email account over a given period of time.
We believe the rate-limiting will help James to have more benefits:
Set up a new maven project dedicated to rating limiting. This allows the rate limiting mailets to be embedded in a James server as a soft dependency using the external-jar loading mechanism. Please note that this will take the form of an extension jar, that could be dropped in one's James installation, and thus is optional, and not a runtime dependency.
Rate limiting will be enabled per sender, per receiver and globally. For each we will provide options for email size and email count.
This can be done via mailets:
Those mailets will be based on a generic RateLimiter interface. We will propose two implementations for it:
We will base on RateLimitJ to provide the implementation. It is a Java library for rate limiting, assembled using extensible storage (Redis) and application framework adaptors. Its library's interfaces support thread-safe sync, async, and reactive usage patterns which is suitable for our reactive pipeline.
The implementation chosen will be configurable as part of mailet configuration. One would be able to configure the implementation he wishes to use.
Alternatives implementation of the rate limiter can be proposed, and used within the aforementioned mailet.
For instance one could rely on Cassandra counters and Cassandra time series (thus not needing additional dependencies) however we fear the potential performance impact doing so. Streaming based options, that aggregate in memory counters, might be a viable option too.