notmuch-mua-send + msmtp IS sending perfectly... but Emacs says it failed! Why?!

[Tomi Ollila]

On Fri, Oct 25 2019, Aren Tyr wrote:

> Hello all
>
> I have setup mbsync to receive my e-mail, msmtp to send my mail, and use
> notmuch + emacs to read/compose my mail. I have the msmtp-mta package also
> installed, so that msmtp acts as a sendmail replacement. I have a bizarre
> problem, however, which despite my searching I cannot find an answer to.
>
> Every time I send a message (via notmuch-mua-send) from within Emacs, the
> message apparently 'fails', and I get this error message:
>
> ------------------------------
>
> Mark set [5 times]
> Sending...
> Mark set [2 times]
> Sending via mail...
> message-send-mail-with-sendmail: Sending...failed to gpg: Signature made
> Wed 09 Oct 2019 12:50:15 BST; gpg:                using RSA key
> C58AF6323354659D571F1DCA4AF54DEEDEA8938D; gpg:                issuer "
> foo at foo.com"; gpg: Good signature from "Aren Tyr (Key for encrypting mail
> password files) <foo at foo.com>" [ultimate];
>
> --------------------------------
>
>
> I say 'fails', because in fact it DOES SEND, and it sends perfectly! I've
> tested it with lots of e-mails, tested it with attachments, everything is
> sending and working as it should be.
>
> It is Emacs that is thinking it has failed, for whatever reason.
>
> I've tried twiddling with every variable I can think of in Emacs to no
> avail. Here are my relevant emacs settings:
>
> (setq mail-specify-envelope-from 't)
> (setq message-sendmail-envelope-from 'header)
> (setq mail-envelope-from 'header)

What are the values of send-mail-function and message-send-mail-function...

If something like `message-smtpmail-send-it` then you could tru

(setq smtpmail-debug-info t smtpmail-debug-verb t)

and see what appeears in some new log buffers...)

>
> My notmuch-config database path is set to:
>
> path=/home/aren/.mail
>
> I've set the emacs 'message-directory' variable to the same path, i.e.
> ~/.mail/. I've also tried manually creating 'sent' folders in the mail
> store, just in case this was an issue, to no avail. (When I compose mail,
> header has Fcc: sent ). notmuch-maildir-use-notmuch-insert is set to true.
> notmuch-fcc-dirs is set to "sent". So everything should be set...
>
>
> As a result, the buffer does not get closed/saved into the relevant sent
> file, and it stays open as an "unsent" buffer, even though the message has
> been sent fine. It is very irritating. To be clear, it is sending properly,
> so it is correctly decrypting the password via gpg, so I don't know why it
> is complaining and thinks there is a problem, when there isn't. Simply
> sending an e-mail on the command line via mstmp also works perfectly
> without any error, further verifying there is no configuration issue on the
> actual mail transport side of things.
>
> Any ideas? Why does emacs/notmuch think there is a problem sending, when
> there isn't? What setting do I need to put into emacs to get it to shut-up
> and accept that the mail has actually been sent, because it has in fact
> been? :-D
>
> In all other respects the mail setup is working perfectly, and I can
> browse/search/read/view my e-mail just fine. It's a terrific program, thank
> you!
>
> Well almost. One other slight nuisance. Whenever I close a message search
> buffer, or a message reading buffer, instead of returning me to the
> *notmuch hello* main buffer, it ALWAYS sends me to another buffer, usually
> *scratch*. Never *notmuch hello*. It doesn't seem to matter what 'order'
> the buffer is. I was expecting that after having started notmuch (M-x
> notmuch), which brings up notmuch-hello, then immediately going into my
> inbox (which opens a new buffer), opening an email (another new buffer),
> closing it by pressing 'q', that I'd be returned back to my search list
> since that is the immediately prior buffer. But no. It doesn't even return
> me to notmuch-hello, which is the next one down. Instead it returns me to
> another buffer, or *scratch*, or whatever. This is werid. It is like it is
> ignoring the buffer list order. It means I have to manually switch buffers
> back to the search list (or notmuch-hello). Emacs/notmuch seems to be
> ignoring the buffer stack order, which is presumably not the intended
> default operation. I don't understand enough about Emacs to know which
> setting to tweak this. This is a minor distraction though, compared to the
> sending issue I have described above.

I used to have similar problem, and already wrote some elisp code to "fix"
that (i.e. find suitable "parent" buffer and then switch there). Then I
realized (i think someone(tm) commented on my suggestion) that there were
problem in my emacs configuration -- and after I fixed that the buffer
switching when closing search buffer worked basically as expected...
i.e. when closing message buffer (and I have not one any other buffer
manipulation) I ended back to search buffer, and from there back to hello
buffer. 

If you have notmuch source code around you could try to run
`devel/try-emacs-mua` and see whether you get different behavior when
`-q` or `-Q` were used when running emags...

Tomi
  

>
> Thanks!
>
> Aren.