A Unix-style mail setup (2012) | Hacker News Reader

A Unix-style mail setup (2012)

dev.gentoo.org

82 pointsHerrMonnezza36 comments

I used to have a "homely mutt"[1] kind of setup but eventually got tired of offline imap, msmtp, and all that.

Now I use mutt only directly on the server running exim. Painless support for multiple domains, completely arbitrary from addresses with no configuration necessary, no imap, no magic directories showing up for no reason, no weird certificates, just pure ssh... It's the way to do it.

Otherwise, I stick to generic clients (Google webmail and Android app).

[1] http://stevelosh.com/blog/2012/10/the-homely-mutt/

But that kind of solution works only if you are self-hosting, or anyway have access to the server, doesn't it?

how exactly does your setup works when offline ?

what if you do understand the internet and stay away from centralized third party solutions and rather self-host your email because it is too sensitive to give away to giant corporations ?

I don't really understand this comment. You can host exim+mutt anywhere. With a megacorp, in the cloud, even under your bed... The only problem you face is getting the giants to accept your mail so you will probably want another server acting as a smarthost if you host at home.

I also don't remember being involuntarily offline in the last four years so I don't optimize for it any more. Plus, it's email. It will be there when I get to it. You can incur hours of downtime and other servers will just dutifully keep trying to deliver messages. It's a pretty laid back service.

Well-configured other servers will just dutifully keep trying to deliver messages. There are plenty of less well configured servers out there.

For instance, I have greylisting configured on my primary SMTP server, but no greylisting on my secondary (because it's run by a friend, not me). Some servers will contact mine, offer a message, get told "try again", and just not bother, even though they could try the secondary and get through straight away. Other servers will give up after failing to deliver for 30 minutes.

"completely arbitrary from addresses with no configuration necessary"

That is the main reason I still use mutt. I like to be able to edit my from header when sending messages without having to pre-create virtual identities and then pick from a list. I asked for this functionality to be added to Evolution but apparently my use case wasn't common enough.

I have used the same setup for the past five-ten years. I have IMAP setup for when I want to travel, but I find console access to mail just simpler.

Though I migrated from mutt to lumail[0] (which I wrote) as I find the ability to script operations in Lua very useful.

0 - http://lumail.org/

FYI: You might have DDOS'd yourself here - the site is loading for minutes so far (but no timeout yet).

I'm interested and will check back later :)

Oops bad timing there - the server is in the process of being physically relocated (moving data centers via a van).

Mutt has had excellent built-in SMTP/IMAP/POP3 support for years. I'm always surprised to see guides suggesting helpers like msmtp, offlineimap, etc. And with a few macros and save-hooks that you'll only write once, you'll have a fast, flexible mail client that will beat nearly any GUI client in mail processing speed.

msmtp supports reading passwords from OS X's and Gnome's keychain programs. Also, having a separate program for that is very UNIX-way :)

I've got tired of IMAP too. Now I just sync my maildir using Syncthing (Pulse). I can use mutt both on the server and on my local machines, everything gets synchronized.

I use unison to synchronize maildirs between the machine that receives mail and the machines where I read it. It has worked quite well, especially for catching up on my mailing list backlog while on a plane.

Also worth mentioning is Karel Zak's mutt fork:

https://github.com/karelzak/mutt-kz

It uses notmuch for mail indexing/tagging/searching and allows you to use notmuch searches as virtual folders.

seconded- especially now that notmuch-inject exists. When I first started playing with mutt-kz, I had some difficulty getting the flow through procmail into notmuch, but it's pretty painless now. I've been using it daily for 2-3 years and can't imagine working without it now.

notmuch-inject? I hadn't heard of this, and google is turning up nothing. Care to elaborate for a line or two?

Maybe gp means: http://notmuchmail.org/manpages/notmuch-insert-1/ ?

Sounds like it should work nicely with server side filtering/delivery?

Are there any projects trying to reduce the email-server complexity on linux?

Mailpile seem to be going in the right direction on the client side, but I have yet to find any self-contained MTA/IMAP solution. With self-contained I mean its configured in one location, doesn't use linux users and has easily extendable storage options.

Soverign provides a good basis for an email server setup. It describes itself as a "set of Ansible playbooks to build and maintain your own private cloud: email, calendar, contacts, file sync, IRC bouncer, VPN, and more."

https://github.com/al3x/sovereign

Hope so! Then I don't have to keep maintaining http://flurdy.com/docs/postfix/

But for now email servers are still hard. Not too difficult to set up, hard to maintain.

What about creating a docker image? I was just considering to do so for my postfix / dovcot setup. That way i can migrate the image when i want to....

I recently started using a VM built using Mailinabox, which was both painless and surprisingly excellent.

https://mailinabox.email

iRedMail is a integrated set of scripts to install and configure a full-featured email server setup using free software components: http://www.iredmail.org/

I've used it, and it's pretty great.

Is anyone here using GNUS as their daily email client? I used to use mutt back in the day, and I was kind of surprised that the author was using emacs with mutt rather than just using emacs.

That said, I got as far as getting emacs / gnus to sync a gmail account before realizing that I'd need to spend some serious time reading manuals and tweaking configuration before I'd be able to use it day to day.

I use gnus. On my desktop I run offlineimap+fastmail, on my laptop I just use fastmail directly.

Gnus is great for reading/posting to Gmane newsgroups, I would use it for that even if I switched to something else for reading email. For plain mail reading it actually could be a lot better. For example, support for seeing your own replies in a thread is a bit flaky (notmuch.el is better for that), and since Emacs is single-threaded, sending large attachments blocks it (perhaps I should use that relay trick from the article, but then it's not often I use email for sharing big files).

I used to run GNUS, I switched to mu4e over a year ago, and haven't looked back.

I'm looking at the webpage now. Sounds like it tries to resolve some of the thread locking issues. Not sure I'd use the orgmode -> rich text email feature, but that is pretty awesome. Anything in particular you find superior to GNUS or otherwise useful?

Well, the idea behind mu is to use searches to filter your email instead of using imap folders. Indexing does feel a little slow sometimes, but it is far better than writing procmail rules to filter email.

I could still run it. I have a .gnus file that works with my current accounts (all Gmail/Apps accounts).

The problem with Gnus is that nnimap is unbearably slow and quirky in its own ways, and nnmaildir, which you'd ideally use with something like offlineimap to make Gnus work on a local copy for speed, is such a weird non-standard one-off backend that it's really hard to sync back to the server.

At least that was true a couple of years ago when I last made a serious attempt to use it. I think the modern emacs mail approach is probably either notmuch.el or mu4e, whichever interface you prefer.

I use a setup very similar to this on OS X.

- After using offlineimap for years, I recently switched to mbsync/isync. It is way faster and has been much more stable.

- After a stint with sup (http://supmua.org), I'm now back to mutt. I really love sup's interface, but it was a little too flaky.

- I use a script called "mail" that starts a tmux session then launches mutt in it:

    #!/bin/sh
    tmux -2 new-session -d -s mail -n 'mutt' "export TERM=screen-256color; mutt"
    tmux select-window -t 1
    tmux attach-session -d -t mail

Then, in mutt I have the double-quote mapped to a macro that executes a shell command to split the tmux window and launch a read-only instance of mutt:

    macro index,pager \" "<enter-command> \
        unset wait_key<enter><shell-escape> \
        tmux split-window -h \"mutt -R\"<enter>" "open new mutt"

This is my way of having an "async compose" pane for writing emails. I had tried replacing the mutt EDITOR variable with a command that splits the window and launches vim, but there are a lot of annoyances with that approach. Launching another mutt is way easier, and it also allows for easily viewing two emails at once.

That said, there are a lot of nice tips in here that I'll incorporate into my setup. Thanks for posting!

Very nice. My biggest objection is to Mutt (which I agree sucks less than many options). It is not clear to me that "mail client" is one job - I find myself happiest with nmh.

Re address books and mutt. I recently integrated my Owncloud contacts into Mutt by following these instructions:

http://got-tty.org/archives/mutt-kontakte-aus-owncloud-nutze...

They're in German, but they're easy enough to follow even if you don't speak it (I don't). It works really well.

See also http://karra-asynk.appspot.com/ which syncs CardDAV (e.g. OwnCloud) with MS Outlook with Emacs BBDB with Google Contacts with MS Exchange

I've been considering switching to an IMAP/mutt email setting on the desktop.

But what is the best mobile / iOS client to use?

Which mobile client meets the desiderata he lists (fast, works offline, etc.)?

http://www.tldp.org/HOWTO/HOWTO-INDEX/

I really like mutt + isync (for painless imap syncing) + mu (for indexing and address completion)

Reply on news.ycombinator.com