[HN Gopher] A Quick Guide to Mutt
       ___________________________________________________________________
        
       A Quick Guide to Mutt
        
       Author : cpp_frog
       Score  : 96 points
       Date   : 2023-02-06 12:10 UTC (10 hours ago)
        
 (HTM) web link (srobb.net)
 (TXT) w3m dump (srobb.net)
        
       | jrm4 wrote:
       | Anyone still successfully using this or similar in a hardcore
       | Microsoft Outlook environment? My university keeps making it
       | harder, last time it broke I essentially just gave up
       | temporarily, and I keep intending to try to fix it. Any
       | help/ideas/insight is appreciated.
        
         | [deleted]
        
         | rollcat wrote:
         | Never touched mutt, but I've been using Emacs+notmuch for email
         | for quite a long time (and you can use mutt+notmuch together,
         | unfortunately TFA doesn't even mention it - it's really good
         | when you have too much mail).
         | 
         | My daily workflow involved quite a lot of mail, both from real
         | people expecting a reply, and some automated reports. I've had
         | many notmuch auto-tagging rules, and some custom Emacs key
         | shortcuts to make tagging/sorting even more efficient. I think
         | I've accumulated around 100k messages during my 4 years there.
         | 
         | Around 2017, I moved on to a job in a smaller company, where
         | everyone was sitting in the same building. Ditched that setup,
         | and definitely not looking back ;)
        
           | aidenn0 wrote:
           | I use bower+notmuch; what's your emacs setup for using
           | notmuch? Everything I find for emacs seems to be built around
           | mu4e, and I don't want to recreate my tagging/moving/&c.
           | notmuch setup in mu4e.
        
         | pfortuny wrote:
         | You will probably need davmail to download the mail from
         | exchange before passing it on to offlineimap/whatever.
         | 
         | I had to do that with my uni's corporate outlook mail, a real
         | pain but it does work (although I use mu4e, not mutt, but have
         | used the latter also).
        
       | dsr_ wrote:
       | The key advantage to mutt is the limit/tag/pattern workflow.
       | Everything else is more or less the way other mail clients work.
       | 
       | A pattern is a mail-specialized regular expression. There are
       | shortcuts for the things that you are likely to be interested in:
       | From and Cc, To, Subject, Date, status flags. After a few uses of
       | each, they'll start to feel natural.
       | 
       | The limit/tag/pattern workflow goes like this. Start in a mailbox
       | view -- say, your overloaded Inbox. Use a limit pattern to see
       | just a subset of the mailbox -- l ~fjira to limit to messages
       | from a sender with jira in their name or address. Use T to tag a
       | pattern -- by default the one you just used. Then prefix any
       | command with ; to make it apply to all the tagged messages. That
       | isn't just deleting them or moving them off to a different
       | mailbox. You can forward them all as attachments, or respond to
       | them all as one message, feed them to a command line process or
       | give them a new status flag. You can also tag and untag messages
       | one at a time, if you need fine control but don't want to figure
       | out a narrowed pattern. Then, untag anything left and unlimit
       | back to the full mailbox.
       | 
       | The key is that this happens much faster than you can possibly
       | make selections with a cursor in a GUI, and much faster than you
       | can make selections with a scrolling TUI. And patterns don't miss
       | something by accident.
       | 
       | One of my favorite limit patterns is "l~d<2d ~d>1d\n" which I
       | have aliased to ".y". It shows everything that came in yesterday.
       | You might be surprised how often this is the view that shows you
       | what you've missed. Another great one is "l~(!~fDOMAIN)\n" which
       | shows only threads that have outside mail addresses in them.
        
         | jjav wrote:
         | > Everything else is more or less the way other mail clients
         | work.
         | 
         | Agreed on the limit/tag/pattern benefits, but there's even more
         | to mutt. The greatest thing is how everything is configurable.
         | It works and behaves exactly how you want, for any conceivable
         | definition of want.
         | 
         | Most software these days takes the Apple approach of imposing
         | one single way of doing things and you will shut up and like
         | it. Which I hate. Mutt is the complete opposite, configure
         | everything to taste and enjoy.
        
       | lelag wrote:
       | A "Quick Guide" with at least 3 hours of reading material.
       | 
       | I'm scared to see the "Complete Guide to Mutt".
        
         | 3np wrote:
         | I guess what you want is "Mutt: The good parts"
        
       | ryan-duve wrote:
       | My professor used Mutt and I was always in awe every time I
       | watched him zip through emails. From time to time I try to get
       | into it, but always fail for a different reason.
       | 
       | This time, I made it about 30% of the way through this "quick
       | guide" with a Gmail account. I don't want to have my password in
       | plaintext, so I'm fine typing it in each time to get started, but
       | I never got over the finish line. I got stuck somewhere around
       | minimizing the number of system headers that go out with each
       | message.
       | 
       | Please let me know if anyone has recommendations for a CLI email
       | client that hooks up with Gmail on a modern Linux distro
       | relatively simply.
        
         | 3np wrote:
         | Aside from the already recommended aerc, here's a fairly
         | friendly and sane way to get started with neomutt:
         | https://github.com/LukeSmithxyz/mutt-wizard
         | 
         | In general I find that most people who have (or claim) a
         | productive workflow sync their mail locally (rather than
         | letting the client connect directly over IMAP). So decoupling
         | your reader application from your mail fetching application.
         | 
         | [mb/i]sync or offlineimap, with or without notmuch.
        
           | alxlaz wrote:
           | > In general I find that most people who have (or claim) a
           | productive workflow sync their mail locally (rather than
           | letting the client connect directly over IMAP). So decoupling
           | your reader application from your mail fetching application.
           | 
           | Can't speak for others but when I was using mutt this is
           | indeed what I was doing. It's just way, way easier, there are
           | no IMAP quirks to jump through and you get excellent offline
           | functionality pretty much for free.
        
         | rkta wrote:
         | > I got stuck somewhere around minimizing the number of system
         | headers that go out with each message.
         | 
         | What system headers are you trying to minimize?
        
         | pjc50 wrote:
         | > CLI email client that hooks up with Gmail
         | 
         | I'm not sure of the state of Gmail IMAP, but Mutt is "happiest"
         | when you've got a classical UNIX system with mail being
         | delivered locally. It's .. very old school. I suspect you could
         | get 80% of the zipping benefit by learning all the Gmail
         | keyboard commands (why is delete '#'? To avoid accidental
         | usage? Is there a keyboard command for "label as"?)
        
           | AndrewSwift wrote:
           | label as = L + first letters of label
        
         | epilys wrote:
         | I made my own mutt-like CLI client from scratch.
         | 
         | https://meli.delivery/
         | 
         | Webassembly demo: https://meli.delivery/wasm2.html
         | 
         | Git: https://git.meli.delivery/meli/meli
        
         | kenniskrag wrote:
         | I used aerc: https://aerc-mail.org/
        
           | anileated wrote:
           | Who is maintaining aerc's fork? I know Drew DeVault abandoned
           | the original version...
        
             | hdb2 wrote:
             | This is what I'm curious about - I remember seeing that DD
             | is no longer maintaining aerc...
        
             | lwhsiao wrote:
             | rjarry does :)
             | 
             | https://sr.ht/~rjarry/aerc/
        
         | throw_pm23 wrote:
         | PINE/ALPINE is also great and available on pretty much every
         | distro.
        
         | petemir wrote:
         | Currently using aerc. It could be better, but I can assure you
         | I tried several of them and this was the only one that stuck!
        
       | cosmojg wrote:
       | For fans of Mutt/NeoMutt looking to try something new, I've been
       | getting a lot of mileage out of Aerc[1] and can recommend it as a
       | somewhat more approachable alternative for the Mutt-curious.
       | 
       | [1] https://aerc-mail.org/
        
       | philonoist wrote:
       | Is there something awesom like this for Windows 11?
        
         | layer8 wrote:
         | You can install Cygwin and run Mutt on that.
        
       | wazoox wrote:
       | I've been using for about 20 years fetchmail, procmail and
       | spamassassin to locally deliver email, that I can then read
       | either with mutt (when I'm remotely connected, mostly) or claws-
       | mail. Frankly, nothing can beat that setup IMO :)
        
         | jjav wrote:
         | Same here, that is email in its natural habitat where it works
         | best.
        
       | topaz0 wrote:
       | Note that this guide appears to be quite old, although there are
       | updates as recently as 2022. E.g. there are _added_ notes about
       | issues that were fixed in Fedora 10, which came out in 2009. (not
       | that this should be considered as a negative -- it 's great that
       | this resource is still useful after so many years. Just pointing
       | out that this page appears to have a long history, and whatever
       | idiosyncrasies come with that history).
        
       | juped wrote:
       | Please note that if you are reading this, you almost certainly
       | want to skip everything before the "IMAP" heading.
        
       | euroderf wrote:
       | Can anyone point to a guide to using mutt with Protonmail ? I
       | guess it needs the Bridge. I wonder if mutt "e" (edit mail) works
       | with it.
        
         | surteen wrote:
         | David Petraeus, is that you?
        
         | BirAdam wrote:
         | You need the bridge, but after that mutt's standard IMAP
         | configuration is usable. The key is that when you set your imap
         | config you would do something like:
         | 
         | set folder="imaps://127.0.0.1:1143/"
         | 
         | and for SMTP you would do something like:
         | 
         | set smtp_url="smtps://username@127.0.0.1:1025/"
        
       | henry_flower wrote:
       | Heh, I started using Mutt only because of "peer pressure" during
       | my university years: all cool guys were using it! (Still with
       | Mutt, > 10 years later.)
       | 
       | I think this is somewhat akin to Emacs: startup costs are
       | enormous, but you reap the fruits for the rest of your life.
        
         | BirAdam wrote:
         | I am most certainly not an Emacs fan, but I have similar
         | thoughts about WordStar, Vim, and of course Mutt.
        
       | user3939382 wrote:
       | I went all-in on this https://stevelosh.com/blog/2012/10/the-
       | homely-mutt/ at some point but was eventually forced to give up
       | due to the problem of HTML emails. A lot of the emails I receive
       | are HTML-only, and the step of launching a browser tab to make
       | them legible was too big a PITA/slow. If I could find a tool kind
       | of like Firefox's "reader view" that could convert HTML emails by
       | default to something plaintext I'd be in business. Until then I'm
       | on horrendously slow Thunderbird, but at least the lag pain is
       | upfront launching the program and not per email.
        
         | layer8 wrote:
         | You can set up Mutt to display HTML mails with w3m or the like.
         | That works very well.
        
         | cbracken wrote:
         | I know someone mentioned Lynx, another option is to set up your
         | mailcap to view using w3m. For reference, see
         | .config/mutt/{muttrc,mailcap} here:
         | https://git.bracken.jp/dotfiles/files.html
        
         | surteen wrote:
         | Install lynx (or links or w3m). Add this to your ~/.muttrc:
         | 
         | auto_view text/html
         | 
         | alternative_order text/plain text/html
         | 
         | Add this to ~/.mailcap:
         | 
         | text/html; lynx -dump -localhost -force_html %s | sed 's/^
         | *//'; copiousoutput
        
           | user3939382 wrote:
           | Thanks! I'll give that a shot.
        
           | 5e92cb50239222b wrote:
           | Another option is piping email body into pandoc:
           | pandoc -f html -t plain
           | 
           | you have to try all three and see what works best. In my
           | experience, pandoc tries to reproduce the page faithfully
           | using ascii art, while lynx output is the easiest to read.
           | 
           | If you're going to use w3m, it's wise to wrap it with
           | socksify to prevent email spam from tracking you:
           | export SOCKS_SERVER="127.0.0.1:1"       exec socksify w3m
           | -dump
        
             | eqvinox wrote:
             | On Linux, you can also use "unshare" in your mailcap, e.g.
             | text/html; unshare -U -n lynx -assume_charset=%{charset}
             | -stdin -dump; copiousoutput;
             | 
             | This creates a new user namespace (-U) and then network
             | namespace (-n), meaning there is no way for the lynx
             | process to communicate with the outside world.
             | 
             | (requires unprivileged userns, which is default enabled on
             | recent distros. "sysctl -w
             | kernel.unprivileged_userns_clone=1" if not.)
        
       | incanus77 wrote:
       | I am shocked -- shocked -- to see the guide I wrote 22 years ago
       | on Mutt & GPG to be linked as relevant in this modern guide. I
       | don't use the combo anymore, but there is sometime affirming to
       | me about Mutt still being relevant after all this time. Good
       | tools that do a good job are still valuable.
        
         | jjav wrote:
         | > I am shocked -- shocked -- to see the guide I wrote 22 years
         | ago on Mutt & GPG to be linked as relevant in this modern
         | guide. I don't use the combo anymore, but there is sometime
         | affirming to me about Mutt still being relevant after all this
         | time. Good tools that do a good job are still valuable.
         | 
         | Yes! That should be the standard to aspire to with all
         | software. Not the constant change for the sake of change.
         | 
         | I set up a very highly customized (simplified) mutt setup for
         | my parents in 1996 and the exact same setup continues to work
         | today and my now-almost-100 year old parent continues to use
         | it.
         | 
         | Anyone who has tried to keep older people using software knows
         | the nightmare of UI changes. Even a small movement in the
         | placement of icons is a big hill to climb. Consistency is key.
         | My parent has given up on using the web because both the
         | browser and website UIs keep changing all the time, it becomes
         | too frustrating for them. So they gave up.
         | 
         | But thanks to mutt they continue to use email actively, nothing
         | has changed since 1996 when they memorized how to use it.
        
           | incanus77 wrote:
           | That's amazing, and great perspective. I see with my own
           | parents (one of them more so) how difficult they find UI
           | changes. For a lot of people, it's not just finding the same-
           | or similarly-named button, but spatial placement and
           | appearance can also be important.
        
         | zwayhowder wrote:
         | I got as far as the assumption of POP3 for fetching mail and
         | stopped reading TBH. Here was me hoping for some cool new guide
         | about Mutt with Oauth or similar.
        
           | znpy wrote:
           | Well, the guide is from 1996...
        
           | 5e92cb50239222b wrote:
           | POP3 is still useful. I have many addresses for various needs
           | and don't need to store email on servers for almost all of
           | them (mostly because it costs money). There is at least one
           | IMAP client* that supports _fetching_ mail (not syncing like
           | most of them do), but POP3 has much wider selection of
           | clients and serves that need perfectly.
           | 
           | *: https://github.com/nicm/fdm
        
       | mattbillenstein wrote:
       | I still use mutt mostly, but it's harder and harder as more
       | emails come in as html - w3m only seems to get you so far...
        
         | rinze wrote:
         | For the HTML email that doesn't work as intended (which is not
         | a lot, mostly newsletters, which I prefer to read via RSS), I
         | use https://github.com/tshirtman/.mutt/blob/master/mutt_bgrun
         | and this macro. It picks up the first HTML attachment in the
         | mail, saves it to a local file and opens it in a Firefox tab
         | (and Firefox is already typically running):
         | 
         | macro index,pager ,b "<view-attachments>/html<enter><view-
         | mailcap><exit>" "View first HTML attachment in browser"
         | 
         | You'll need to combine it with this entry in .mailcap:
         | 
         | text/html; mutt_bgrun /usr/bin/firefox %s >/dev/null 2>&1;
         | needsterminal
        
           | mattbillenstein wrote:
           | Will give it a whirl, I also have a roundcube install on my
           | mail server (via mail-in-a-box), so it's easy enough to just
           | flip to a tab and read it there... Still only use mutt for
           | composing.
        
           | eqvinox wrote:
           | That'll presumably load all the spam tracking pixels if you
           | ever accidentally open a spam mail, no? Displaying HTML
           | e-mails really needs to run with all external resource fetch
           | disabled...
        
       | lelanthran wrote:
       | I stopped using local mail readers[1] when webmail became a thing
       | - it was just too convenient.
       | 
       | But I was still chugging along using the mozilla mail client to
       | read usenet (or maybe there was a separate usenet client?)
       | 
       | So after awhile I chose the path of least resistance and used the
       | same local client for both email and usenet.
       | 
       | And then gradually stopped using usenet, at which point webmail
       | became a thing again for me.
       | 
       | Now I use thunderbird, because local mail readers beat webmail
       | interfaces for convenience factors.
       | 
       | [1] First pine, then I upgraded to mutt.
        
       | anthk wrote:
       | Mutt is great with mbsync and mstmp.
        
       | bitwize wrote:
       | "How about you use a mail client from this century." --IT at a
       | place I worked.
       | 
       | Context: I was using Mutt to do email, and one day I found that
       | Exchange was configured to send _only_ HTML versions of each
       | message. If it received a plain text message, it would convert it
       | to HTML -- including changing things like  ":)" into J in
       | Microsoft Symbol font or Webdings or whatever it was. Typically
       | in an HTML mail environment, the plain text and HTML versions
       | would both be sent as separate MIME attachments, but in this
       | setup, only the HTML was included.
       | 
       | I filed a ticket, requesting that plain text messages be enabled
       | so I could read them easily in Mutt. This snippy remark was the
       | only response from IT.
       | 
       | So if you use a client like Mutt, be warned: nobody these days
       | feels any obligation to support your retro email experience.
        
         | mixedmath wrote:
         | I routinely work with people using screen readers and for whom
         | plain text email is perfect, while HTML email is a minefield of
         | unreadability. It's worse that different email providers use
         | different, inconsistent, and variable HTML formats.
         | 
         | The more I work with people using accessibility tools, the more
         | I realize that web accessibility is an afterthought (if thought
         | about at all).
        
       ___________________________________________________________________
       (page generated 2023-02-06 23:01 UTC)