chibenwa commented on a change in pull request #833:
URL: https://github.com/apache/james-project/pull/833#discussion_r781012316
##########
File path: src/adr/0051-email-rate-limiting.md
##########
@@ -0,0 +1,40 @@
+# Email rate limiting
+
+Date: 2021-01-10
+
+## Status
+
+// todo
+
+## Context
+
+Rate limiting is one of the most popular features of any service. They limit
how many emails you can send/receive from/to
+each email account over a given period of time.
Review comment:
I would rather say it is a common feature.
Give examples: SaaS is one. Give a link:
https://www.fastmail.help/hc/en-us/articles/1500000277382-Account-limits#sending/receiving
Another exemple is rate limiting to specific remote host. When I was a
student we had a rule on our mailing list servers of no more than 5 mail.sec to
GMail not to be considered as Spammer, and traffic would be smoothed if needed.
(we did set this up using Postfix)
##########
File path: src/adr/0051-email-rate-limiting.md
##########
@@ -0,0 +1,40 @@
+# Email rate limiting
+
+Date: 2021-01-10
+
+## Status
+
+// todo
+
+## Context
+
+Rate limiting is one of the most popular features of any service. They limit
how many emails you can send/receive from/to
+each email account over a given period of time.
+We believe the rate-limiting will help James has more control of the resource
and easy to dynamic config the user policy.
+
+## Decision
+
+Provide 2 criteria to limit to each duration:
+
+- Number of emails
+- Total size of emails
Review comment:
Rate limiting will be enable per sender, per receiver and globally. For
each we will provide options for email size and email count.
##########
File path: src/adr/0051-email-rate-limiting.md
##########
@@ -0,0 +1,40 @@
+# Email rate limiting
+
+Date: 2021-01-10
+
+## Status
+
+// todo
+
+## Context
+
+Rate limiting is one of the most popular features of any service. They limit
how many emails you can send/receive from/to
+each email account over a given period of time.
+We believe the rate-limiting will help James has more control of the resource
and easy to dynamic config the user policy.
+
+## Decision
Review comment:
We proposes to set up a new maven project dedicated to rate limiting. We
proposes two implementation of rate limitings: in memroy (guava based) and
redis. Please note that this will take the form of an extension jars, that
could be dropped in ones James installation, and thus is optional, and not of a
runtime dependency.
##########
File path: src/adr/0051-email-rate-limiting.md
##########
@@ -0,0 +1,40 @@
+# Email rate limiting
+
+Date: 2021-01-10
+
+## Status
+
+// todo
+
+## Context
+
+Rate limiting is one of the most popular features of any service. They limit
how many emails you can send/receive from/to
+each email account over a given period of time.
+We believe the rate-limiting will help James has more control of the resource
and easy to dynamic config the user policy.
Review comment:
Rate limiting can also be a security requirement for SaaS deployments.
It also minimises impacts of Open-relay types of compromission.
##########
File path: src/adr/0051-email-rate-limiting.md
##########
@@ -0,0 +1,40 @@
+# Email rate limiting
+
+Date: 2021-01-10
+
+## Status
+
+// todo
+
+## Context
+
+Rate limiting is one of the most popular features of any service. They limit
how many emails you can send/receive from/to
+each email account over a given period of time.
+We believe the rate-limiting will help James has more control of the resource
and easy to dynamic config the user policy.
Review comment:
Also add "it complements storage quota".
##########
File path: src/adr/0051-email-rate-limiting.md
##########
@@ -0,0 +1,40 @@
+# Email rate limiting
+
+Date: 2021-01-10
+
+## Status
+
+// todo
+
+## Context
+
+Rate limiting is one of the most popular features of any service. They limit
how many emails you can send/receive from/to
+each email account over a given period of time.
+We believe the rate-limiting will help James has more control of the resource
and easy to dynamic config the user policy.
+
+## Decision
+
+Provide 2 criteria to limit to each duration:
+
+- Number of emails
+- Total size of emails
+
+This can be done via mailets (`PerSenderRateLimit` and
`PerRecipientRateLimit`). Depending on the position in the pipeline this could
allow rating limit all emails in
+transit, relayed emails or locally delivered emails.
+The rate limit will be config in
[mailetcontainer.xml](/server/apps/distributed-app/sample-configuration/mailetcontainer.xml).
+
+Provide the interface `RateLimiter`, that will evaluate the current rate limit
and return result acceptable or exceeded.
+The default implement of RateLimiter will be using [Redis](https://redis.io)
to store the current rate of each email (Redis is an in-memory data structure
store, used
+as a distributed).
+
+We will document such a setup, and provide a mailetcontainer sample file.
+
+## Consequences
+
+- When having change the rate limit config, We need to restart James.
+- The rate limit will not care with which protocol like IMAP, POP3, SMTP, JMAP.
Review comment:
Only protocols allowing to submit emails make sense here so SMTP and
JMAP.
##########
File path: src/adr/0051-email-rate-limiting.md
##########
@@ -0,0 +1,40 @@
+# Email rate limiting
+
+Date: 2021-01-10
+
+## Status
+
+// todo
+
+## Context
+
+Rate limiting is one of the most popular features of any service. They limit
how many emails you can send/receive from/to
+each email account over a given period of time.
+We believe the rate-limiting will help James has more control of the resource
and easy to dynamic config the user policy.
+
+## Decision
+
+Provide 2 criteria to limit to each duration:
+
+- Number of emails
+- Total size of emails
+
+This can be done via mailets (`PerSenderRateLimit` and
`PerRecipientRateLimit`). Depending on the position in the pipeline this could
allow rating limit all emails in
+transit, relayed emails or locally delivered emails.
+The rate limit will be config in
[mailetcontainer.xml](/server/apps/distributed-app/sample-configuration/mailetcontainer.xml).
+
+Provide the interface `RateLimiter`, that will evaluate the current rate limit
and return result acceptable or exceeded.
+The default implement of RateLimiter will be using [Redis](https://redis.io)
to store the current rate of each email (Redis is an in-memory data structure
store, used
+as a distributed).
Review comment:
Those mailets will be based on a generic `RateLimiter` interface. We
will propose two implementations for it:
- In memory (guava based) suitable for single instance deployments
- Redis based, suitable for distributed deployments.
The implementation chosen will be configurable as part of mailet
configuration.
##########
File path: src/adr/0051-email-rate-limiting.md
##########
@@ -0,0 +1,40 @@
+# Email rate limiting
+
+Date: 2021-01-10
+
+## Status
+
+// todo
+
+## Context
+
+Rate limiting is one of the most popular features of any service. They limit
how many emails you can send/receive from/to
+each email account over a given period of time.
+We believe the rate-limiting will help James has more control of the resource
and easy to dynamic config the user policy.
+
+## Decision
+
+Provide 2 criteria to limit to each duration:
+
+- Number of emails
+- Total size of emails
+
+This can be done via mailets (`PerSenderRateLimit` and
`PerRecipientRateLimit`). Depending on the position in the pipeline this could
allow rating limit all emails in
+transit, relayed emails or locally delivered emails.
+The rate limit will be config in
[mailetcontainer.xml](/server/apps/distributed-app/sample-configuration/mailetcontainer.xml).
+
+Provide the interface `RateLimiter`, that will evaluate the current rate limit
and return result acceptable or exceeded.
+The default implement of RateLimiter will be using [Redis](https://redis.io)
to store the current rate of each email (Redis is an in-memory data structure
store, used
+as a distributed).
+
+We will document such a setup, and provide a mailetcontainer sample file.
+
+## Consequences
+
+- When having change the rate limit config, We need to restart James.
+- The rate limit will not care with which protocol like IMAP, POP3, SMTP, JMAP.
+- It is more than acceptable to lose all redis data, which is equivalent to
resting the rate limiting.
Review comment:
resting -> reseting
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
