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?


Thanks,

Dan
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org