I'll never forget, for the rest of my life, a devastating email scenario that I was one keypress away from executing that would have had serious dire consequences.
It was 2003 and I was a dedicated and exclusive Mutt user (this, before Gmail came along).
Due to some accidental press of the wrong key combination, somehow Mutt managed to take every single email in my Sent folder and combine it into one gigantic aggregate text document -- a record of all emails I'd ever sent from that account -- and turn this aggregate itself into an outgoing email, ready for sending.
What's worse, it took every address that had ever been in a To: field in any Sent mail and put them all as one big list in this aggregate email's To field!
With just one more keypress, had I accidentally then sent this, every person I'd ever emailed would have received a copy of every email to any person I'd ever sent.
Can you imagine the disaster? That I could concoct such an email accidentally was terribly frightening and that was the last year I ever used Mutt.
Well, if you do want to send all-your-emails-since-ever to all-your-contacts, I bet it's a lot harder to do in Gmail. Perhaps that's where Mutt shines!
You're joking, but it's true. It's the same thing with any poweruser tool, like Vim and tiling window managers. You can accomplish surprisingly difficult tasks in just a few keystrokes, but you can also destroy everything just as easily.
TBH I don't think you can easily destroy things in Vim/Emacs though. As long as you don't for some reason run it as sudo the security mechanism is quite robust.
'T' means tag messages matching a given pattern. '.' would be the pattern that matches all messages in the current mailbox. So now all messages are tagged. ';' is the prefix for 'do the next command for every message that is tagged' and 'g' is reply to all.
Mutt will then assemble everything into a single massively multipart mail message and bring it up in your editor so that you can write an additional message of your own. Then you have to save the edited file and OK mutt to send it.
I would not characterize this as a single command...
[mayer]Marissa Mayer, VP, Search Products and User Experience at Google
confesses to CNN Money that she doesn't use Gmail for her business mail.
"I don't feel overwhelmed with information. I really like it. I use Gmail for
my personal e-mail -- 15 to 20 e-mails a day -- but on my work e-mail I get as
many as 700 to 800 a day, so I need something really fast. I use an e-mail
application called Pine, a Linux-based utility I started using in college. It's
a very simple text-based mailer in a crunchy little terminal window with
Courier fonts. I do marathon e-mail catch-up sessions, sometimes on a Saturday
or Sunday. I'll just sit down and do e-mail for ten to 14 hours straight."
Pine is a mail program developed at the University of Washington. It has a lot
of keyboard shortcuts and countless ways to sort, shuffle, and sift through
your email.
People often talk about Mayer as the pinnacle of work ethic, but it often sounds to me like she needs more "work smarter, not harder". 10-14 hours of email once a week sounds like a remarkably bad idea to me.
(Yes, I know she's also phenomenally successful, but so are MANY more people that don't share her methods)
I don't think if you work like crazy 24-7 there's any "ethic" in it. I'd say it's more of some sort of morbidness. Human beings are not meant to live this way, and exemplifying such an attitude really makes a perverse and toxic culture.
Pine was the defacto email client for so many universities (including mine); these kids today don't know what they were missing! It was a rare window of human Time On Earth where every single person at my massive nearly 100K-size college used Control-X to send every email.
This requires a secretary (or at least an AI that's able to prioritize as well as a human). GMail is getting there by filtering out obvious cruft (spam filtering, flagging as important, moving social and promotional emails into their own tabs, etc), but falls down in terms of prioritizing non-obvious cruft.
From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [git pull][resend] Input updates for 2.6.22-rc7
Date: Fri, 06 Jul 2007 01:11:27 UTC
Message-ID: <fa.IgmANxZoEvqGUWkoZEe414vIYlQ@ifi.uio.no>
On Fri, 6 Jul 2007, Jesper Juhl wrote:
>
> > I'm constantly surprised by just how _many_ ways MUA's find to screw up.
>
> 'pine' actually seems to work pretty damn well once you disable the
> flowed-text "feature".
Yes. And 'alpine', it's modern version, does even better, but you also
need to make sure to disable "downgrade-multipart-to-text".
I've been using alpine for a while now, and it's nice to see it be utf-8
capable and able to handle other charsets well.
So as a former pine user, I can recommend upgrading.
Linus
Oh yeah, I had an MS-DOS build of PINE that got me through uni. After loading the packet drivers, I had just enough conventional memory to load the mail client as well. Good times.
I use it daily. It's a lovely email client. Close to the Unix ideal of doing one thing, and doing it well.
Integration with other utilities (notmuch, isync) for indexing and sync'ing is very easy, thanks to close adherence to Unix principles, and gets you a very neat setup. Nothing to envy from Gmail.
> Close to the Unix ideal of doing one thing, and doing it well.
In my opinion this concept does not work for most non-cli programs. How do you actually define this "one thing"?
Is "reading an email" one thing? And "writing an email" another thing? What about "spellchecking the email"? What about "managing all my email contacts"? What about "back up my emails"? What about "sign email with GPG"?
Do all of these things really need a separate program?
The unix principle works quite well for stuff like grep/find/awk but there is just now way you could make GIMP follow the unix principle.
That's essentially what Mutt does. But you could also use other programs to parse and read each email file if you wish. "Fetching email" can also be a different thing. I use offlineimap for that purpose and store my messages in the Maildir format.
> And "writing an email" another thing?
Yes. Even "sending an email" is another thing. The program that edits my emails (vim) is not the same program which sends them (msmtp).
> What about "spellchecking the email"?
I don't do this (with a program), but I assume you could just do it within Vim.
> What about "managing all my email contacts"?
I use OS X Contacts for that, so there's a command-line tool that allows me to search for and then insert those contacts in Mutt.
> What about "back up my emails"?
Again, another program! I keep my Maildir synchronized to my home server and all my other computers using BitTorrent Sync. Changes are backed up with Arq to Amazon Glacier every day.
> What about "sign email with GPG"?
Definitely its own program, although Mutt includes support for it you still need GPG installed and everything set up for that stuff in order to sign your emails. This is true for every other email client isn't it? I know I have to instal GPGMail to get the same functionality on Apple Mail.
So you see, all of these tools are really separate processes in and of themselves. The benefit to all of this is when newer and better technology comes around, you don't have to wait for your software vendor to support it. Instead, you just use a different program that follows the same standards, which have been around for decades. Some people, probably most, find this to be an unacceptable burden. For that, there are definitely great email clients out there like Nylas N1 and Google Inbox...but if you want total control in the same sense that you get from your shell and your editor, Mutt is the client for you.
Well, in case of mutt, it's just reading email from a local maildir. That is, a MUA (mail user agent) in it's own jargon.
Mostly everything else is outsourced. Composing is done by your $EDITOR, sending is done by an external program, fetching email by an external program too. Even indexing and querying is usually outsourced to a modern xapian-based tool, like mu or notmuch.
My own idea of the Unix ideal—I don't know how it accords with others'—is that there's nothing wrong with having an umbrella program that brings many pieces together, as long as those pieces are modular.
That is, I have no problem with being able to read, write, spellcheck, and sign an e-mail, manage my contacts, and back up my archive from within a single program; but it had better be true that, if I want to use vi instead of Nano to write my e-mails, then I can force the program to respect this wish.
(As is probably apparent, I'm a Pine user by experience; I've never used Mutt, but would like to give it a try.)
ImageMagick is a poor example of "doing one thing right" because every command line tool actually does a million different things with different command line switches. Additionally, it can't do everything GIMP can (which I think you're acknowledging with the winky face).
Imagemagick can't do everything GIMP can do. But everything Imagemagick can do can be scripted.
Need to convert 10, or 100, or 1,000, or 1,000,000 images? You might use GIMP for the first. You'd best give it up for the 2nd and further.
On Linux desktop, I had an Imagemagick command in my command history which would trim off the top n pixels of images to remove extraneous elements. Quick to call that up and run it on a new screenshot, or a series of shots, prior to posting online. The job was completed before GIMP would finish initialising.
> Do all of these things really need a separate program?
Indeed. This is one of the reasons why the unixy "One app does one thing" philosophers dislike the C++ language so much. C++ is built for creating precisely the kind of apps you are describing - Classes are a well-defined compartment or component that does this "one thing" business while the app co-ordinates their working towards a common good.
C, on the other hand, pertains much to their "one thing" philosophy and they like it very much.
> Is "reading an email" one thing? And "writing an email" another thing? What about "spellchecking the email"? What about "managing all my email contacts"? What about "back up my emails"? What about "sign email with GPG"?
>
> Do all of these things really need a separate program?
Yup. I used it for a few years. It also had a Tk-based GUI. Every email message is a single file. "Folders" are directories. So you can use your usual text-processing commandline stuff: grep, sed, awk, etc.
Using MIME or GPG required a little configuration (mostly preset properly) which hooked external programs to preprocess before sending or displaying the message.
> The unix principle works quite well for stuff like grep/find/awk but there is just now way you could make GIMP follow the unix principle.
It seems that the unix principle is most relevant when compiling a C program takes too long and no interpreters exist that are fast enough. So, you figure out all the higher level functionality that you will need for system administration and compile that long before needing to do any sysadmin work. When a problem arises on a system, you can write a shell script that uses those already compiled commands, instead of writing a C program and waiting for it to compile. If your initial code sucks, you don't have to debug and recompile; you just debug and re-run the script.
Compiling C programs is now substantially less time consuming, so you could use C for sysadmin work (shudder). C shell was perhaps a similar attempt to get the benefits of C, but without the downside of compilation times. I seem to recall some essay on the harmfulness of using csh, so C will continue to keep its place.
how about we break down each action one can take in the GUI as its own binary that is part of a larger set? that way the GUI becomes a wrapper that do one thing, wrap the binaries that all their own thing, but that gets composed to do larger jobs.
One IMO important thing that's missing from others' replies: It's extremely simple to integrate other programs for processing your mails. Want to be able to import patches sent to you into some git repository? Just write a small shell script that accepts the mail (or some attachment) as input and then create a keyboard shortcut in mutt that pipes the mail (or attachment) to that script, done. You don't need to extend mutt in order to be able to programmatically process your emails, you simply use standard unix mechanisms (a pipe or maybe a file) and call an external program.
> In my opinion this concept does not work for most non-cli programs. How do you actually define this "one thing"?
I don't see how CLI programs avoid this. "One thing" is a human idea, subject to interpretation. Should grep and sed be consolidated? Does find do too much? Why do we have both echo and printf?
> Is "reading an email" one thing? And "writing an email" another thing?
Mutt says so. You read and sort emails in Mutt, you write emails in $EDITOR and then you can add attachments and such back in mutt.
> What about "spellchecking the email"?
Well since mutt outsources writing the email, I can't really comment on what mutt does. But if you don't want to do spellchecking within your editor for whatever reason, mutt lets you pipe the contents of anything to an external program, so you could write your email, then select the message from the attachments list and type "|aspell -a<CR>" and you'll get a basic spellcheck.
> What about "managing all my email contacts"?
I think that's pretty clearly a seperate program's duty, since contacts are used by other applications as well. Not only does mutt agree with me, so do Google and Apple. Mutt makes it simple to integrate with external contact lists to provide autocomplete for known email addresses.
> What about "back up my emails"?
That should be taken care of by both your email provider and your personal backup solution. I don't see why an email client would care about backups.
> What about "sign email with GPG"?
Well that's a job for GPG isn't it? That again can be accomplished by just piping the message into an external command. If you use it frequently you'd write some config and scripts to automate it. I saddly rarely uses PGP for email so I don't have hands on experience with this, but it looks like mutt has built in support for this kind of automation. A more unix-aligned approach would be to ship an /usr/share/mutt/examples/auto-gpg.muttrc or something like that that users can just source in their config files.
> but there is just now way you could make GIMP follow the unix principle.
No? Represent layers as a bunch of image files in a directory. Have one program check when they change and composite them in realtime. Have another program render the output of that one to the screen. Have a third integrate with the rendering program and manage the creation of selections (represented as a selection mask, so it supports everything from rectangular selection to brush selection). Drawing tools and filters become programs that take an image and a selection and some (interactive) options and output a new image. Then you have a UI program that brings all these programs together.
If this isn't as performant as Gimp, you can optimize it, for example, by replacing pipelines between parts of the standard toolchain with some kind of shared memory IPC or something similar.
It's not that the ideas behind unix don't apply to modern software; people just don't give a fuck.
In fact, sometimes it can be the "only" thing you want. Most often it is the case with open source developers when they want to catch up a huge discussion thread. (Like bugs to email interface). Mutt is excellent here.
If I have something to add to the discussion, I have the option to use the command line or log in to web interface and post my response.
I personally always felt that "full applications" were disconnected from the Unix philosophy. By definition, such an application does many things: fetch things from the network, display them, sort them, ... it talks many protocols, concerns itself with many I/O systems.
I'm certainly not saying that it is the way to go, but a real Unix philosophy way of dealing with email would be to use a command to pull mails from a mail server as text files (heck, as a text stream!), then other commands to display them, sort them, ...
Well, mutt is close to what you say. It's just a MUA [1].
That is, it just reads emails on a local mailfolder. Fetching emails to that mailfolder from the server, sending emails and doing other operations is a task of 3rd party programs.
[1] OK, it has a few addons for lazy people. But most experienced users ignore them.
That's what mutt is. You can compile it with support for imap and smtp, and most packaged versions of it are built that way, but the traditional way of using it is just as way of reading and sorting emails. Fetching emails from the server is done by a POP or IMAP agent (I use offlineimap), sending mail is handled by an smtp agent (I use msmtp), composing emails is done with $EDITOR.
I don't think that mutt is the most unix-philosophy-aligned MUA possible, it feels kind of like GNU tools: unixy, but jam packed with too many flags and options and convenience features. The unix philosophy would prefer that the application's design be changed to better accomodate implementing those extra features externally where plausible. But the perfect unix MUA would do the same things as mutt.
Actually, the traditional way (that still works perfectly fine, actually) is to not "fetch emails" at all. You simply have an SMTP server on your machine and have it either be the MX for your domain or have the MX forward emails for your address(es) to your machine via SMTP, and then have the MTA deliver to the mailbox file or directory that Mutt reads from.
I think a lot of Mutt users do what you are describing.
I use mbsync to synchronize my mail over IMAP with my remote mailserver. I use mu to index it for search. I use msmtp to send mail. And I use mutt to read and write mail.
I used to be a mutt user back in the day, and it was great at the time, especially when unix/linux lacked anything really better, and there were no iphones or android devices. It was/is the best-in-class console based email client, probably still is.
I can't but help feeling though these days it just doesn't really gain you anything substantive to bother to learn it, or even continue to use it, and spend the hours it will require to dial in and maintain your configuration.
Most gui clients are good enough.. webmail (Gmail and alternatives) are good enough, unless you have some non-negotiable requirement that mandates you have your own self-hosted email servers, I have a hard time believing its not an overall productivity loss to spend time in mutt (or Gnus for emacs, and other such things).
If you like to tinker with that kind of thing, and you like making your email client a hobby of sorts, cool. But what do you really gain other than a techno-bauble to tinker with?
"and spend the hours it will require to dial in and maintain your configuration."
This is my main gripe with mutt. The days where I could futz around with 100 config setting for hours are long behind me. Just having to set up an smtp daemon every time, and having to maintain it, is such a pain in the ass. Probably most tools have moved on by now (I moved away from mutt in 2004 or 2005) but I used mostly postfix and qmail (when I got fed up with one I switched to the other for a few months, etc). Just having to remember the dozens of idiosyncrasies in those was enough of a PITA to make me switch to an integrated graphical mail program.
My main method of searching email was grep -R ~/.Maildir . When I think back about that - ugh.
the UNIX philosophy died with the advent of the web imo. The emacs editor/Mozilla suite (SeaMonkey) mentality of doing most things and doing them relatively well is the reality we have inherited.
Emacs has always been That Way. And then CERN/Mosaic happened, and browsers (being all-singing, all-dancing environments that do everything from page layout to hosting interpreters and databases, are also big apps) came along.
This has not lead to awk becoming an MUA, or tmux adding a flight simulator, or tee offering to store things as PDFs. Nor has it stopped the development of building-block tools - I still see more nifty new things built with more or less the same assumptions than I can play with.
The only thing I can think of is that you're referring to GUI apps, at least mostly on Linux. GUIs (or more specifically, what Alan Cooper termed 'sovereign applications', but they are mostly GUIs) are typically subject to Zawinski's Law in ways that command line tools are not. Heck, Mutt is somewhat subject to it, itself, for that reason.
Like most pop-philosophy, the Unix philosophy is too vague and subject to interpretation to really be a good guide or yardstick for your projects or ideas.
Its a nice little useful heuristic or reminder to ask yourself if maybe what you are doing is too much.
But maybe what you are doing isn't too much.
That's all it should ever be, IMHO... a reminder to check yourself at some point or another - but its perfectly valid to conclude that your monolithic, large app can and does many things well, and cohesively adds something of value to the software world, that can't or hasn't been accomplished by tiny composable bits, or at least not nearly as well.
Love SDF. (Of course, I run bash and Emacs on it, which will probably earn me a slightly-warmer spot in Hell someday than if I used ksh and vi like God intended.)
I use k-9 mail these days, which is OK but doesn't handle huge folders well. However, back when I had an n900 with its hardware keyboard, my mobile mail client was ssh, screen, and mutt.
not the commenter you want, but i had both a mobile client (if i am using mutt, that means i can access the imap/pop server from other clients) and the ultimate ssh client on my phone which gave me full mutt, in case i needed to have my procmail filters helping me)
Navigating any terminal software without a true keyboard is an exercise in frustration. Look, I understand what you're saying, but claiming that an ssh client on a phone is a full-fledged replacement for a touch-optimized UI is disingenuous.
really? until a few months ago, you couldn't find anything besides whole words with textual search on gmail. why do people have it's search at such high standards? how bad was the alternative you had?
It's funny, i have been frustrated since day 1 which gmails search. Granted, it could very likely be user error - as i often forget the set of keywords that might lead me to the email i desire, but regardless i as a user am left frustrated.
Since someone may ask, my desires are simple in nature, but i'm sure difficult to implement. I simply want to find an email. On the Google Search side of things, i have often been very impressed by the search results i am able to achieve. Yet for email, it's been far less successful.
On Search, i'm able to use synonyms, or hell even vaguely describe (in the case of movies) plots, and often be presented with what i want. On Gmail, it feels like Gmail has no idea about the context or content of my mail (which is arguably their selling point), and instead i'm purely searching by keyword. The frustration is amplified by the fact that Search(proper) works so surprisingly well, i'm sure.
Search has the benefit of all they data they have from the millions of other users who searched the same term and clicked certain results. It also has the backing of Pagerank. Your email is unique to you and doesn't have any of these advantages.
What are you talking about? What have you've been missing?
Senders name or email? That has always been an option. Has attachments? Been an option since forever. tags? Since forever. date? Available since forever.
Not OP, but here's something I miss in Gmail search all the time-- ability to target a search at a particular directory and its sub-directories.
Suppose, for example, I have set up a subdir for conferences. That subdir contains a bunch of subdirectories for individual conferences. I know the e-mail I'm looking for is stored in there, because it relates to a conference publication I wrote. However, that subdir itself is "empty" as far as gmail search is concerned (because it's a "tag" rather than a true subdirectory).
The net effect of these hollow imitations of directories is I can either target the search to a specific tag, or I can search throughout my entire collection of messages. (Or, I suppose, I can tag every e-mail with every single sub-tag represented in the directory hierarchy I have mentally set up, just in case I might want to search for it someday.)
The gmail ideal, of course, is that I abandon the notion of directories altogether, and just let all my messages stew in the ocean of e-mail that one accumulates over the years. Supposedly their "powerful" search capabilities will help me find what I want. In my experience, though, under this approach most reasonable searches produce multiple pages of possible matches. This, of course, is hardly efficient.
It would also be nice if I could perform a search and then pull out that page of returned results into a separate screen/window for ongoing reference. Often when I'm searching for something, I'm looking broadly for resources or related conversations, rather than for a specific message.
Another place where I feel gmail search is brain-dead is its lack of regex capability (which @devdas has already mentioned).
Yes, it supports nested tags, and the tags create structure that suggests directory nesting. However, as far as I can tell the search can't be made to honor the nesting.
To make my example explicit above, suppose I have a "directory" structure with dirs like `conf`, `conf/iaq2016`, and `conf/gmu2012`. Then a search in `conf` will not turn up results in `conf/iaq2016` or `conf/gmu2012`.
Believe me, I check this once every few months, always hoping that google will have improved their "tag" implementation.
I do appreciate your tip about multiple browser windows, though. In general, I don't like having multiple windows open to the same application-- but that's my problem, and not a design flaw in Gmail's search.
I wonder if we'll ever be able to do regex Google searches in the future, or if AI/machine learning will make that sort of flexibility redundant by the time the hardware would be able to handle it.
But seriously, all these hard core unix fans seem a little odd here. Gmail search has always been powerful, and is even more powerful now. It sounds like a case of user error if it isn't working for someone.
I'm not sure what you mean here - I've searched in email for years with gmail - and it's basically always been flawless. Search on From:, To:, Subject, Date, etc... - in addition to searching for content in the body.
I'm curious, what other search does one do in email?
The search I have the most trouble with is searching for things that match a label and are in my inbox. GMail will consistently miss messages. I don't know what it is about them, but I imagine it's some indexing bug. I can go to my inbox, click through the first several pages of messages, and see that a message is there, and has my label. I can go to my label, and find it there too. But a search for 'label:foo in:inbox' will come up empty.
I think my dissatisfaction with mutt + rss2email is more about RSS in general. It amounts to just being a short description of the article and a hyperlink, and at that point I might as well just load these websites in my browser.
I need a better article scraper. General solutions that try to detect content, like Firefox's article mode and similar, don't do enough.
Maybe a little more heavy handed but I use huginn for exactly that. Read in numerous RSS feeds and digest them into my email box. It does a lot more than that too.
Shameless plug:
I use sinntp[0] to grab newsgroup messages and put them into a mailbox.
You can also configure mutt so that it can post to newsgroups (see doc/mutt-integration.txt).
I do have offlineimap and mutt already setup and I can read emails, but haven't installed notmuch or done any configuration. Seeing 1.6 release reminds me that I should give it a fair try again.
https://github.com/karelzak/mutt-kz is another active fork of mutt with a whole bunch of improvements that haven't made it upstream yet. It's been accepting patches for most of the time mutt upstream had been asleep (years). For example mbox parsing in mutt-kz is about 50% faster
It's been many years since I've used mutt, but I'm considering going back to it. For a while, HTML email had become so common that it was uncomfortable to use a text email client, but that trend seems to have reversed...most of my business communication is plain text (maybe a shift in the people I interact with for business). The speed of mutt is damned near impossible to beat, and the bandwidth usage is so tiny (I can run it on the server, rather than locally, so only the mails I actually open get transferred). I'm living on the road again, and mobile internet has gotten incredibly expensive (I spend approximately $300/month on Internet now, even with very little video and large downloads), so I've been using a web-based mail client more often (Usermin, which is one that I work on, so it's an "eat your own dog food" situation), but it is currently not particularly fast for dealing with hundreds of emails per day.
Most MUAs these days send multipart/alternative messages, so even though most recipients see the fancy HTML version, the message also has a text/plain version that mutt will default to showing and you won't even notice it had an HTML part.
For those rare HTML-only mails, just install lynx and add this to ~/.mailcap:
This will make mutt pipe the html content to lynx, which will render it and spit back a plaintext version with all the embedded links at the bottom. You'll be able to easily scroll through the message in mutt as though it were plaintext.
Where do you live / travel where you are spending $300 a month on Internet? I live in Australia (not the cheapest place) and spend $50 AUD a month for 12G of data and free international calls to 10 countries.
I have T-Mobile, with 36GB of data spread across two devices. I also have Karma (it was the "Neverstop" plan, until they bait-and-switched that out of existence) with 10GB. I have two plans because T-Mobile network is awful in some places. I share internet with my girlfriend, so it's not just one person using this much data...but, I do use a lot of data.
Edit: T-Mobile "unlimited" is bullshit. It is only unlimited for the phone itself. Hotspot usage is rate limited to an unusably slow rate after data allowances is used (the limited rate is usually well below the 128kbps they claim, but even when it is reaching 128bps, that's unusable for the modern web, and the latency is horrific, so even shell sessions are impossible once you hit the cap). The only reason I stick with T-Mobile is BingeOn lets me watch Netflix without using much data; though the crappy speed of it makes it unworkable in a lot of locations. But, don't believe their marketing about "unlimited" data. It is not. T-Mobile also seems to measure bandwidth usage in a shady way; I use about 1GB a day on Karma...same kind of usage results in 2GB+ a day on T-Mobile. I haven't analyzed what's really going on with any precision, but I've noticed the discrepancy on a few occasions; it has happened often enough and to a large enough degree to where I think the smoke is indicative of a fire.
I am a reluctant Mutt user. I prefer it to webmail but I prefer a good native gui client to either. It is a very flexible solution but is a big investment in configuration and keypress memory for a casual user. It is a relief to see it still being developed. So much seems abandoned these days with the bleed to web and mobile.
Can anyone recommend a CalDAV based calendar program that either integrates into or works well along side Mutt? I've tried khal and it works alright, but I recall it being a little wonky with timezones.
I love mutt and use it as my primary email client. I got too frustrated with gmail's interface changing all the time and Apple's Mail.app introducing regressions each release. You can't beat mutt's speed and stability.
I do wish that there was an option to treat threads as the primary unit, like gmail and sup (http://supmua.org). The threading support isn't bad, but expanding and collapsing threads in the index view only gets you so far. Years ago I took a look at the code base thinking I might give it a try, but quickly realized that kind of change was a lot of work and way over my head.
Gmail's conversation threading, or the Thunderbird Conversations addon, are the only thing I wish for with Mutt. I once asked on the mutt mailing list about this, but the solutions were pretty ugly, mostly involving all sent mail copied in the inbox.
Still, mutt is my main email client. I only started using it a couple of years ago, after Thunderbird started to strain with my mail folders. In 1990s college days, I used Pine. Mutt scared me back then, tho mostly because no one I saw using it then edited with Pico.
That's not strictly new in this version. I've had that enabled (hesitate to say been using) for a while now.
Anyone know if the hanging between wifi to cable connections is resolved yet? Aside from that I'm much quicker and more productive with my inboxes now. Sidebar patch, hotkey per mailbox... Very quick icedove replacement.
PS: Workaround for the connection thing is to ctrl-z when it hangs, and fg the other instance for that connection.
Yeah good call. I have mosh running to various boxes all day, but the mail sits on 2 diff servers so I tend to bring them together on the local machine. Still, very doable. Could use tmux and mosh together on the pi even... Yep, thanks for suggestion.
Wow, this takes me back. Like someone else posted here, to around 2007 or so, which is when it was last updated.
Good to have this, although most of what I get these days (work-wise) is HTML-formatted or otherwise challenging from a readability perspective. I fully intend to give this a go against my mail archive (which goes back to '98, and which I currently access via Thunderbird, running inside a VNC server on an ODROID-U2 ARM board - which is a bit heftier than tmux...)
if you haven't already, have a look at w3m [1] or similar. I use mail cap to route emails though w3m and it's pretty rare that I notice anything amiss.
w3m is another project that hasn't seen activity in years. Why do people recommend it so much more often than lynx[1], which is still in active development?
Does anyone use Mutt with SMIME and GPG? Do you like it? I need a mailer with SMIME support for work. I am currently using thunderbird and would love an alternative.
I've been doing gpg and smime for many years; in the contrib/ folder in the dist tarball, you'll find a "gpg.rc" and "smime.rc". I don't think I've changed more than a couple of minor settings in those files; I just use muttrc's include directive and then override a couple of settings in my main muttrc.
With those settings gpg mail is very simple to do, and of course since its mutt its endlessly configurable if you need it.
The last time I looked into using mutt for work I read about problems with signed SMIME emails not being easily searchable. The overwhelming majority of the email I get is signed SMIME messages. If I can't easily search them it's a nonstarter. Have you had any problems with searching?
I haven't used Mutt in ages, but I'll be installing it tonight. 90% of my mail is done in Outlook (work) or Mail.app (home). I feel like those 2 applications have more users than they probably deserve.
I've been a Mutt fanboy for long now. Ironically seeing this announcement reminded me to give sup[1] another try. It sounds amazing to me, but when I tried first I had some issue with installation that I hope I can get past now. May be reporting on it later…
Since I'm an Emacs user, I recently switched from mutt to mu4e. It wasn't difficult, since I recycled most of the mutt setup: offlineimap, msmtp, mu, and of course the maildir.
Even more, I can still use mutt if I want to. But mu4e is so nicely integrated with the rest of Emacs that I think I'll keep using it.
"By default, POP3 and IMAP4 are disabled in Microsoft Exchange Server 2013. To support POP3 clients that still rely on these protocols, you need to start two POP3 services: the Microsoft Exchange POP3 service and the Microsoft Exchange POP3 Backend service. To support IMAP4 clients that still rely on these protocols, you need to start two IMAP4 services: the Microsoft Exchange IMAP4 service and the Microsoft Exchange IMAP4 Backend service."
most desktop clients (mutt included) almost died when everyone moved to gmail and such. imap/pop access was too expensive (when compared to having a so-so UI for free) or not available.
now that gmail and yahoomail give imap for free, they will surely comeback. see N1 for example.
Gmail has provided free IMAP since they launched, and Yahoo has had it for years too. Personally, my main draw to Gmail is that I just don't have to deal with ISPs blocking SMTP, which can get really annoying really quickly on laptops.
>ISPs blocking SMTP
is this actually still a thing? I know on our campus network they block SMTP on the wired network, but not on the wireless (for some boneheaded reason or another).
I've been on ISPs that block SMTP ans SUBMISSION along with their main alternative ports because they had too much spam sent from their IPs in the past getting them added to spamhaus.
Of course, they only needed to block port 25, but alas they blocked them all.
Most residential ISPs in the US, at least. Certainly all of the big ones do (Comcast, Time Warner, AT&T, Verizon, etc); the FTC has actually specifically recommended that all US ISPs block outbound port 25 as a spam mitigation measure.
Pretty sure gmail supported POP from day one, and it has supported IMAP since 2007 [1]. The problem is that gmail's mail organizational system is sort of incompatible with POP/IMAP and completely incompatible with a number of clients. That started to change around 2010 when gmail had been so popular for so long that the standards and clients started to accomodate gmail's way of doing things.
Desktop MUAs won't suddenly become popular now. A generation of users has been brought up on webmail, and the idea of using a separate program for email on the desktop isn't familiar to them.
I completely agree. Just during the last 24 hours I've heard someone repeatedly using expressions like "I've sent you a Gmail" or "Yes, you can send a message from Outlook to Gmail". As if Gmail was just another messaging service, along the lines of Whatsapp, WeChat or Line.
The person in question is someone who became "computer literate" relatively recently (at least compared to me, I'm 37 and always been tinkering since I was a kid) and has become accustomed to most on-line services while using smartphones and tablets, not a personal computer.
That person is not alone. To be honest, I think most people under 20 and most people living in developing countries went down a similar path (mobile first) and have a similar understanding of messaging platform.
You'd think, but the shift from desktop apps to web apps happened concurrently with the rise of mobile apps. It doesn't seem that users think of mobile and desktop apps the same way.
I really tired of having to use a browser to access my main email (Gmail inbox) and even worst to have to use another and different email program (Apple Mail) to access my other email addresses (I have few emails on those ones).
I look at Mutt willingly once about every 3 months, but then I'm always put down because of the last of Snoozing (that I've know off). I rely heavily on Snoozing in my main account to order my tasks.
Is there any workflow with mutt that achieves a similar workflow where I can postpone emails to a later date?
It was 2003 and I was a dedicated and exclusive Mutt user (this, before Gmail came along).
Due to some accidental press of the wrong key combination, somehow Mutt managed to take every single email in my Sent folder and combine it into one gigantic aggregate text document -- a record of all emails I'd ever sent from that account -- and turn this aggregate itself into an outgoing email, ready for sending.
What's worse, it took every address that had ever been in a To: field in any Sent mail and put them all as one big list in this aggregate email's To field!
With just one more keypress, had I accidentally then sent this, every person I'd ever emailed would have received a copy of every email to any person I'd ever sent.
Can you imagine the disaster? That I could concoct such an email accidentally was terribly frightening and that was the last year I ever used Mutt.