Thank you, Dan and Hans, for your feedback. The reason we decided to accept the email silently was to avoid retries that would pile up on top of the massive flux of new ones incoming. I was aware this would add overhead to our servers. Still, I configured the code only to accept the data and drop them, not calling the database or any resource-intensive systems we generally use.
The situation was hard, but it finally was solved; The user in question had the great idea to ask all their client to point to a CNAME they manage for the MX, which was then redirected to our services. So once we were in contact with them, they moved that CNAME point to something else, resolving the issue in a matter of a few hours (the time it took for the slowest services to process the DNS cache propagation). Clearly, this situation showed us that a badly intentioned person (which wasn't the case here) could do wreckage on our service with us being unable to avoid this (again, we were not sending emails, only receiving bounces. This is definitely in the DDoS area). Fortunately, we were able to increase the number of servers with AWS EC2, so our other users weren't severely impacted, but this feels like it's just a ticking time bomb. This matter is now resolved, and I'm really glad it is! Thank you, everyone, for your support! Best regards, Cyril Le mer. 30 nov. 2022 à 08:52, Dan Malm via mailop <mailop@mailop.org> a écrit : > On 2022-11-23 10:39, Cyril - ImprovMX via mailop wrote: > > Blocking the recipient had the effect that we don't accept emails for > > them anymore, so anyone sending an email via ImprovMX to one of their > > domain will have a 5xx response on the RCPT command. > > That was our initial strategy, the default when we block an account: we > > let the sender know the email wasn't accepted. > > > > But in this case, I realized one thing: It's possible that the sender > > could retry, increasing the number of connections at every new bounce. > > So I've updated the policy on this specific account to accept but > > silently drop any emails for them. > > Silently dropping the mails seems like a bad strategy to me. That would > mean you accept DATA and waste your bandwidth and processing power on > those. If there was no reaction on you returning a 5XX then my strategy > would be to return a 4XX. If the 70K connections per minute actually > translates to 70K unique emails per minute then a defer queue rising by > 70K per minute should be at a scale that I expect gets noticed even by > Microsoft. > > -- > BR/Mvh. Dan Malm, Systems Engineer, One.com > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
