mouss wrote:
Alex wrote:
Hello everyone!
Do we have some 5xx error code, which drop connection immediately as
it fo
421?
No. and it's even worst: even if you implement code that does so, the
client will probably ignore the 5xx error and consider the disconnect as
a temp failure. so all you get is 421 behaviour.
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
