> Unfortunately, "521" is not a valid response code, and you > must issue "421" if you intend to disconnect. > > I fiddled with a small "550 reject + 421 disconnect" patch for > a while, but it just didn't seem to make enough difference to > be worth the effort of maintaining a local patch of > questionable value. I didn't notice any clients that mistook > it for a temporary error, but the bottom line is it just > didn't seem to make much difference in overall system load. I > think I posted it to the list - check the archives if you're > interested. > > One thing that does help is to set smtpd_hard_error_limit to a > lower value, such as 5, or in extreme cases 1. Note this > affects all rejects, not just specific clients. > > Note that setting smtpd_hard_error_limit "too low"[1] could > significantly delay some mail, specifically legit > multi-recipient mail that is addressed to some valid users > plus greater than smtpd_hard_error_limit invalid users. > > [1] "too low" is a system-dependent value. > > Another thing that helps is setting smtpd_timeout to a lower > value. The default setting of 300s is mandated by the RFCs, > but is overly generous. Collective list experience is that > "smtpd_timeout = 30s" is unlikely to affect legit mail, > assuming a non-saturated incoming link. > > YMMV etc. > > -- > Noel Jones
Thank you for the answer. I'll try to explain my position. I prepearing postfix setup as a relay for several backend mail servers as a filter. And loads seems to be very high. At least count of rejected connections on one server now going up to 4 millions in day. So configuration should be as stable under stress as it could. I have set smtpd_delay_reject = no, smtpd_error_sleep_time = 0s and other pretty things. It also would be good to drop connection, not wait host drop it by himself. But 421 code not suitable because of: "The down-side of sending 421 instead of the default 554 is that it works only for zombies and other malware. If the client is running a real MTA, then it may connect again several times until the mail expires in its queue." With something like 521 normal clients would not wait until expire, but would see error in time. //I'll try to find patch in archives, thanks.
