Email Apps Suck
schneid.io
schneid.io
Even if you are not a technical user, you should respect the fact that proprietary formats will bite you. Look how many this guy alone used. If you use opensource, even, the mbox and mh all email, one giant file paradigm is all nice until it is corrupted.
I wish more clients respected Maildir underneath, or tried to bend the truth on Windows FAT32 and NTFS ad the ; in path names limitation is a pain.
https://en.wikipedia.org/wiki/Maildir#Filesystem_Compatibili...
Sadly even Thunderbird has struggled to re-engineer a Maildir subsystem where it was never intended. Show me any email client devs who had the khutzpah to even dare that.
https://bugzilla.mozilla.org/show_bug.cgi?id=845952
But you have a lot of safety in spreading it across files, and you can throw dumber full text search at it, shell scripts, and a lot more flexibility over all.
Sadly, some Unixisms will never escape Unix culture. As someone who has watched people screw 10+ years of email in Thunderbird n>1 times, I wish for the love of God everyone would use Maildir in the client, regardless of interface, free or not, et cetera.
I'd hazard a guess that most proprietary formats are similar to the maildir format. Its just that the individual files are opqaue at the filesystem level. If you create thousands of tiny files then you are hoping that the file system design - which like any other design can only be optimized for specific workloads - can handle it better than a database type format specifically designed for email.
Then again a generic full text search system (which probably won't even know that they're email files) over those thousands of files would have to be better than a targeted design for email data.
You would miss certain optimizations like.. (making one up now) extracting and storing just the email headers in a separate region to speed up indexing and having some indirection built in to lookup that specific email.
- Almost all (open source and proprietary) prefer mbox-style
- If not mbox, then it is monolithic file per folder, very few if any store email per file like maildir, despite it having many benefits [0] (if you are smarter than Bernstein on such things, please do write on these things; no one gives a shit to explain email out because it is not sexy)
- The index system always stores data separate of the email store; I have not seen a counter example, perhaps for Outlook, which I presume uses the Windows/OSX OS-level indexing
- To get back to my point re generic FTS, there it is, keep the OS ones so people can search in one place (I use recoll and notmuch for email specifically; it's annoying)
- What optimizations are there for indexing beyond header info? Again, good FTS systems can be extended (for what I define as good)[1]
I do not mean to criticize your points, but I do support work and all of these clients do good for non-technical users, but are ticking times bombs that shit themslves and require resyncing all data when they corrupt massive multi-gig files, let alone re-indexing it all.
Using them is one thing, having to fix them is what informs my opinions on this and why I sync to maildirs, use mutt-kz, and webmail depending on mood and time.
[0] https://cr.yp.to/proto/maildir.html
[1] https://bitbucket.org/medoc/recoll/wiki/IndexMailHeader apparently they have improved, perhaps I shall ditch notmuch out of notmuch discipline for email! Haha
Personally, I never have IT problems, so I can't comment on the support burden. But I agree with you that if I had to re-prioritize, then reducing the support costs by trading performance and going back to a simpler format is probably worth it.
SQLite is used in many cases to store smaller things. It's likely not a good fit for a few gigabytes of email with binary attachments, though. I wonder what would be? NoSQL document-storing databases seem to have been created for a purpose like this. Is any of these used by any remotely popular client?
I have wondered the Sqlite thing myself beyond my one criticism. If anything, you would love K9 Mail on Android, which does this out of necessity.
And some people have made SQL and noSQL email stores.
http://nosql.mypopescu.com/post/3083070885/couchdb-as-email-...
Well, maybe the people writing email clients have already thought quite a bit on this topic, likely created several prototypes, benchmarked them and chosen one that works the best given their constraints and features. Now all that's left is to open the format specification :)
You know why mutt can be for me? I have a second program (isync/mbsync) sync the maildirs, a third to index it, and mutt is just for reading and sorting.
When you have one monolith doing all 3 at its will all the time, you get calls from users that Thunderbird and Mail.app are janky and the computer is hosed. It is interesting as FTS came to Thunderbird and they ran the indexer all the time, until they intelligently designed to have better controls around its execution as it destroyed general usability. Mail.app is better, but I see executive running it for days and it becomes a misbehaving pile of mess.
I am asking in a respectful tone and not to make light of your position, but what do you use? I want to get a better look into your view and I think this might help me understand you better, if you are willing to indulge me.
UPDATE: And when I say several things at once, ironically this is not by design! Email has changed a lot since the sendmail days (and that is cutting edge with respect to many veterans here) and thus there is well-known and accepted design I can think of beyond layers of addition on clients to meet definitions and changes in protocol, routinely made without any discussion of client operation beyond standards for file structures like mbox and Maildir, even they are formal standards, I would have to check,
Well OK, so the most important for me is search, and the second most important is being able to quickly apply labels based on filters on a bulk-scale. I have found mutt to not really be performant and the workflow that I achieved was rather brittle (complicated by other factors like having to deal with HTML email). I'm currently using Gmail, but I am experimenting with outlook and I quite like the performance. I don't have a ton of email, maybe around 3-4GB, 25K emails. Bulk operations like 'select all' - do X on several thousand emails takes seconds (which is still slow IMHO FWIW). I haven't seen such performance with other clients. Granted, I haven't broken down every single client and benchmarked different workloads, so I'm only speaking in generalities.
And don't worry about offending me. I was just trying to stir up some conversation. I don't take offense if someone disagrees with me on the internet.
As I suggested, I slip everything up into different applications. I use mutt-kz and not much with isync to sync maildir, view it mutt, and do label/filtering like Gmail locally with notmuch on a Xapian FTS subsystem backend. It's fun.
For me, it is one of the best clients... although I use primarily windows and sometimes Linux (where it works fine with wine), so I can't try the macOS-only ones.
"[...] it’s buggy and crashy, it needs to update my email library every few months when I open it (why does my email need a library?), and it lacks any sort of innovative feature set (or even support for things like snoozing)."
I can remember mail.app needing to rebuild a mailbox to a new format maybe twice or three times, since probably 2008.
1 person saying "x is buggy and crashes" doesn't mean much without actual descriptions of the problem.
I've used mail.app since I've used OS X, and I wouldn't describe any version I've used as particularly "buggy" or "crashy"
I realize this is just one data point, but as unpopular as your perspective is, stephenr, I share it.
Maybe I'm the odd one out, but I don't need any glitz and glam in my email client. I just want it to work and show me the email I want to see when I want to see it.
Or you have to make a PST export on a Mac and do it on a PC? Given my job, I am relieved but terrified I have not even had to worry about it. I just looked it up and chuckled. Not a surprise this will screw you.
http://answers.microsoft.com/en-us/mac/forum/macoffice2011-m...
Again, I said this before in another thread and stood in the middle of a minor flame. All email clients suck more than mutt.
Do I love mutt? Not so much. But the developers have the serenity to accept that which they cannot change, and that the whole charade blows. (Does a day go by where we do not pounce on those who propose secure email, as a protocol and system? Forget the clients even.) That, and I have low self-esteem and relate to people who poke fun at themselves for sucking a little less since the beginning. [0]
To relate it to a real technical issue. Mutt tries to be as nothing as possible, in terms of feature set and use case, while Outlook/Thunderbird/fat clients try to be everything.
Someone likened Outlook to Emacs (which I love ironically), which I would say is true with a caveat. Something as intimate as correspondence and personal communication programming needs to be powerfully extensible and customizable, and none of the fat clients have good interfaces for that. Not even mutt does easily, and this is the core of the problem.
Show me a world where everyone uses the same ink, pen, and paper to draft dead tree letters in the exactly style and preference and we can find an email that does not suck.
(Hint: there never was one and never will be! Let the downvotes descend upon me!)
[0] http://www.mutt.org/ I pray they never change this beautiful site and its header.
http://stackoverflow.com/questions/9814276/git-patch-file-at...
Too many 'modern' email clients try too hard to create a new workflow for email, I get an email, I read it - if I care about it I file it away in a folder or flag it for follow-up (at which point it will show in my tasklist in GW regardless of where I move the item), if I don't care about it I throw it in the trash.
[0]: https://freron.com/
[1]: https://www.indiegogo.com/projects/mailmate-2-0-the-email-cl...
I've used Fluid.app[1] to create 'standalone applications' of webpages. It's always worked great, and is almost what the OP is asking for for 'inbox'.
There may be extensions for other browsers as well, but I'm not sure about that.
It would be nice if Google added native support for notifications like they did with GMail though.
I've been using Mail.app for years and it's not bad for my needs, but it doesn't have any fancy features, for sure. But the fact that it's native and works decently with mail providers and allows me to manage multiple inboxes quite easily is enough for now.
It is also a database of all our past communications. Apart that mobile adds further complexity. It is likely that any one answer for it can miss out things in the enthusiasm to bring out a simpler version or in the over-enthusiasm to make it complicated than what it should.
It is hard to quantify the "needs" as it caters to a wide audience as a one stop answer. Slack like app can take away the professional side, or a Facebook can take away the social side, but no matter what, you still need a email as it serves as the identity to reach out for the Web applications.
So whoever is building a new email App needs to keep all of this in mind and come out with something nifty yet powerful.
Does it look okay in your browser?
start by disabling custom fonts. select decent defaults you like to stare at. done. perfect legibility, saved bandwidth, faster page load times, less data leakage to google (who magnanimously host all those fonts)
I wonder if that would actually break any programs that try and use Arial as the default font... hmm...
Email is a non issue for most people because most people just use a web browser and a mobile app. For the record, I wasn't impressed with Outlook for the Mac.
Sure you can – tap on the share button, then scroll to the Gmail icon and tap on it. A new email will be started in the Gmail application containing the page title and URL.
If you don't see the Gmail icon straight away, scroll to the end of the list, and tap on More… to add Gmail to the list.
I like Mail.app.
Maybe that's a personal deficiency.
- Select a group of messages (could be Command-A in a smart folder, for example).
- Then choose "File -> Save Attachments..."
- Finally, choose or create a directory where you'd like the attachments to reside.
As for managing them, I would imagine that would vary for each person in how they like to work and what they seek to accomplish.
0 - http://email.about.com/od/macosxmailtips/qt/How-to-Save-All-...
I actually sort of prefer email apps with this sort of pricing model; it makes me think they're trying to be financially sustainable rather than just getting acquihired in a year or two. I would definitely pay $7/mo for the right email app. (But I don't know if N1 is it; I added N1 and some other Mac-only email apps to the original article.)
OSX: Mail.app does the job very well, little bloat.
Linux: I like Geary. Lean but not as good as Mail.app though
Windows: Mailbird. Light but also not as good as Mail.app
For Business I have Outlook.
None is perfect but all do what I need in the corresponding context.
Is it as fast and perfect? No. But I do not have to store so much damn email or increase the efficiency of Gmail's real-time tracking of my butt all over the world.
Really the only thing email is lacking is good end-to-end encryption.
People suck at writing emails though. I partially blame Outlook, but also the unwillingness to wanting to read and write well. So much of the hassle of email has to do with volume and the sender not re-reading their writing before hitting send.