Re: Sending mail succeeded but signaled failure

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

Hi Dan :)

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

> 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.

Good lead, but I looked at msmtp, and it uses popen(3), so it doesn't
get to see what the invoked process writes to stderr.  Therefore, I
think emacs it at fault here.

> 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.

Indeed, that is also the workaround I arrived at!

Best,
Justus\r