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 E50EC6DE0178 for ; Fri, 25 Oct 2019 08:17:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 tagged_above=-999 required=5 tests=[AWL=-0.140, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PLING_QUERY=0.279, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 0Dn69Qqs8utM for ; Fri, 25 Oct 2019 08:17:22 -0700 (PDT) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by arlo.cworth.org (Postfix) with ESMTPS id 7FA536DE0177 for ; Fri, 25 Oct 2019 08:17:22 -0700 (PDT) Received: by mail-ed1-f41.google.com with SMTP id e12so2024081edr.4 for ; Fri, 25 Oct 2019 08:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=9sKRkNgD26TlD7WCx5Nc5sMav2sTTSgmlVDzoi/ud6M=; b=Rl02xa/E2HY9QFpfXZpL870wDqHvM7QeL6Qr2MCdsVm3uCnZFetg7rtZM+2gPZ6AeZ miqFdk61tZAeCXiFHdEIOvufYLT7eBc18wK7TIT7xh2JFeD9uUTmjKgzuHwAtdi0/UjG 0tLoggDcrfAetREUsarstBQZ8oTCYL0dA6aNwD45GafigbwL1QrRdmbog2A8LzKrNfdE tClqGdwvSkZTi8t/DLxfZtJ3WpwUtBdUckVii+bVaf8FPUkKO7hR5ST+Sg6jUeZ13LRU rQaZ7Kt7rBMtuCwvHpCbv0Mhel4I5yL9r+g9HtCRfejDO5N7XBuGLXmeAT41JPK++343 t+zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9sKRkNgD26TlD7WCx5Nc5sMav2sTTSgmlVDzoi/ud6M=; b=l+EQdppbnS6s3qHPWeA0LmD1FsmQY5kjcalMqu6fMoMJiQaCQe8PF6NFcEy3IRmTO4 VVS54+xyTSDd6xE3Zzn+3Owy8eO83PiN8/YyhrphHjefcJ4+nvauMcwFo/kiFMFDeNcB lQ5jlylHUdhTjwDvnwCiok0tAtXhVyVliCoy3HovqZq0oIpY2Y7wr4WPVNbgYMhOdw4D YnUVTJISok3WEKN9WxkoA87txWw28K0oBjmB2Fo4FfJ9ggvYFh4lzkLAtCqAgnYy5FsN Ng8PAbRXRmE2y+dX/VrBAC2s2fYsIIiQOGKe7s7PRX2xfPmp1S9kOUrI8oHaH2SFaQy1 37Tg== X-Gm-Message-State: APjAAAVcxoofmATyiAijW8RkEvZxyySSyBqJTSiUQQ602oSFc8T2kLhp bKz5M7VeZ4Y4i8gyn+RsLUJxeTu/Ynlu+XQBX5Dtn6M= X-Google-Smtp-Source: APXvYqxRSJe1dYjaKYEBBvLeSbG+2XG8DztMLccEIiX7KsgwjpgxcRo3rAbOUzOHp4uYHspKE4SZAHHD29jyt6zwLx8= X-Received: by 2002:a50:d7c9:: with SMTP id m9mr4583110edj.93.1572016640645; Fri, 25 Oct 2019 08:17:20 -0700 (PDT) MIME-Version: 1.0 From: Aren Tyr Date: Fri, 25 Oct 2019 16:17:09 +0100 Message-ID: Subject: notmuch-mua-send + msmtp IS sending perfectly... but Emacs says it failed! Why?! To: notmuch@notmuchmail.org Content-Type: multipart/alternative; boundary="0000000000007260270595bda536" 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: Fri, 25 Oct 2019 15:17:24 -0000 --0000000000007260270595bda536 Content-Type: text/plain; charset="UTF-8" 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) 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. --0000000000007260270595bda536 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all

I have setup mbsyn= c to receive my e-mail, msmtp to send my mail, and use notmuch + emacs to r= ead/compose my mail. I have the msmtp-mta package also installed, so that m= smtp acts as a sendmail replacement. I have a bizarre problem, however, whi= ch 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 m= ail...
message-send-mail-with-sendmail: Sending...failed to gpg: Si= gnature made Wed 09 Oct 2019 12:50:15 BST; gpg: =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0using RSA key C58AF6323354659D571F1DCA4AF54DEED= EA8938D; gpg: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0issuer= "foo@foo.com"; gpg: Good sign= ature 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.
<= div>
It is Emacs that is thinking it has failed, for whatever= reason.

I've tried twiddling with every varia= ble I can think of in Emacs to no avail. Here are my relevant emacs setting= s:

(setq mail-specify-envelope-from 't)(setq message-sendmail-envelope-from 'header)
(setq mail-envelope-f= rom 'header)

My notmuch-config database path i= s set to:

path=3D/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&= #39; 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 eve= rything should be set...


As a resul= t, 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 be= en sent fine. It is very irritating. To be clear, it is sending properly, s= o 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. Simp= ly sending an e-mail on the command line via mstmp also works perfectly wit= hout any error, further verifying there is no configuration issue on the ac= tual mail transport side of things.

Any ideas= ? Why does emacs/notmuch think there is a problem sending, when there isn&#= 39;t? What setting do I need to put into emacs to get it to shut-up and acc= ept that the mail has actually been sent, because it has in fact been? :-D<= br>

In all other respects the mail setup is workin= g 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 m= essage reading buffer, instead of returning me to the *notmuch hello* main = buffer, it ALWAYS sends me to another buffer, usually *scratch*. Never *not= much 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 pressin= g 'q', that I'd be returned back to my search list since that i= s the immediately prior buffer. But no. It doesn't even return me to no= tmuch-hello, which is the next one down. Instead it returns me to another b= uffer, 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 t= he search list (or notmuch-hello). Emacs/notmuch seems to be ignoring the b= uffer stack order, which is presumably not the intended default operation. = I don't understand enough about Emacs to know which setting to tweak th= is. This is a minor distraction though, compared to the sending issue I hav= e described above.

Thanks!

Aren.
--0000000000007260270595bda536--