notmuch-mua-send + msmtp IS sending perfectly... but Emacs says it failed! Why?!
tomi.ollila at iki.fi
Sat Oct 26 08:17:04 PDT 2019
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]
> 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:
> 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
> 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
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...
More information about the notmuch