Re: Sending mail succeeded but signaled failure

[Justus Winter <justus@sequoia-pgp.org>]

Dan Čermák <dan.cermak@posteo.net> writes:

> Justus Winter <justus@sequoia-pgp.org> writes:
>
>> David Bremner <david@tethera.net> writes:
>>
>>> Justus Winter <justus@sequoia-pgp.org> writes:
>>>
>>>> Hello,
>>>>
>>>> I just embarrassed myself a little by sending the same mail over and
>>>> over again.  The reason for that is that notmuch-emacs signaled failure,
>>>> i.e. it displayed an error message in the status buffer and didn't close
>>>> the compose buffer, yet it did in fact send the mail.
>>>>
>>>> I suspect that my configuration has to do with that and someone is
>>>> trying to be helpful.  So 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 notmuch-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.
>>>>
>>>> I suspect that this is not notmuch's fault, but I don't know where else
>>>> to turn to with this bug report.
>>>
>>> I guess the first step is to see if you can duplicate the problem with
>>> plain M-x message-mode. The mechanics of sending should be identical in
>>> notmuch-message-mode unless (surprise!) I misremember something.
>>
>> It does indeed happen with the plain message mode.  And I think I have
>> identified the code in emacs that turns any output, stdout and stderr,
>> into errors:
>>
>> % cat -n emacs/lisp/mail/sendmail.el
>> [...]
>>   1343			     (exit-value (apply #'call-process-region args)))
>>   1344			(cond ((or (null exit-value) (eq 0 exit-value)))
>>   1345			      ((numberp exit-value)
>>   1346	                       (setq error t)
>>   1347			       (error "Sending...failed with exit value %d" exit-value))
>>   1348			      ((stringp exit-value)
>>   1349	                       (setq error t)
>>   1350			       (error "Sending...terminated by signal: %s" exit-value))
>>   1351			      (t
>>   1352	                       (setq error t)
>>   1353			       (error "SENDMAIL-SEND-IT -- fall through: %S" exit-value))))
>>   1354		    (or fcc-was-found
>>   1355			(error "No recipients")))
>>   1356		  (if mail-interactive
>>   1357		      (with-current-buffer errbuf
>>   1358			(goto-char (point-min))
>>   1359			(while (re-search-forward "\n\n* *" nil t)
>>   1360			  (replace-match "; "))
>>   1361			(unless (zerop (buffer-size))
>>   1362	                  (setq error t)
>>   1363	                  (error "Sending...failed to %s"
>>   1364	                         (buffer-substring (point-min) (point-max)))))))
>>
>> Apparently, that behavior goes back to the initial checkin of that
>> file.  I refuse to believe that Dan and me are the only ones having
>> problems with that in 30 years... I'll report it upstream.
>
> Can you paste the upstream bug number here as well please?

Sure thing:  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56855

Best,
Justus\r