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