On 22May2019 15:03, John Long <codeb...@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-re...@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 <c...@cskk.id.au>