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 E9C0A6DE0ED0 for ; Tue, 29 Oct 2019 09:53:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 Hz33vD1nJsxJ for ; Tue, 29 Oct 2019 09:53:10 -0700 (PDT) Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by arlo.cworth.org (Postfix) with ESMTPS id D034E6DE0EDB for ; Tue, 29 Oct 2019 09:53:10 -0700 (PDT) Received: by mail-wm1-f45.google.com with SMTP id w9so3167979wmm.5 for ; Tue, 29 Oct 2019 09:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=T1R9NtAfi+XwM19HfOrlrzLDdHnbSTKbswlDsfTL8LU=; b=JlRWnFuKPyNsWZEhEB8L0breiJxoppRYXNh5ySB375hkpFXuL5ai8O0mnPZeAc1lPr B8uOnf7KmrJFoXgZa8uMAsbcsS9R5+mzdCI/mC+nwTpAtjcJhO8ycMxBkSocqXWl57fb 84IwcAjeMfGEK/VGlxvrCKDE6ulPoTRmPrZxEQgdp3JYQJTLYPQFH2JpZIMzNHwTSGmy +6Gf67WlaH5wyfcpBUXkS+LxxjqrbxRRx2eKVuf71kVZOHtj84ps/lZRzGvRUaLVr9Sc klzSxyGK4PWJipADvgD79LQrns3AlLlOYwxUfRNczHg8879G8Dp/MkMNrf+ox5d27gtS xGJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=T1R9NtAfi+XwM19HfOrlrzLDdHnbSTKbswlDsfTL8LU=; b=qCi2D/Y5WWElrvMtLbg5qcqP09ew8x6nBUGchIxtf8kQ6irOTyF41I+J/1zfo8EXLa JYID0QVPCYF9f0RP+SeuuSSJ+0OB6QyWj8h6oE44+ano6b3eFNgCtQaVm5eyHf38W/d+ knxDkhtfjumQaXabJFSuN63vVE1NLN9mlxipyqo8mf6ceRTm18TfP95+m+6vF4XiPuuY btfZlKRClzj8XwwsdfkONaVGg1LkHyZhL/6Ajgd92lkezz1GlzDWxSsZZpFy5trilFyV MEzsYAbCJnICXq/yQ2TpbHNtftIc7FqSXA5OUhfxkmwjC36nKoswPxHPBf9bTkpJJECE 4/iw== X-Gm-Message-State: APjAAAUoIjgttlmW9UJxu/yaVz9f0opHsQoN2DH2HpLsZMKOcMDIAirY 1LDZb95MCaeGygU60HD2myXaJe8= X-Google-Smtp-Source: APXvYqxGEBKkc83N4wOHPLkPggo8yW4NB2s1UWp3yXmG3jVvMY49mR7kHCv3E6NUxZwoTM5oiAonQw== X-Received: by 2002:a1c:558a:: with SMTP id j132mr822499wmb.21.1572367987793; Tue, 29 Oct 2019 09:53:07 -0700 (PDT) Received: from localhost (host109-152-6-19.range109-152.btcentralplus.com. [109.152.6.19]) by smtp.gmail.com with ESMTPSA id q6sm16745499wrx.30.2019.10.29.09.53.06 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 29 Oct 2019 09:53:07 -0700 (PDT) From: Aren Tyr To: notmuch@notmuchmail.org Subject: Re: notmuch emacs + msmtp sending issue fixed! :-) Date: Tue, 29 Oct 2019 16:53:03 +0000 Message-ID: <87lft3mr2o.fsf@emacs> 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: Tue, 29 Oct 2019 16:53:13 -0000 Hello First of all, thanks to both of you (Tomi & Tomas) for your help. I have finally solved the issue by my own self-investigation prompted by a suggestion on reddit that wasn't the correct cause, but did send me on what proved to be a successful path to a solution. The poster had suggested I needed to disable the msmtp logging to a logfile. This seemed like it wouldn't solve the issue as sending from the command line worked fine for me with a 0 exit status. Still, I was willing to give it a try. I tried it, and as expected, it made no difference... However, running it from the command line did highlight that I was always getting some informational output to the console from gpg. I wondered whether suppressing this might make a difference; perhaps it was interfering with the return value to notmuch/emacs. What was interesting was that gpg was spitting output to stderr, even though the output was *not* error, as such; it was just informational output saying successful decryption, etc. Even stranger, it was doing this despite having the -q (i.e. quiet) flag. Adding the --no-verbose flag still wouldn't shut it up. OK, so how about simply chucking this output away? After all, it wasn't actually saying anything relevant or useful.So, in my msmtprc file, I changed the passwordeval line to the following: passwordeval gpg2 --no-tty -q -d ~/.mail/passwords/gmail-main.gpg 2> /dev/null And tried to send an e-mail from notmuch.... SUCCESS! In fact, for the first time, it actually brought up a prompt asking me whether I wanted to (c)reate the necessary folder, which made sense. I went ahead and created it. So it turns out: a) My emacs config was fine b) Notmuch was fine c) gpg was chucking a load of informational output that notmuch/emacs was interpreting as a non-zero exit code d) worse, this output was causing the prompt to disappear to create the new folder I did further trials and tests and confirmed that the logfile option in msmptp is fine. So the solution was simply to add 2> /dev/null on the end of the passwordeval line to keep gpg quiet. This line needs to be there, even with the necessary directory structure in place (the 'cur', 'new', and 'tmp' folders under 'sent'), because it still thinks the message hasn't been sent if isn't there. It is good to have it there anyway, since I don't want the output of gpg anyway. It should be pretty obvious if I mess-up entering the password. > 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...) > Tomi > I /think/ that's all I have about the sending of mails and it works > fine. (plus the msmtp configs of course). > > Best regards > -- > Tomas Thanks once more. > 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... Yes, I still have this slight buffer order nuisance. I'll look into it further and resolve it. I've got a fair bit going on in my spacemacs setup, with a fair few layers and configuration options etc. Regards Aren. PS. This e-mail has been sent with my now fully working notmuch ;-)