Hi, >> far-reaching solution. I've used tc and cbq for QoS a long time in the >> past, but not sure I could now figure out how to use it to throttle >> SMTP traffic now. > > If you want a global solution to the parallel client connection problem, > this is it: > > smtpd_client_connection_count_limit=1 > > This limits the number of parallel connections a client is allowed to > open to Postfix. This 'might' unduly slow delivery from legit non bulk > senders as well so you may need to play with different values until you > achieve the desired results. If this technique turns out to not be > suitable... > > Simply add CC's and other bulk sender IP addresses and/or subnets to the > table we discussed earlier in the thread, in the context of the postfwd > policy daemon or iptables rules.
Okay, great. I don't think I understood your previous post regarding the IP list and the policy daemon. I'll have to research that further. All the connections from everbridge.net were from the same IP. >> Mar 6 18:05:34 mail01 postfix/error[13144]: 59C26156326F: >> to=<01...@example.com>, relay=none, delay=557, delays=439/118/0/0.11, >> dsn=4.4.2, status=deferred (delivery temporarily suspended: lost >> connection with 127.0.0.1[127.0.0.1] while receiving the initial >> server greeting) > > So amavis is failing. The above should fix this. > >> I'm pretty sure it was related to that, as I haven't had these types >> of messages in quite a while. I had to increase the >> default_process_limit back to 200 and forcibly restart amavisd, after >> which it delivered all the messages without further issues. > > Please note that increasing default_process_limit also increases > smtpd_client_connection_count_limit to half that value, if you haven't > manually specified a value for the latter. I.e. 200 processes equals > 100 connections per client IP. Lucky for you bulk senders don't > configure their outbounds with unlimited parallel connections, or > increasing process limit wouldn't help you, but could make things worse. I think I made the mistake of possibly combining two issues in the same email. I had previously adjusted the default_process_limit to 300 because connections to the server were timing out, not because amavisd was dying or regarding the bulk senders issue. I believe then you asked to report back the minimum value that was possible for this setting, which is why I set it to 100. I then had the amavisd issue, and combined with removing the reject_rbl from smtpd_recipient_restrictions and only having it in postscreen, I thought setting the default_process_limit back to the default of 200 was reasonable. This was also all on the same host. Well, actually two hosts; the primary and secondary MX for my domain. Hopefully that's more clear now. The secondary is definitely more idle than the first, even though they are equally weighted. > How many Postfix servers are in your MX farm? When you make changes to > one host slowing down client delivery, smart bulk senders will simply > avoid your slow MX and hammer the others in the MX pool. When you make > a change to one that slows clients down you need to make the same change > to all of them. Yes, understood. There are two MXs for the domain that has the bulk mailing overload problem and the one I'm adjusting the default_process_limit. There is one MX for the domain that has the always_bcc issue and the submission port auth issue. > Try setting smtpd_client_connection_count_limit=1 on all your postfix MX > hosts and see how that works for a day or two. If legit non-bulk > clients are seeing too much delay, bump the value up in increments of 1 > until you get legit clients moving as they should while still preventing > bulk-mailers from bogging you down. That's awesome. I will read about that further, but very happy to learn this option exists. That is the option I was trying to describe all along. Thanks for reading all this. Alex
