
Guide to email in Emacs using mu and mu4e - gjstein
http://cachestocaches.com/2017/3/complete-guide-email-emacs-using-mu-and-/
======
avar
Maybe I'm missing something obvious here, but calling "mu index" from the
offlineimap postsynchook is going to suck, because mu4e invokes "mu
server"[1], that aquires a Xapian lock on the index, which means you can't run
the "mu index" while reading your E-Mail.

This is the worst thing about mu/mu4e. You need to do the indexing with a
timer in Emacs, and because Emacs is single-threaded this blocks things /
slows down the UI. After trying to get it to work in some automated way I gave
up. I manually issue a key-combo to re-index and then read my E-Mail.

Another comment: I recommend not using Emacs to send E-Mail, but to outsource
this to a local smtpd such as Exim (which I use with mu4e on Debian). Then if
you don't have WiFi or whatever the smtpd just queues those up for later
sending, and has queue inspection tools etc. All of the solutions for doing
this in Emacs itself are dirty hacks full of edge cases and bugs smtpds have
solved decades ago.

Despite some rough edges, mu+mu4 (plus Exim, or similar). is an amazing tool,
and the most useful E-Mail client I've ever used.

1\. [https://www.djcbsoftware.nl/code/mu/mu4e/mu-
server.html](https://www.djcbsoftware.nl/code/mu/mu4e/mu-server.html)

~~~
arnoooooo
My mail fetching script kills mu before calling "mu index", like so :

$ pgrep mu && kill `pgrep mu`

$ mu index

It works perfectly. Mu4e then restarts mu when it needs it.

I think I saw that as the recommended setup somewhere in the mu docs.

~~~
tom4000
With `pkill $(pgrep mu)` or even with `pkill mu` you can kill mutt and any mu$
process as well.

`pkill -x mu` matches the whole name without substrings.

------
clircle
For anyone thinking about a setup like this: skip offlineimap and use mbsync
instead. It's much faster, and syncing (rather than indexing) mail is the main
speed bottleneck to reading email in emacs.

~~~
defanor
`doveadm sync` is also a nice option if the server supports it: combined with
a custom `sendmail` command, one can both send and receive/synchronize
messages over SSH, avoiding additional authentication.

------
djcb
mu/mu4e author here... please let me know if you have any specific questions.

~~~
philjackson
No questions. Just a "thanks" \- mu4e is great.

------
arohner
Is there any Emacs-based solution to access a GMail account with 2FA, without
enabling "insecure access" on Gmail?

I've looked at a lot of solutions, and AFAICT:

\- SMTP + app-based passwords require "insecure access" being enabled

-Using the GMail HTTP API does not require insecure access, but none of the standard CLI email tools support it.

~~~
geofft
Can you use XOAUTH2?
[https://developers.google.com/gmail/imap/xoauth2-protocol](https://developers.google.com/gmail/imap/xoauth2-protocol)

offlineimap supports it, and the config file has setup instructions:
[https://github.com/OfflineIMAP/offlineimap/blob/master/offli...](https://github.com/OfflineIMAP/offlineimap/blob/master/offlineimap.conf#L900)

------
autopoiesis
How does this compare to using notmuch-emacs? And can someone say whether
notmuch or mu is preferable these days?

~~~
nextos
I have extensively used both, and spent some time using Gnus too. Plus a lot
of time on Mutt.

In my opinion, Notmuch is better than Mu because it has a really neat
architecture that allows customizing it to embrace any possible email workflow
with a few trivial Bash commands.

Notmuch is purely tag based. It will never ever modify your mailbox. It's your
task to map tags to imperative mailbox actions (delete, move...) using some
shell hooks. Most workflows can be trivially implemented by calling the
notmuch backend and piping the output to mv or rm using xargs or parallel.

Since searching in Notmuch is really quick, I recommend never manually
assigning tags and tagging everything with rules written in the backend for
those repetitive searches that you want a shortcut for. This is not specific
to Notmuch, but also applies to Mu.

Mu has a hybrid tag/folder model, and the interface resembles Mutt in some
ways. The other key difference with Notmuch is that Mu stores tags using a
special header in each message. Notmuch uses a separate database, which is not
synced across computers (unless you rsync it explicitly). I prefer the latter
approach, as modifying your mailbox to store tags is a bit ugly and slow. I
also favor not tagging things manually, but using rules. Then syncing tags
becomes unnecessary.

~~~
BeetleB
Thanks for the comparison. I'm wondering what the benefits of mu4e are over
notmuch (your comment doesn't list any - which makes sense because you
preferred notmuch).

The reason I ask: When I look around, I tend to see a lot more references to
mu4e than to notmuch. Is it just easier to start with, or does it actually
have some nicer features that notmuch doesn't?

Not sure if it's relevant, but: I download all emails and do _not_ want to
sync with the server.

~~~
dima55
A case for mu: it is NOT tag-based, which is a feature: it can work with
normal IMAP, and thus other email clients that aren't mu can look at that
mailbox, and have all the data. Notmuch's tags do NOT live in IMAP (as far as
I know), so if your workflow relies on them, you get annoyed if you ever look
at your mailbox in any other way.

With mu, you just do the normal thing: instead of tagging a message as "x",
you put it in folder "x". Clearly this breaks down if you want to apply more
than one tag to a message, but this hasn't been an issue for me in the 20+
years I've been using email.

Before I read this, I had no idea that mu even did any tag-based anything.

~~~
nextos
That's not true. You can still have Notmuch to play well with other mail
clients. You simply need to work out a good mapping between tags and folders,
which is trivial.

IMAP only supports a few tags: read, unread... But not custom ones.

The only possible scenario where Mu is better than Notmuch is where you have
many many custom tags and you want them to be perfectly synced across Emacs
instances in different computers. Since Mu stores them in messages, this is
very easy. With Notmuch, you'll need to separately sync the database. E.g. by
rsyncing it.

But note that other clients won't understand these tags.

------
kkylin
I've been using mu4e for a while, and despite some rough edges (e.g., I have
the same dissatisfaction with timers and xapian lock that others have), I've
been pretty happy with the set-up. I did find that for working with gmail,
mbsync works more consistently than offlineimap.

------
Myrmornis
I found trying to do this sort of thing (e.g. gnus + dovecot) a very helpful
introduction to software engineering; once I got a job as a software engineer
I found I didn't have time for a local setup that needed so much attention.

~~~
pfortuny
It needs no attention once you set it up. And the first steup is a bunch of
copy-pastes and minor customization.

~~~
Myrmornis
No, I'm speaking from experience unfortunately! Things break, emacs changes,
your OS changes, you decide you need a more recent version of something in
order to get a certain feature or bug fix. You get a new laptop. Etc.

~~~
michaericalribo
I agree. I’ve learned immensely from using tools like mu and offlineimap,
writing utilities for a maildir, and it can be great fun...but I need direct
and unmediated access to email, I need it to ‘just work’ and let me copy-paste
html text and images and drag and drop attachments. I have to use email to get
other stuff done, I can’t spend time focusing on email itself.

------
dannyobrien
I guess exploring around with setups like this is part of the command-line-
and-lots-of-email-subculture's current zeitgest. I hadn't heard of mu as a CLI
tool before, though I knew that mu4e was one of the emacs mail-reading
options.

I'm currently playing around with mblaze, which is another command line mail-
reading toolkit
([https://github.com/chneukirchen/mblaze](https://github.com/chneukirchen/mblaze)
), and building some notmuch-friendly tools on top of that (
[https://github.com/dannyob/mblaze-much](https://github.com/dannyob/mblaze-
much) ). I'm not sure it's the right way forward, but it's proving to be a fun
experiment.

------
federicotdn
Not completely related, but I have a question regarding Emacs and email:

Is there a way to read/write emails on Emacs, without having any emails or
credentials stored locally as plaintext? I'm heavily prioritizing ease of
configuration and security over speed or other additional features.

~~~
aerique
I don't know if the others use it but Gnus can read credentials from an
.authinfo.gpg file.

[https://www.gnu.org/software/emacs/manual/html_node/auth/Gnu...](https://www.gnu.org/software/emacs/manual/html_node/auth/GnuPG-
and-EasyPG-Assistant-Configuration.html)

~~~
globuous
That's what I do actually:
[https://www.emacswiki.org/emacs/GnusAuthinfo](https://www.emacswiki.org/emacs/GnusAuthinfo)

When I set it up with gmail tough, I think you either need a 2fa token (which
requires 2fa on gmail) or tick "allow unsafe apps" in the admin panel,
otherwise you get rejected by gmail. I'm sorry I don't have much info, it's
already been a few months I've set it up. However, if anyone's struggling,
I'll be glad to help ;)

------
kashyapc
FWIW, here's an alternative setup to consider if you don't want everything to
do in Emacs (I use it daily for its wonderful Org-Mode):

* OfflineIMAP -- to download and synchronize local Maildir with remote IMAP.

* Mutt -- E-mail client (understatement).

* Notmuch -- for fast local indexing and querying.

* Postfix -- the wonderful mail transfer agent.

Here[1] are some config files (from my colleague, Paul Frields) that you can
adapt from.

Been using the above set up for about five years. They heavily help with the
high-traffic open source projects that use mailing lists for patches. (Even
for general mail setup, this is still useful).

These tools are a part of my day-to-day happiness at work.

[1]
[https://pfrields.fedorapeople.org/configs/](https://pfrields.fedorapeople.org/configs/)

------
jpeeler
If you're using notmuch and Gmail, I'd recommend taking a look at gmailieer -
[https://github.com/gauteh/gmailieer](https://github.com/gauteh/gmailieer). It
uses the Gmail API to fetch mail into a local maildir and keeps the tags
synced bidirectionally.

The downside is that for whatever reason the Gmail API doesn't support the
mute label, so having that tag sync is not possible. (If a Googler reads this,
please fix that! For others, there's already an issue filed as referenced in
the gmailieer readme.)

------
aidenn0
I'm really happy with my e-mail setup of offlineimap, afew, notmuch, bower.

[http://www.offlineimap.org/](http://www.offlineimap.org/)

[https://github.com/afewmail/afew](https://github.com/afewmail/afew)

[https://github.com/wangp/bower](https://github.com/wangp/bower)

------
another-cuppa
I used to use gnus and liked it. I don't think I can use this at work because
I need the exchange invitation crap which thunderbird thankfully supports. I
just can't be bothered to put significant effort into making that work. But I
think I should definitely look into this for home.

------
NesteaIsBad
I use Fastmail and the interface is so good that I can say this solution is
really crappy.

~~~
unhammer
I use Fastmail and think their web interface is great, but I still also love
having offline access to my mail[1], and being able to create an org-mode TODO
from an email with a link back to the message, and being able to hit a key to
open a new message while coding. Also, every day I get an email with some log
files from a service at work; because `mbsync` puts these in my Maildir, I can
run a script (using `ripmime`) to extract the logs (going all the way back in
time) and show me a report etc., which is so much faster than if I were to get
those attachments from a GUI.

[1] I'm still spooked from the time my Gmail account was suspended for no
apparent reason, having to contact support and being without email for nearly
a week.

