* bug#56855: 27.1; sendmail-send-it considers it an error if sendmail wrote to stdout/stderr
@ 2022-07-31 13:08 Justus Winter
2022-08-01 20:46 ` Matt Armstrong
0 siblings, 1 reply; 4+ messages in thread
From: Justus Winter @ 2022-07-31 13:08 UTC (permalink / raw)
To: 56855
sendmail-send-it considers it an error if sendmail wrote to
stdout/stderr, despite the fact that the process returned success.
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.
I wrote to the notmuch mailing list before investigating further, and at
least one other person hat a similar problem. The thread is here:
https://nmbug.notmuchmail.org/nmweb/show/87k080jgx8.fsf%40thinkbox
I dug into emacs, and discovered that indeed sendmail-send-it considers
any output from the sendmail process to be an indication of an error,
even if the process returned 0. 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.
Best,
Justus
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#56855: 27.1; sendmail-send-it considers it an error if sendmail wrote to stdout/stderr
2022-07-31 13:08 bug#56855: 27.1; sendmail-send-it considers it an error if sendmail wrote to stdout/stderr Justus Winter
@ 2022-08-01 20:46 ` Matt Armstrong
2022-08-02 5:59 ` Justus Winter
0 siblings, 1 reply; 4+ messages in thread
From: Matt Armstrong @ 2022-08-01 20:46 UTC (permalink / raw)
To: Justus Winter, 56855
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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#56855: 27.1; sendmail-send-it considers it an error if sendmail wrote to stdout/stderr
2022-08-01 20:46 ` Matt Armstrong
@ 2022-08-02 5:59 ` Justus Winter
2022-08-02 10:44 ` Lars Ingebrigtsen
0 siblings, 1 reply; 4+ messages in thread
From: Justus Winter @ 2022-08-02 5:59 UTC (permalink / raw)
To: Matt Armstrong, 56855
Matt Armstrong <matt@rfc20.org> writes:
> 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 man cron(8) I see:
When executing commands, any output is mailed to the owner of the
crontab (or to the user named in the MAILTO environment variable in the
crontab, if such exists) from the owner of the crontab (or from the
email address given in the MAILFROM environment variable in the
crontab, if such exists).
Note how it says nothing about considering it an error. In fact, I did
an experiment on my cron implementation (ISC cron 3.0pl1-149 as packaged
by Debian), and it did send me any output written to stdout or stderr
regardless of the exit status, and it did *not* notify me of a failing
command if no output was written. Clearly, sending mails is orthogonal
to the exit status as far as cron is concerned.
> 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.
I don't read the snippet you quoted as promising to never send text to
stderr if the process succeeds. Now, I don't know which version of the
manpage you consider authoritative, but I found
e.g. https://linux.die.net/man/8/sendmail.sendmail which does contain
your snippet, and then clearly states:
Sendmail returns an exit status describing what it did. The codes
are defined in <sysexits.h>:
EX_OK
Successful completion on all addresses.
And:
% grep EX_OK /usr/include/sysexits.h
#define EX_OK 0 /* successful termination */
> On this we do have roughly 35 years of historical precedent, since the
> original Sendmail began in the mid-80s. :-)
Well, happily, we're also 35 years wiser than to trust the original
sendmail with anything.
> 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 don't understand that argument. I agree that seeing the output is
beneficial, but then you say that it is easy to suppress that output,
the same output that seeing you deemed beneficial just a few lines
earlier.
In fact, I think we should ask what the best thing is for the user. I
think that (a) emacs should correctly indicate whether sending the mail
succeeded or not, and (b) any warnings should be presented to the user.
Currently, emacs fails at (a) and your workaround violates (b).
>> 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?
Yes I can, but the question is: should I have to?
Best,
Justus
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#56855: 27.1; sendmail-send-it considers it an error if sendmail wrote to stdout/stderr
2022-08-02 5:59 ` Justus Winter
@ 2022-08-02 10:44 ` Lars Ingebrigtsen
0 siblings, 0 replies; 4+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-02 10:44 UTC (permalink / raw)
To: Justus Winter; +Cc: Matt Armstrong, 56855
Justus Winter <justus@sequoia-pgp.org> writes:
> In fact, I think we should ask what the best thing is for the user. I
> think that (a) emacs should correctly indicate whether sending the mail
> succeeded or not, and (b) any warnings should be presented to the user.
Your argument makes sense, but there's a lot of systems out there, and
there's a lot of different things people use in place of
`sendmail-program'. Emacs' contract with the user here has been (for 35
years) to consider any output from these programs as an error condition,
and changing that will inevitably lead to people losing mail, because
they're using that contract.
As a practical matter, accepting a SUCCESS exit code as a success, but
then showing the extra text isn't much friendlier than signalling an
error -- users don't want to see warnings every time they send a mail,
so they'll have to fix whatever program they're using for
`sendmail-program'.
So I think the fix here is to just document that output is considered
failure, and I've now done this in Emacs 29, and is therefore closing
this bug report.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-08-02 10:44 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-07-31 13:08 bug#56855: 27.1; sendmail-send-it considers it an error if sendmail wrote to stdout/stderr Justus Winter
2022-08-01 20:46 ` Matt Armstrong
2022-08-02 5:59 ` Justus Winter
2022-08-02 10:44 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.