bug#56855: 27.1; sendmail-send-it considers it an error if sendmail wrote to stdout/stderr

[Matt Armstrong <matt@rfc20.org>]

Justus Winter <justus@sequoia-pgp.org> writes:

> sendmail-send-it considers it an error if sendmail wrote to
> stdout/stderr, despite the fact that the process returned success.

[...]

> I read documentation of various sendmail implementations, and all
> agreed that returning success meant that the operation succeeded.  I
> found no justification for emacs thinking that the operation failed if
> the process printed to stdout or stderr.

This is perhaps surprising.  It is also behavior that has come to be
expected, especially in more traditional Unix programs.  E.g. crontab
also considers jobs that print to stderr to have an error, regardless of
exit status.

From the sendmail(8) manpage we have this statement:

    Sendmail is not intended as a user interface routine; other programs
    provide user-friendly front ends; sendmail is used only to deliver
    pre-formatted messages.

An implementation of the "sendmail program" should probably emulate the
original sendmail as closely as possible.  It prints no messages when it
succeeds.

On this we do have roughly 35 years of historical precedent, since the
original Sendmail began in the mid-80s.  :-)

This may seem like a historical wart, but I have personally found this
behavior to be helpful, especially in programs that are typically run
non-interactively and "out of sight" like a crontab or sendmail wrapper
script.  E.g. when a shell script prints to stderr there may indeed have
been a problem, but a bug in the script may still have caused it to exit
with zero regardless.  It is usually easy to arange for such programs to
print nothing when they succeed.


> I use msmtp with the authentication password encrypted using OpenPGP.
> Then, I use 'gpg --no-tty -q -d ...' as msmtp's passwordeval function.
> Now, my OpenPGP key has expired, but that doesn't stop GnuPG from
> decrypting the secret, and in fact it returns the status code 0.  It
> also prints
>
>   gpg: Note: secret key 08CC70F8D8CC765A expired at Mon 25 Jul 2022 05:31:26 PM CEST
>
> to stderr, which is picked up by emacs, it says
>
>   sending...failed to gpg: Note: secret key 08CC70F8D8CC765A expired at Mon 25 Jul 2022 05:31:26 PM CEST
>
> in the status buffer while the compose buffer stays open.  Note that
> despite this, the message has been sent successfully, while emacs
> indicates that the sending has failed.

Can you configure your msmtp to behave like sendmail and refrain from
printing human readable messages upon success?  Perhaps the --logger-fd
or --logger-file arguments to gpg could be used to direct the output you
do not wish to read to /dev/null?