Thank you, Viktor. I am planning to look at increasing the size of the Active queue however I would need to resize to a minimum of 50x based on past events.
> You can also configure a non-zero smtpd_client_message_rate_limit Hmmmm, not so sure about that. The docs do advise against this for legitimate traffic - and I've yet to see anything in the documentation that describes what happens when these rates are exceeded is it a 4xx? a 5xx? Is the IP just blocked? I now know that the config settings do not do what I expected - which is unfortunate as this would have been a very simple solution. > you could use a policy service to impose rate limits per SASL login, or sender address I had not considered that as a means of load balancing across the available relays (delaying the message at the origin is very much a last resort). I will do some reading on this. C. On Thu, 7 Mar 2024 at 13:46, Viktor Dukhovni via Postfix-users < postfix-users@postfix.org> wrote: > On Thu, Mar 07, 2024 at 12:26:06PM +0000, Colin McKinnon via Postfix-users > wrote: > > > I look after a SAAS site where customers can send emails to their own > > domains. At times some of our customers can initiate sending of large > mail > > volumes - which can swamp the active queue. > > Given sufficient memory, you can substantially raise the active queue > size limit. Servers have a lot more RAM now than they did in 2001. > The default of 20,000 could easily be raised by 10x to 200000 on a > server-class machine. > > If customers indeed send mail only to their own domain, the destination > concurrency limits should ensure fairness, given sufficient space in the > queue and sufficiently many delivery agent slots. > > Speaking of delivery agent slots, if you have enough network bandwidth, > you can raise the smtp(8) delivery process limit in master.cf from 100 > to 1000: > > smtp unix - - n - 1000 smtp > > Not that this could require some system-dependent tuning of the open > file hard limit in whatever code starts Postfix, if the limit is not > already very generous (on a Fedora 39 system with 65GB RAM, "ulimit -Hn" > reports ~1.8 million max open files). > > > >From [1]: > > "The only way to reduce congestion is to either reduce the input rate or > > increase the throughput. Increasing the throughput requires either > > increasing the concurrency or reducing the latency of deliveries." > > I am suggesting increasing concurrency, and also increasing the queue > depth to allow your customer to send larger bursts of mail without > overflowing the queue size limit. You can also configure a non-zero > > smtpd_client_message_rate_limit > > if abuse of your resources is plausible even with the larger queue size. > If that's too crude, you could use a policy service to impose rate > limits per SASL login, or sender address, ... > > > I thought that reducing TRANSPORT_recipient_refill_limit and > > TRANSPORT_recipient_limit would prevent messages sent to the customers > > domain from dominating the active queue / prevent blocking of other > > customers / backup messages in the incoming queue. > > These controls affect deliveries of single messages with many > recipients, but have no effect on a flood of single-recipient messages. > > -- > Viktor. > _______________________________________________ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org > -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCM d s+:+ a+ C+++(---)$ UL+++ P+(--) L+++ E--- W+++ N++ w-- PS++(+++()) t+ 5+ X R- tv-- b++ DI++ D e+++ h---- ------END GEEK CODE BLOCK------
_______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
