On Mon, 17 Jun 2024 23:56:34 +0100,
gil...@poolp.org wrote:
> 
> June 16, 2024 2:12 PM, "Kirill A. Korinsky" <kir...@korins.ky> wrote:
> 
> In your specific case, you had a descriptor leak and a deadlock... what would
> be the best option for OpenSMTPD to cope with these ? your filter isn't going
> to end up closing descriptors so you're already toast no matter what we do...
> as for the deadlock, we could try to detect it, but we're already going to be
> hitting the session timeout and the filter will still be in a broken state by
> the next time we enter it.
> 
> The only improvement I see here is that if we could detect deadlock early, we
> could kill smtpd right away.

I spent some time to think about it, and I feel that killing smtpd is the
right move.

As you points before it dies when filter misbehave, and not reply for a
while, let say for 15 minutes, it defently misbehaving.

From another hand, such timeout should be large enough and announced to
filter, because the filter may do DNS requests and it can be quite slow.

-- 
wbr, Kirill

Reply via email to