Short form: Passing extra file descriptors to the filter command can prevent it
from detecting EOF or EPIPE.  Result, dead filter commands that never
terminate.  Close everything except fd 0, 1, 2 before running the filter
command.

Long form: At the point that the filter command is forked and executed,
proxsmtd may have multiple children with multiple pipes open.  fork() bumps the
reference count on all the file descriptors that are open at that moment.  When
the parent closes its part of the pipe, the pipe fd may or may not be removed
from the system, depending on how many children have accidentally inherited
that pipe.

The child code closes fd 0, 1 and 2, calls dup2() to map the pipes to 0, 1 and
2 then runs.  If another child has accidentally bumped the reference count on
the pipes to this child then fd 0 can have multiple writers.  This prevents the
filter from detecting EOF or EPIPE when proxsmtpd closes the pipe to this
particular child.  This bug is particularly evident if the filter program does
another fork and uses more pipes to communicate with its own child.  awk does
this as a matter of course.

The result is a dangling filter command just sitting there waiting for input
and not detecting that stdin has been closed.  The dangling commands are owned
by pid 1 rather than proxsmtpd.  The only way to get rid of them is to manually
kill them.

Sometimes waitpid(-1) in cb_check_data reaps a child that has just terminated,
before waitpid(pid) in wait_process can reap it.  Linux waitpid(pid,,WNOHANG)
may not return an error if the child has already terminated, which results in
wait_process looping waiting for the child which has already terminated.  The
symptom is a spurious "timeout waiting for filter command to exit".