> > I'm thinking about trying the example suggested in the documentation for > > "sleep": > > > > > > /etc/postfix/main.cf: > > smtpd_client_restrictions = > > sleep 1, reject_unauth_pipelining > > smtpd_delay_reject = no > > > > In general, I try to order smtpd_*_restrictions with the least costly > > first, >so > > this would be an exception. Has "sleep" shown to be: > > > > * effective? > > Not particularly. The sleep command was an early attempt to reject bots > that >start talking before it's their turn. The idea is: > sleep 1 (don't say anything for a while - pick up the phone without saying >hello) > reject_unauth_pipelining (if the caller starts talking before we greet them, >they are a bot/recording so hang up) > > Problems with sleep (ie. good reasons to not use it): > - not many bots fall for the trick. > - requires "smtpd_delay_reject = no" which can create other issues with >logging and restriction flow, particularly for casual postfix users. > - penalizes every client on every connection > - ties up a valuable smtpd process with doing nothing. > > The postscreen feature in postfix 2.8 eliminates those problems, and adds >other features not possible/practical in the regular smtpd listener. > > Your best choice is to upgrade to current postfix. If you can't do that, a >greylist policy service is probably the next best thing. > > > On a related note, is there any reason this example adds > > "reject_unauth_pipelining" after "sleep"? > > The reject_unauth_pipelining is what causes the bad clients to be rejected. > > > Is using "sleep" alone with nothing > > else OK? > > Using sleep by itself won't break anything, but it doesn't do anything > except >slow everything down. > > Slowing the server down gives no benefit, and in the case of a server that's >close to overload, could push it over the edge.
Ah, excellent responses Noel and Stan. I understand very well now. I really appreciate the detailed explanations. > > I'm using version 2.3.3, and the docs say "reject_unauth_pipelining" > > is only recommended in smtpd_data_restrictions for older versions (but >doesn't > > say why or if it will hurt to have it anywhere else). > > You should really upgrade. The final update for the postfix 2.3 series > before >EOL was 2.3.19 in Aug 2009. > > If 2.3.3 is the best your vendor can provide, you should complain strongly. OK I hear that loud and clear. There's a few hitches involved (DB support, etc), but that's probably all the more argument to simply move to one of Simon's packages. Maybe that's the best choice. We'll work on that, but I must say that one of the things I appreciate the most about postfix is that we can languish in a stale version that's not even being supported and we're still not vulnerable to any security issues. > In older postfix versions with recommended default smtpd_delay_reject = yes, >the reject_unauth_pipelining > restriction is only effective in smtpd_data_restrictions. It doesn't hurt >anything if used in other sections, it just > doesn't do anything. That's also why the example shows setting >smtpd_delay_reject = no. >
