A fully-searchable and accessible archive of court data including growing repositories of opinions, oral arguments, judges, judicial financial records, and federal filings.
We should put a soft-limit on the number of emails we can send on a rolling 24 hour basis. Right now our quota in AWS is 100,000 emails per 24 hours on a rolling basis, and we never come close to hitting it except when we're under attack like yesterday.
Can we design a rolling quota in redis with a limit of 50k emails set via a django setting? The idea is that if we ever go over 50k emails in any 24 hour period, we throw huge, repeating errors until we figure out what's going on. (The errors should contain the stack trace, so probably throwing errors in Sentry is smart)
I think we can call this feature the email emergency brake and have useful errors like "Emergency brake engaged".
For any URL that sends emails (registration, change password, forgot password, etc), we can use django-ratelimit to put a global limit how many requests the URL can get per some period of time. We use django-ratelimit to limit based on IP addresses in a number of places, so we just need to add an additional rate limit decorator that doesn't use any key at all. It's better for the registration page to break completely than for us to exceed this kind of quota again.
Eduardo, I think this will be a good one for you, but Alberto is our email expert. Therefore, Alberto, can you please make yourself available if Eduardo has any questions about how the email system works?
Responding to the attack detailed here, we have a few further steps to take:
We should put a soft-limit on the number of emails we can send on a rolling 24 hour basis. Right now our quota in AWS is 100,000 emails per 24 hours on a rolling basis, and we never come close to hitting it except when we're under attack like yesterday.
Can we design a rolling quota in redis with a limit of 50k emails set via a django setting? The idea is that if we ever go over 50k emails in any 24 hour period, we throw huge, repeating errors until we figure out what's going on. (The errors should contain the stack trace, so probably throwing errors in Sentry is smart)
I think we can call this feature the email emergency brake and have useful errors like "Emergency brake engaged".
For any URL that sends emails (registration, change password, forgot password, etc), we can use django-ratelimit to put a global limit how many requests the URL can get per some period of time. We use django-ratelimit to limit based on IP addresses in a number of places, so we just need to add an additional rate limit decorator that doesn't use any key at all. It's better for the registration page to break completely than for us to exceed this kind of quota again.
Eduardo, I think this will be a good one for you, but Alberto is our email expert. Therefore, Alberto, can you please make yourself available if Eduardo has any questions about how the email system works?