On Sat, Oct 11, 2025 at 01:38:59AM +0000, Dan Mahoney (Gushi) wrote: > On Wed, 8 Oct 2025, Matija Nalis wrote: > > own, I'd do "strace -ff -tt -p `pidof dccifd`" to try to see where it fails > > dccifd is producing *these* logs. > > What I am pretty sure is happening is that we have the "shortcircuit" plugin > installed, and so if a shortcircuit=spam fires, it hangs up on dccifd > without properly closing the connection.
Quite possible (that strace should confirm that, but correlating with other logs as you did should be good enough evidence for most). However, in that case, isn't that the very reason for shortcircuiting? I.e. to free up resources early by "dirty-closing/aborting" the connection (instead of having resources tied up waiting for dccifd to process the query so you can "properly close" the connection?) > Any ideas as to how to tell SA not to shortcircuit this, or how to close the > dccifd connection in a more clean way? I believe Mail::SpamAssassin::Plugin::Shortcircuit man page contains documentation on how to disable shortcircuiting for some tests (I have not used that functionality, though). Of course, while short circuiting DCC might be just fine, it might be unwanted in your case -- it depends on exact reason WHY you enabled shortcircuiting in the first place. > Oct 9 11:02:02 post dccifd[834]: write(MTA socket,843): Broken pipe > Oct 9 17:33:56 post dccifd[834]: write(MTA socket,840): Broken pipe If your conclusion above is correct (which seems very likely), those are harmless and can be safely ignored, so there is no actual problem, right? And if it is just that you find those lines annoying in the logs, but still want to shortcircuit dccifd, there is also an option to filter them out before writing logs to disk. E.g. for rsyslog see: https://www.rsyslog.com/doc/configuration/filters.html -- Opinions above are GNU-copylefted.
