Re: Sending mail succeeded but signaled failure

["Dan Čermák" <dan.cermak@posteo.net>]

Hi Justus,

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 think this is msmtp's "fault". Afaik if msmtp receives something on
stderr for the passwordeval, then it considers that a failure, however
it will still take the password and send your mail.

I have run into exactly the same problem when gpg started to print
--8<---------------cut here---------------start------------->8---
gpg: all values passed to '--default-key' ignored
--8<---------------cut here---------------end--------------->8---
stderr and msmtp took that as failure. I have "fixed" that issue by
adding a
--8<---------------cut here---------------start------------->8---
2> /dev/null
--8<---------------cut here---------------end--------------->8---
at the end of each passwordeval in ~/.msmtprc.


Hope this helps,

Dan