send email using the default email client instead of our own

another improvement from the geysigning project is the ability to send email using the user's regular email client. to quote their README again:

In contrast to monkeysign, xdg-email is used to pop up a pre-filled email composer windows of the mail client the user has configured to use. This greatly reduces complexity as no SMTP configuration needs to be obtained and gives the user a well known interface.

This seems like a low effort, high benefit feature that we could implement easily.

mentioned in issue #8 (closed)

in fact, we already have the --mta flag now, i guess it's just a matter of making it grok it correctly.

i am curious to see how geysigning does it, because xdg-email assumes you give it the body on the commandline, with the --body flag, which will probably fail for long emails, as we will go over the commandline limit.

what do people think of a separate --mua flag that would expand %(body)s and %(subject) and so on?

this is how geysigning sends the email:

https://github.com/muelli/geysigning/blob/d1c657e62b14688ba63b4c81c1985df980335aaf/keysign/GetKeySection.py#L623 https://github.com/muelli/geysigning/blob/d1c657e62b14688ba63b4c81c1985df980335aaf/keysign/GetKeySection.py#L562

notice how the body is in cleartext, and the key is simply an attachment. i like that.

Milestone changed to %Monkeysign 2.1.0

Added Development label

we have discussed this in the #monkeysphereIRC channel on oftc, and here's a summary.

one of the key issues here is how we encapsulate MIME. if we simply encrypt the signed data with GPG and shove that in an attachment, the MUA won't know how to import that key automatically, and it will require assistance from the user to import the key correctly.

in other words, this doesn't work:

$ LANG=C gpg --export --export-options export-minimal -a  anarcat@debian.org | gpg -r anarcat@debian.org -a -e | gpg --import
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

this works, but i don't expect MUA (or users, for that matter) to have such a clue:

$ LANG=C gpg --export --export-options export-minimal -a  anarcat@debian.org | gpg -r anarcat@debian.org -a -e | gpg | gpg --import

You need a passphrase to unlock the secret key for
[...]

so one idea would be to make a encrypted attachment (instead of having the whole message encrypted). according to rfc3156 section 4, this is done by having a multipart/encrypted message with two application/pgp-encrypted parts.

the problem is that xdg-email doesn't actually support that: you can't specify a mimetype, just an attachment. then each MUA decides how it decodes the file. Mutt uses /etc/mime.types to figure out what Content-type to assign, and while we can use the .pgp to make Mutt believe that the attachment is encrypted stuff, it doesn't actually work: the content mysteriously gets replaced by the string Version: 1 and the attachment is lost. there's no extension set multipart/encrypted. and even if there would, thunderbird and other MUAs are unlikely to work the same way...

so the only way to use xdg-email is to have a plain-text attachment. .asc extensions are a good compromise because they indicate some sort of cleartext encoding. that means that the burden is shifted on the recipient, which then needs to manually decrypt the message and then import it, in other words run the second pipeline above (ie. pipe the file through gpg | gpg --import). this could eventually also be improved in GPG itself.

but I believe the tradeoff is worth it: we make it easier to send the email, and assume the other end is familiar enough with PGP to decapsulate the thing. it beats not being able to send email at all because the user doesn't remember their SMTP passwords (and rightly so).

there are two ways to implement this feature here:

1. improve the --mta command to support %(attachment)s, %(body)s and so on. it would need to pipe the message only if %(attachment)s is not present, however
2. make a distinct --mua command that supports %(attachment)s, %(body)s and so on

I am leaning towards the second option, as it would require less magic and would be easier to document for the user. It is also more logical: with --mta, monkeysign behaves as a MUA and talks to the specified MTA. with --mua, mutt just shoves bits and pieces into the given MUA and doesn't try to be a MUA itself.

of course, another solution would be to autodetect the user's SMTP configuration based on their email address. this has been thoroughly discussed in Debian #723072 and remains a good objective. it does mean we grow the MUA code in Monkeysign itself, but it seems unavoidable (people asked for it). that issue will still be tracked in the Debian BTS until imported separately here.

@dkg let me know if i missed anything here.

i still prefer Debian #723072 over the options discussed above (though i'd refer to it as the user's "submission configuration" these days and not "SMTP configuration").

Another option that should be included here if you want to follow the xdg-email route is to build a dedicated e-mail that is nothing but a single application/pgp-keys part wrapped in a multipart/encrypted section. This would then be added as an e-mail attachment of type message/rfc822 (which is usually mapped to the .eml extension).

This might permit a single attachment that is mime-decryptable on some popular MUAs in a way that the key could be directly imported based on its mime-type.

Reassigned to @anarcat

mentioned in commit 11ccede0

finally a first implementation in 11ccede0. i need to test this with thunderbird and mutt.

mentioned in commit 22e5c14a

it fails with xdg-email, which checks if the --attach argument is a file with test -f, so it just crashes the whole thing.

can't use FIFOs, will have to find another way to wait for thunderbird to do its thing.

i am now able to send email with mutt, but one key usability problem with it is that if the message is not modified, then mutt exits without sending the email (!). furthermore, gvfs-open, called by xdg-email, does not pass the attachment correctly to thunderbird, which then totally fails to send the key. whoohoo...

but at least it's possible to somewhat configure this correctly. in the dev/mua branch, i'll sleep on it before merging.

oh, and another bug: mutt transforms \n in \r\n when called from xdg-email. go figure.

related issues:

• using stdin in xdg-email: BTS #427728 (upstream) - wontfix
• using mboxes with xdg-email: BTS #427727 (upstream) - wontfix
• gvfs-open exits too early: BTS #677430 (upstream) - with patch, stalled since january 2015
• gvfs-open fails to attach email: BTS #837771
• xdg-email: check for iceweasel: BTS #788047 - fixed in stretch
• xdg-email fails to find icedove: BTS # 837790 - fixed in stretch

according to this, to change the default mailer with Gnome 3 is something like this:

xdg-mime default icedove.desktop x-scheme-handler/mailto

The current setting can be selected with:

xdg-mime query default x-scheme-handler/mailto

This doesn't seem to change xdg-email's behavior either, as it still fires up gvfs-open.

i have also tried this:

gconftool-2 --type string --set /desktop/gnome/url-handlers/mailto/command  "thunderbird %s"

... but it seems that doesn't do anything in GNOME3, so I reset it with:

gconftool-2 --unset /desktop/gnome/url-handlers/mailto/command

the default there is evolution %s, which you can see with:

gconftool-2 --get /desktop/gnome/url-handlers/mailto/command

our todos here:

• implement --mua flag
• port to argparse so that we can have --mua with a default, done, in the https://0xacab.org/monkeysphere/monkeysign/commits/dev/argparse branch
• talk to the mua with a fifo (xdg-email failed)
• talk to the mua with a tempfile, and prompt the user to wait before closing it
• document how to use this with thunderbird since xdg-email fails or at least document how to configure xdg-email - moved to #4 (closed)

note: there's a bug in the jessie version that doesn't find icedove, it'S fixed in stretch.

this was fixed in c4909e15. we'll fixup the documentation later, when #4 (closed) is complete.

Status changed to closed

mentioned in issue #4 (closed)

for the record, one should be able to send mail to thunderbird with:

monkeysign --mua "thunderbird -compose to=%(to)s,subject=%(subject)s,body=%(body)s,attachment=%(attach)s"

here's a patch to xdg-email in jessie that fixes icedove detection:

--- /home/anarcat/dist/xdg-utils-1.1.0~rc1+git20111210/scripts/xdg-email	2016-09-14 11:42:01.613671932 -0400
+++ /usr/bin/xdg-email	2016-09-14 08:39:02.284971109 -0400
@@ -587,8 +587,8 @@
     local client
     local desktop
     desktop=`xdg-mime query default "x-scheme-handler/mailto"`
-    client=`desktop_file_to_binary "$browser"`
-    echo $client | grep thunderbird > /dev/null 2>&1
+    client=`desktop_file_to_binary "$desktop"`
+    echo $client | egrep 'thunderbird|icedove' > /dev/null 2>&1
     if [ $? -eq 0 ] ; then
         run_thunderbird "$client" "$1"
     fi

that should probably be proposed as an update to jessie, or simply have xdg-utils backported. unfortunately, the debdiff between stretch and jessie is:

 92 files changed, 3829 insertions(+), 13845 deletions(-)

so that is quite unlikely.

Removed Development label