Thank you for a superb, helpful email Cameron. I'll go over this and a few things posted upthread and come back with questions later.
Thanks, /jl On Thu, 23 May 2019 09:56:08 +1000 Cameron Simpson <c...@cskk.id.au> wrote: > 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>
