On 3/6/2012 8:49 PM, Alex wrote: >> -o smtpd_recipient_restrictions=permit_mynetworks,reject
> Isn't this effectively what I already have? I must be missing > differences somewhere? You're missing a recipient_restrictions override. Without one, your submission connections are subject to dnsbl checks when auth fails. This is why you saw that ZEN rejection. You should _never_ check submission connections against dnsbls. ZEN contains the PBL, which contains consumer dynamic IP ranges. This is where clients typically connect from. Using the above override prevents the dnsbl checks you have configured in main.cf. In your case it won't reject a client connection because of your restriction ORDER, but it will cause those ZEN errors in the log, which can be very confusing, as you already discovered. It made you think the problem was in a place it did not exist. > submission inet n - n - - smtpd > -o smtpd_tls_security_level=encrypt > -o smtpd_sasl_auth_enable=yes > -o smtpd_client_restrictions=permit_sasl_authenticated,reject > -o milter_macro_daemon_name=ORIGINATING > -o syslog_name=postfix/submission > Just to be clear, I'm missing no_address_mappings in the > receive_override_options in order to prevent the duplicated always_bcc > mail, correct? I'm not sure on that one. Someone else will need to chime in. > You're saying here that the reject_rbl_client at the end of the > smtpd_recipient_restrictions would be skipped because it would be > auth'd by permit_sasl_authenticated, correct? Yes. At least, that's what we're assuming based on restriction ORDER in your Postfinger output. > I think I'm still going to have to do more research on finding that > right default_process value. There is a problem here. You have found a knob you can turn and get something like the result you want. But, this is not the right knob to be turning to address your load problem because it simply masks the real problem. And it can cause larger problems later when your connection load continues to increase. You increased the process limit on one machine from 100 to 300, and on another machine from 100 to 200. The peak connection load on each actually increased as well, but not enough to overwhelm the new process limit. When you get hit by enough bulk mailers concurrently, a process limit of 500 may not be enough to mask the problem any longer, and you're back where you started. Thus, the permanent solution is to dramatically slow down the bulk mailers. I've given you one method in the previous email that should do exactly that, instantly, while keeping default_process_limit=100. -- Stan
