From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 532356DE0924 for ; Sat, 26 Oct 2019 08:26:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.547 X-Spam-Level: X-Spam-Status: No, score=0.547 tagged_above=-999 required=5 tests=[AWL=-0.384, PLING_QUERY=0.279, SPF_NEUTRAL=0.652] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnwlFZpVU-rn for ; Sat, 26 Oct 2019 08:26:56 -0700 (PDT) X-Greylist: delayed 585 seconds by postgrey-1.36 at arlo; Sat, 26 Oct 2019 08:26:55 PDT Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) by arlo.cworth.org (Postfix) with ESMTP id CC8DA6DE0352 for ; Sat, 26 Oct 2019 08:26:55 -0700 (PDT) Received: from guru.guru-group.fi (localhost [IPv6:::1]) by guru.guru-group.fi (Postfix) with ESMTP id D792A100069 for ; Sat, 26 Oct 2019 18:17:04 +0300 (EEST) From: Tomi Ollila To: notmuch@notmuchmail.org Subject: Re: notmuch-mua-send + msmtp IS sending perfectly... but Emacs says it failed! Why?! In-Reply-To: References: User-Agent: Notmuch/0.28.3+84~g41389bb (https://notmuchmail.org) Emacs/25.2.1 (x86_64-unknown-linux-gnu) X-Face: HhBM'cA~ MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2019 15:26:57 -0000 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@foo.com"; gpg: Good signature from "Aren Tyr (Key for encrypting mail > password files) " [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.