Can I do this (should I do this) with Mutt?

Wed May 22 23:56:08 UTC 2019

On 22May2019 15:03, John Long <codeblue at inbox.lv> wrote:
>I have around 10 email accounts I use actively for various mailing
>lists, work, personal etc.
>
>1. Is it reasonable to use Mutt with many email accounts? I know you
>probably can, but is it reasonable as in, is it manageable, is the
>performance good enough on a midrange box. Usability stuff, like will
>mutt automagically respond using the correct account (the account the
>email I'm replying to was received by), is it clear when you compose
>which account you're using. Etc.

You need to orchestrate switching accounts if you want it particularly 
easy.

Someone has posted a folder hook which switches their From: header if 
they enter that folder. I don't entirely work that way myself.

I've got:

- an "alternates" regexp matching my various email addresses; this lets 
  mutt know what email is to me versus some list

- some reply-hooks to fiddle the from in some settings; for example I 
  switch to my gmail address if theres an @googlegroups.com address 
  present because Google's stupid that way; some of my mailing list 
  subscriptions are unavoidably google groups.

- some folder hooks, which exist essentially to fiddle my settings when 
  I use IMAP directly from mutt to match the imap target.
  My normal use is local folders, like you.

Someone else should describe account-hooks - I suspect I'm misusing 
mine.

>2. I have around 100,000 emails right now between all my accounts.

That's nothing large.

I do recommend using a mail indexer for big searches. I use notmuch 
myself, via some simple wrapper scripts for ease of use. It is easy to 
have a cron job or something maintain this silently; you can just ignore 
it until you need it.

>I have one pop account because my ISP mail server doesn't support IMAP.
>I use IMAP with all the rest.

This should be ok.

>I like having the email on my box(es)
>rather than leaving it on servers.

So do I. Do you _remove_ it from the servers or just keep it synched?

>Of the mailbox flavors, which is
>appropriate for this volume of email?...and also for the let's say 200
>a day I get between the various mailing lists I'm on.

Only 200? Again, nothing unreasonable there.

Use Maildir. It uses one file per message and is explicitly designed for 
lock free activity, meaning you can point multiple mutts or other tools 
at a mailbox without worrying about conflict.

I us compressed mboxes for archive folders though. Simply more compact.  
They are not folders I access regularly though.

>3. I seem to remember that mutt didn't poll automagically for pop3 or
>IMAP or both. Is that still true? Is there a way to get mutt to check
>mail every 10 minutes, 15, etc. without middleware? I don't want to get
>into fetchmail, getmail etc. I want the client to do it all.

I think this is the wrong choice. 

It is good to separate the mail fetching and sending from the mail 
reading. That way it can just tick along independently of your mutt (or 
other tool) use.

Let a fetcher collect email, and just have mutt poll folders (which it 
does).

For myself, I fetch my email from various accounts using getmail 
regularly, with a short delay before the next poll. It all gets 
delivered into my +spool folder.

I send email via my local mail system i.e. just the local "sendmail" 
command (postfix on a Mac for the laptop, postfix on an Ubuntu system 
for the home server).  This avoids all sorts of problems configuring 
mutt (and other tools) - you do it once, for the system mail. Then: 
_everything_ can send email, and you can dispatch email while offline - 
it'll go out when you're online again, courtesy of the mail system being 
a proper mail system.

Nor do I file messages with mutt (except by hand of course on an 
occasional ad hoc basis). Like most mutters I file messages with a 
separate rule based programme. Procmail is popular, but it tends to be 
integrated into the fetching. I have my own gripes with that and with 
procmail itself, and use my own filer (mailfiler). It monitors the 
+spool folder, and files anything which appears there according to text 
based rule files.

One consequence of this is that I do pull messages from my ISP inboxes, 
emptying them.

If you wish to keep the upstrwam populated (for example a work IMAP mail 
folder structure) you might use offline-imap, which will maintain a 
bidirectional mirror of an IMAP server with a set of local folders.  
Changes upstream come down, and changes you make locally go back up. So 
you can work on the local folders and know that the upstream IMAP will 
reflect that.

Mailfiler and offlineimap require Maildir mail folders, at least for the 
folders they use.

>4. For the idiots who persist in sending HTML email, even my current
>GUI client borks, sometimes badly, and the email is unreadable. Is
>there any tolerable HTML support in Mutt?

I do a few things for HTML.

First up, when there's no (meaningful) plain text I use my unhtml 
script:

  https://bitbucket.org/cameron_simpson/css/src/tip/bin/unhtml

for presentation. This is done with mutt's:

  auto_view text/html

setting and this:

  text/html; exec 2>&1 && env DISPLAY= unhtml %s; copiousoutput

in my ~.mailcap file.

As mutters, we still prefer plain text over HTML, as indicated by the 
usual:

  alternative_order text/plain text/html

However, many mail applications or organisations sent brokens 
multipart/mixed messages, with the text/plain part present to ZERO value 
because it is essentially empty. I special case these with this little 
dance:

  message-hook . 'unalternative_order *; alternative_order text/plain text/html'
  # Apple Mail embeds attachments in the HTML part instead of outside 
  # the multipart/mixed
  message-hook '~h "X-Mailer: Apple Mail" ~X 1-' 'unalternative_order *; alternative_order text/html multipart/mixed text/plain'
  # senders who can't seem to master multipart/mixed, and send empty or 
  # useless text/plain sections
  # or just badly badly formatted plain text, such as live.com etc
  message-hook '%f htmlers | ~f @no-reply at cc.yahoo-inc.com | ~f @outlook.com | ~f live.com | ~f @facebookmail.com' 'unalternative_order *; alternative_order text/html text/plain'

There are just 3 message-hook lines in there, should it get folded. They 
do the following:

- set the default to text/plain text/html
- set to "text/html multipart/mixed text/plain" for Apple Mail messages 
  with at least one attachment
- set to "text/html text/plain" for known "useless plain text" offendors

Aside from an assortment of badly behaving domains, I also maintain a 
%htmlers mutt group naming individual offendors.

This way we don't waste effort on known bad text/plain sections.

The script unhtml is a bit overengineered, but the core facility is at 
the end, where I run "lynx -stdin -dump" or "w3m -dump -T text/html" 
depending on my current fancy. I do mean to put some ANSI colour support 
in there one day.

The advantage of keeping a distinct "unhtml" script around is twofold: I 
can hack the script at any time for some feature without mucking with 
other configuration (mailcap gets used by more than mutt, for example) 
and I can use unhtml itself in other scripts outside of mutt.

For important and genuinely hard to handle HTML messages I fall back to 
my "dump the attachments" macro:

  macro index,pager V "<pipe-message>mail-open-attachments<enter>" "extract attachments to temp dir and open"

where "mail-open-attachments" is another script:

  https://bitbucket.org/cameron_simpson/css/src/tip/bin/mail-open-attachments

It makes a temp dir, runs munpack to extract the message parts, then 
opens the file browser on that temp dir. On my Mac that's a Finder 
window where things like quickview (Cmd-Space) pop up a nicely rendered 
preview, which works for images and HTML amongst other things.

Happy to elaborate on things beyond this brief sketch.

Cheers,
Cameron Simpson <cs at cskk.id.au>