<div dir="ltr"><div>Hello all</div><div><br></div><div>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.</div><div><br></div><div>Every time I send a message (via notmuch-mua-send) from within Emacs, the message apparently 'fails', and I get this error message:<br></div><div><br></div><div>------------------------------</div><div><br></div><div>Mark set [5 times]</div>Sending...<br>Mark set [2 times]<br>Sending via mail...<br><div>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 "<a href="mailto:foo@foo.com">foo@foo.com</a>"; gpg: Good signature from "Aren Tyr (Key for encrypting mail password files) <<a href="mailto:foo@foo.com">foo@foo.com</a>>" [ultimate]; <br></div><div><br></div><div>--------------------------------</div><div><br></div><div><br></div><div>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.<br></div><div><br></div><div>It is Emacs that is thinking it has failed, for whatever reason.</div><div><br></div><div>I've tried twiddling with every variable I can think of in Emacs to no avail. Here are my relevant emacs settings:<br></div><div><br></div><div>(setq mail-specify-envelope-from 't)<br>(setq message-sendmail-envelope-from 'header)<br>(setq mail-envelope-from 'header)</div><div><br></div><div>My notmuch-config database path is set to:</div><div><br></div><div>path=/home/aren/.mail</div><div><br></div><div>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...</div><div><br></div><div><br></div><div>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. <br></div><div><br></div><div>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<br></div><div><br></div><div>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!<br></div><div><br></div><div>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.</div><div><br></div><div>Thanks!</div><div><br></div><div>Aren.<br></div></div>