On Thu, Nov 12, 2020 at 10:31:59AM +0100, Matthias Apitz wrote:
El día miércoles, noviembre 11, 2020 a las 02:34:57p. m. -0600, Derek
Martin escribió:
On Sat, Nov 07, 2020 at 01:06:00PM +0100, Matthias Apitz wrote:
> El día jueves, noviembre 05, 2020 a las 10:17:25a. m. -0800, Kevin
> J. McCarthy escribió:
> > As far as I know, that mode of operation isn't supported by Mutt. I'm
> > confused how it is working, to be honest. Mutt expects either $sendmail
> > or $smtp_url to be set, and it controls the sending itself.
>
> It *is* supported by mutt using the following trick: one of the arguments
> to mutt is:
>
> .... | mutt -d4 -e "set sendmail=\"cat --\"" ... | sendmail -t
Having to use a hack rather means that it is NOT supported--only that
doing arbitrary other unsupported things with hacks is supported. =8^)
You should not think of Mutt as supporting this--it does not.
This is not a hack. The Mutt variable $sendmail is meant to specify any
process as MTA. Mutt is piping its output into the specified UNIX proc
and adds as arguments mail address(es) which we ignore in our case,
because the mail addr is specified in the mail itself as To: header.
I can not see that using cat(1) as MTA and writing the message to
STDOUT is some kind of (illegal) hack.
that seems to be a common theme in your thinking. ;-)
just because something is possible and not explicitly forbidden doesn't
mean it's a good idea.
with this hack you have no error checking at all, and unexpected output
on stdout would mess up things totally.
i'm not even sure why you're abusing mutt like that. use mime-construct
or something else actually made for this kind of task.
I'm already debugging our own application server which starts the shell
script creating all this process chain with system("script") and I
*think* this has set SIGCHLD to SIG_IGN
there is no excuse whatsoever for spawning a child with suppressed
sigchld (same for *most* other signals, for that matter). if this is
indeed what is happening, you have your root cause right there (and my
assessment from the other mail was in fact incorrect).
(with good reasons,
nonsense.
because all the error handling should be done within "script" and not
by the application server, which has to serve Java written GUI
frontends).
that might be true, but is no excuse for ignoring errors that still come
through, and even more for actively interfering with the child's
execution environment.
