On 3/6/2012 8:01 PM, Alex wrote: > I don't recall seeing an email from you with that information. Can I > ask you to resend, and I'll follow up with her?
It was delivered to your Gmail mailbox yesterday: /var/log/mail.log:Mar 5 16:37:55 greer postfix/smtp[25300]: CB3636C052: to=<mysql*******@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.65.26]:25, delay=1.5, delays=0.01/0.06/0.77/0.66, dsn=2.0.0, status=sent (250 2.0.0 OK 1330987075 e42si17985261yhh.147) And she replied to both of us this morning: /var/log/mail.log:Mar 6 08:57:18 greer postfix/qmgr[1241]: 1D3D86C052: from=<tna*****@constantcontact.com>, size=2711, nrcpt=1 (queue active) > While I think it might be helpful to contact CC, this is just one > example where the server is overloaded. I'd really like a more What you fail to realize is that Tara can give you valuable insight into how ALL bulk mailers tend to behave, not just CC specific stuff. She's got a lot of experience in the bulk mail business. > 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. > As it turns out, before I could hardly notice, the server was hit with > a large amount of connections from everbridge.net, resulting in a few > thousand messages being deferred: Please be technically specific: were all of these connections from a single IP address at everbridge.net or multiple IP addresses? If a single IP, the method I described above should fix this instantly. If multiple IPs this solution will help some, but may not fully solve the connection load problem. I.e. they hit you from dozens of IPs. > 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. 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. 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. -- Stan
