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

[Aren Tyr <aren.tyr@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3966 bytes --]

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@foo.com"; gpg: Good signature from "Aren Tyr (Key for encrypting mail
password files) <foo@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)

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.

Thanks!

Aren.

[-- Attachment #2: Type: text/html, Size: 4753 bytes --]