You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Tung Tran Van <tu...@gmail.com> on 2022/01/10 09:22:03 UTC
New feature: Email rate limiting
Hello community!
Linagora-email-team proposes the email rate-limit feature to James.
Rate limiting is one of the common features. 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 you can send/receive from/to each email account
over a given period of time.
We believe the rate-limiting will help James have more control of the
resource and easy to dynamic config the user policy. It also complements
the storage quota.
We propose to set up a new maven project dedicated to rating limiting. We
propose two implementations of rate limitings: in-memory (guava based) and
Redis. Please note that this will take the form of extension jars, that
could be dropped in one James installation, and thus is optional, and not
of a runtime dependency.
We will enable rate-limiting on the count of emails and total size for
sending and receiving use cases.
JIRA link: https://issues.apache.org/jira/browse/JAMES-3693
Best regards,
Tung, TRAN VAN
Re: New feature: Email rate limiting
Posted by Benoit TELLIER <bt...@apache.org>.
+1
I just want to add that rate limiting combined with requeues (which can
be provided via a separate mailet) can enable traffic smoothing
(rescheduling of the email traffic not to exceed a rate). The use of the
pulsar mail queue could allow to achieve this in a distributed fashion.
Brest regards,
Benoit TELLIER
On 10/01/2022 16:22, Tung Tran Van wrote:
> Hello community!
>
> Linagora-email-team proposes the email rate-limit feature to James.
>
> Rate limiting is one of the common features. 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 you can send/receive from/to each email account
> over a given period of time.
> We believe the rate-limiting will help James have more control of the
> resource and easy to dynamic config the user policy. It also complements
> the storage quota.
>
> We propose to set up a new maven project dedicated to rating limiting. We
> propose two implementations of rate limitings: in-memory (guava based) and
> Redis. Please note that this will take the form of extension jars, that
> could be dropped in one James installation, and thus is optional, and not
> of a runtime dependency.
>
> We will enable rate-limiting on the count of emails and total size for
> sending and receiving use cases.
>
>
> JIRA link: https://issues.apache.org/jira/browse/JAMES-3693
>
>
> Best regards,
> Tung, TRAN VAN
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: New feature: Email rate limiting
Posted by Tieu Giang Nguyen Cat <ti...@gmail.com>.
+1
^^
On Tue, Jan 11, 2022 at 10:54 AM Rene Cordier <rc...@linagora.com> wrote:
> +1,
>
> Rene.
>
> On 10/01/2022 16:22, Tung Tran Van wrote:
> > Hello community!
> >
> > Linagora-email-team proposes the email rate-limit feature to James.
> >
> > Rate limiting is one of the common features. 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 you can send/receive from/to each email
> account
> > over a given period of time.
> > We believe the rate-limiting will help James have more control of the
> > resource and easy to dynamic config the user policy. It also complements
> > the storage quota.
> >
> > We propose to set up a new maven project dedicated to rating limiting. We
> > propose two implementations of rate limitings: in-memory (guava based)
> and
> > Redis. Please note that this will take the form of extension jars, that
> > could be dropped in one James installation, and thus is optional, and not
> > of a runtime dependency.
> >
> > We will enable rate-limiting on the count of emails and total size for
> > sending and receiving use cases.
> >
> >
> > JIRA link: https://issues.apache.org/jira/browse/JAMES-3693
> >
> >
> > Best regards,
> > Tung, TRAN VAN
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
Re: New feature: Email rate limiting
Posted by Rene Cordier <rc...@linagora.com>.
+1,
Rene.
On 10/01/2022 16:22, Tung Tran Van wrote:
> Hello community!
>
> Linagora-email-team proposes the email rate-limit feature to James.
>
> Rate limiting is one of the common features. 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 you can send/receive from/to each email account
> over a given period of time.
> We believe the rate-limiting will help James have more control of the
> resource and easy to dynamic config the user policy. It also complements
> the storage quota.
>
> We propose to set up a new maven project dedicated to rating limiting. We
> propose two implementations of rate limitings: in-memory (guava based) and
> Redis. Please note that this will take the form of extension jars, that
> could be dropped in one James installation, and thus is optional, and not
> of a runtime dependency.
>
> We will enable rate-limiting on the count of emails and total size for
> sending and receiving use cases.
>
>
> JIRA link: https://issues.apache.org/jira/browse/JAMES-3693
>
>
> Best regards,
> Tung, TRAN VAN
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org