Solution: manually pipe your command's output to sendmail. Before that,
use shell's redirection to attach /dev/null as the default stdin/stdout.
Sam, that's a workaround, a method to avoid the problem. make sure there
is no output from the job because courier sendmail will not send it. if
you want something done with job output, do it in the job.
Gordon suggests the solution to the problem involves courier not making
assumptions about fd disposition.
as for your suggestion of using exec to point fds to /dev/null, i don't
get it. if you know how to effect atd's fd's at the time it forks
sendmail, enlighten. anything you do to a job shell's fd's only effect
that job shell and ends when the shell exits. i'm sure you know this so
i can't understand why you keep saying that, unless you mean to say
replace sendmail with a wrapper that fixes up the fd's before calling
the real sendmail. well that would be what Gordon is getting at, that
courier sendmail should sanitize its environment better. or we could fix
atd to be more gentle with courier sendmail.
courier sendmail fails _SILENTLY_ when its fd's are not properly manicured.
What do the sendmail wrappers provided by other MTAs do?
If they work, and courier's doesn't, regardless of the root of the
problem, it's something that should work but doesn't, and IMO that makes
it courier's problem to deal with.
Democracy is two wolves and a sheep voting on what to have for dinner.
Liberty is two wolves attempting to have a sheep for dinner and
finding a well-informed, well-armed sheep.
Jon Nelson <jnel...@jamponi.net>
C and Python Code Gardener