June 16, 2024 2:12 PM, "Kirill A. Korinsky" <[email protected]> wrote:
> On Fri, 14 Jun 2024 01:53:48 +0100, > Kirill A. Korinsky <[email protected]> wrote: > >> Thus, I thought that I made something wrong and tried getrrsetbyname_async >> without any success. > > Indeed I did: run asr_abort without decreasign counters which leads to > deadlock. Thus, asr debug log was useless due to missed debug output inside > asr_abort [1]. > > Anyway, I still not sure that it is correct behaviour that filter may block > processing of email indenfently. > I think you are wrong in how you think of the issue: it is indeed not correct behavior for a filter to block the processing of mail, so... maybe the filter should just not do it to begin with ? :-) Unlike MDA which are executed at delivery time and can retry, filters are not graceful, they can't be retried, they affect directly the SMTP engine, so the contract we have for the API is: do not misbehave. 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.
