Can I do this (should I do this) with Mutt?
John Long
codeblue at inbox.lv
Thu May 23 10:31:54 UTC 2019
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 <cs at cskk.id.au> wrote:
> 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>
More information about the Mutt-users
mailing list