Sending mail succeeded but signaled failure

Sending mail succeeded but signaled failure

[Justus Winter]

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.

Best,
Justus

Sending mail succeeded but signaled failure

[Justus Winter]

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.

Best,
Justus

Re: Sending mail succeeded but signaled failure

[David Bremner]

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.

d

Re: Sending mail succeeded but signaled failure

[Dan Čermák]

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

Re: Sending mail succeeded but signaled failure

[Justus Winter]

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

Re: Sending mail succeeded but signaled failure

[Justus Winter]

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.

Best,
Justus

Re: Sending mail succeeded but signaled failure

[Dan Čermák]

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

Re: Sending mail succeeded but signaled failure

[Justus Winter]

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