New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

using mutt as a MUA does not work #77

anarcat opened this Issue Jan 21, 2019 · 3 comments


None yet
2 participants
Copy link

anarcat commented Jan 21, 2019

in #76 I mentioned that mutt never actually sends the email when sending a signature.

I believe this is due to a weird behavior of mutt: it "remembers" the "template" it sends into the text editor when drafting a new email. If that text is not modified, the email is simply dropped. To get to the "send dialog" in mutt, you actually need to somewhat modify the email.

But even worse, when you do get to that dialog, you notice the email is empty: it has only the introduction message, and no signature. It seems like the &attachment syntax is not supported by mutt. Here's what the interface looks like before sending the email:

y:Envoyer  q:Abandonner  t:À  c:CC  s:Obj  a:Attacher fichier  d:Description  ?:
       De : Antoine Beaupre <>
        À :
       Cc : 
      Cci : 
    Objet : Your signed key C4BC2DDB38CCE96485EBE9C2F20691179038E5C6
Réponse à : 
      Fcc : =.Sent
      Mix : <no chain defined>
 Sécurité : Signer (PGP/MIME)
Signer avec : <défaut>
-- Attachements
- I     1 /tmp/mutt-curie-1000-29180-3863593641275[text/plain, 7bit, us-ascii, 0

-- Mutt: Compose  [Approx. msg size: 0,2K   Atts: 1]----------------------------

There should be more attachments there.

A workaround for this is to allow the user to modify which program gets called by gnome-keysign when actually sending the email. That is how Monkeysign does it, see those instructions for an idea:



This comment has been minimized.

Copy link

muelli commented Jan 21, 2019

interesting suggestion.
Being primarily a desktop application, we attempt to use the email portal ( If that fails, we fall back to the older standard mechanism, xdg-email. If that's somehow not available, we simply open a mailto: URI and hope for the MUA to be registered as a handler for that scheme. Cf.

def send_email(to, subject=None, body=None, files=None):

I'm mildly against catering for each and every MUA and would rather see the MUA to be integrated better with the user's profile through the available mechanisms. Have you tried one of these for mutt?


This comment has been minimized.

Copy link

anarcat commented Jan 21, 2019

Honestly, I don't quite know how that works. :) The only reason why mutt is my default MUA is because my normal MUA (notmuch) doesn't even have such a commandline interface, so I'm a little far out from your normal use case.

This is how monkeysign does it:

I think what might be going on here is the portal "succeeds" in that it calls mutt, but then mutt fails to parse that &attachment URL... Or maybe xdg-mail fails and it fallsback to that mailto: url?

I don't know - I just figured it'd be useful for you to know this doesn't quite work with mutt, considering how popular that email client is among hackers. ;)


This comment has been minimized.

Copy link

muelli commented Feb 14, 2019

I also don't exactly know how it works, but for the portal, I could imagine something providing a mutt-backed email function. The signature of the DBus service is relatively simple:

For xdg-email to work, I suggest patching xdg-email or filing a bug:

For the protocol handler, you can file a bug against your distribution or mutt directly, to provide a .desktop file with something like MimeType=x-scheme-handler/mailto;. Some distributions do that, e.g. SuSE:

You seem to be able to do it yourself, as discussed here:

Does that make it work for you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment