* Sending mail succeeded but signaled failure
@ 2022-07-26 10:40 Justus Winter
2022-07-26 14:07 ` David Bremner
2022-07-26 17:18 ` Dan Čermák
0 siblings, 2 replies; 8+ messages in thread
From: Justus Winter @ 2022-07-26 10:40 UTC (permalink / raw)
To: notmuch
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Sending mail succeeded but signaled failure
2022-07-26 10:40 Sending mail succeeded but signaled failure Justus Winter
@ 2022-07-26 14:07 ` David Bremner
2022-07-30 21:06 ` Justus Winter
2022-07-26 17:18 ` Dan Čermák
1 sibling, 1 reply; 8+ messages in thread
From: David Bremner @ 2022-07-26 14:07 UTC (permalink / raw)
To: Justus Winter, notmuch
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Sending mail succeeded but signaled failure
2022-07-26 14:07 ` David Bremner
@ 2022-07-30 21:06 ` Justus Winter
2022-08-01 8:17 ` Dan Čermák
0 siblings, 1 reply; 8+ messages in thread
From: Justus Winter @ 2022-07-30 21:06 UTC (permalink / raw)
To: David Bremner, notmuch
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Sending mail succeeded but signaled failure
2022-07-30 21:06 ` Justus Winter
@ 2022-08-01 8:17 ` Dan Čermák
2022-08-01 9:21 ` Justus Winter
0 siblings, 1 reply; 8+ messages in thread
From: Dan Čermák @ 2022-08-01 8:17 UTC (permalink / raw)
To: Justus Winter; +Cc: notmuch
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Sending mail succeeded but signaled failure
2022-08-01 8:17 ` Dan Čermák
@ 2022-08-01 9:21 ` Justus Winter
0 siblings, 0 replies; 8+ messages in thread
From: Justus Winter @ 2022-08-01 9:21 UTC (permalink / raw)
To: Dan Čermák; +Cc: notmuch
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Sending mail succeeded but signaled failure
2022-07-26 10:40 Sending mail succeeded but signaled failure Justus Winter
2022-07-26 14:07 ` David Bremner
@ 2022-07-26 17:18 ` Dan Čermák
2022-07-30 14:53 ` Justus Winter
1 sibling, 1 reply; 8+ messages in thread
From: Dan Čermák @ 2022-07-26 17:18 UTC (permalink / raw)
To: Justus Winter; +Cc: notmuch
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Sending mail succeeded but signaled failure
2022-07-26 17:18 ` Dan Čermák
@ 2022-07-30 14:53 ` Justus Winter
0 siblings, 0 replies; 8+ messages in thread
From: Justus Winter @ 2022-07-30 14:53 UTC (permalink / raw)
To: Dan Čermák; +Cc: notmuch
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Sending mail succeeded but signaled failure
@ 2022-07-26 10:34 Justus Winter
0 siblings, 0 replies; 8+ messages in thread
From: Justus Winter @ 2022-07-26 10:34 UTC (permalink / raw)
To: notmuch
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-08-01 9:22 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-07-26 10:40 Sending mail succeeded but signaled failure Justus Winter
2022-07-26 14:07 ` David Bremner
2022-07-30 21:06 ` Justus Winter
2022-08-01 8:17 ` Dan Čermák
2022-08-01 9:21 ` Justus Winter
2022-07-26 17:18 ` Dan Čermák
2022-07-30 14:53 ` Justus Winter
-- strict thread matches above, loose matches on Subject: below --
2022-07-26 10:34 Justus Winter
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).