Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[enh] Avoid to send simultaneously too much emails #691

Merged
merged 3 commits into from May 17, 2019

Conversation

Projects
None yet
3 participants
@zamentur
Copy link
Contributor

commented Mar 19, 2019

The problem

It seems possible for a user to send thousand of emails simultaneously. It's pretty cool but a bit risky.

Solution

Set up a rate delay of 12s to avoid to send simultaneously to the same destination server.

PR Status

Ready, currently in test with one of my server

How to test

service postfix reload

Next send a lot of emails and check delays.

Validation

  • Principle agreement 0/2 :
  • Quick review 0/1 :
  • Simple test 0/1 :
  • Deep review 0/1 :
@maniackcrudelis

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2019

One email every 12s maximum ? What about scripts that send emails ?

@zamentur

This comment has been minimized.

Copy link
Contributor Author

commented Mar 19, 2019

One email every 12s to a same destination. But yes if a script send more than 1 message every 12s it could be a problem. On the other hand, sending 1msg per 12s with a script to the same destination could be dangerous or simply completely fill the inbox of the final recipient.

Have you a particular script in mind ?

@maniackcrudelis

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2019

I have especially a script that sends me emails as soon as my webcam see something moving in my flat.

But, between "thousand of emails simultaneously" and one per 12s, I hope there's a middle value. Like one per second.

@alexAubin

This comment has been minimized.

Copy link
Member

commented Mar 19, 2019

But is your webcam likely to send you several emails per second ? And is it a normal / wished behavior ? o.O

@maniackcrudelis

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2019

Not several per second, but several per 12s yes.
And that's just one of my use case. 2 or 3 emails during 12s does not seems like too much emails. Depending of what's happening at this time on the server.
For sure thousand of email at a time is a problem, but we shouldn't limit to 1/12s because we do not have that usage.

@zamentur

This comment has been minimized.

Copy link
Contributor Author

commented Mar 20, 2019

Note: if there is momentarily more than one email per 12s it is not a problem, the emails will be sent with a delay that's all.

But we can increase the frequency effectively.

About "1s", it seems quite strange to send to a same server 3600 emails in hour ! At this rate, your server could be blacklisted easily...

@zamentur

This comment has been minimized.

Copy link
Contributor Author

commented Mar 20, 2019

For sure thousand of email at a time is a problem, but we shouldn't limit to 1/12s because we do not have that usage.

I think we can find a better rate. I was not aware of this kind of usecases Important: it's not a rate that put into trash bin set of emails sending in the same time, it is just distributed over time.

I understand specific use case with a lot of emails to send, but we need to think about ynh instances with RBL's issues or the free.fr filters... Big mail servers are more and more strict...

@maniackcrudelis

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

I'm not against a rule to prevent server to be used as spam relay.
But we should just be careful to not hind legit use cases.

@alexAubin alexAubin added this to the 3.6.x milestone Apr 1, 2019

@alexAubin

This comment has been minimized.

Copy link
Member

commented Apr 22, 2019

Soooo what do we do with this ? Would 1 email every 5 second would be a better rate ?

@alexAubin

This comment has been minimized.

Copy link
Member

commented May 14, 2019

So idk, arbitarily switched to 5s if that pleases more people ... Feel free to suggest other values ...

Otherwise planning to merge soonish to move forward

@alexAubin alexAubin merged commit d7a90d6 into stretch-unstable May 17, 2019

0 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/travis-ci/push The Travis CI build is in progress
Details

@alexAubin alexAubin deleted the enh-email-rate-limit branch May 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.