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 _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-leave@notmuchmail.org