I’ve used Fastmail for years now on a work account. It’s best feature is that it’s not Google.
First, no phone support. Hardly acceptable when even Google has this.
Second, no collaboration suite like Drive/Docs.
Third, no addons I’m accustomed to having in my daily driver email suite. Things I miss include schedule to send later, default reply all, and no priority inbox.
Im stuck using Google for email and maps. I hate google and want to get off them entirely but Gsuite with 1Tb of disk space for my single user personal domain is so powerful and so cheap it’s impossible for me to switch without giving up too much.
Google maps I think has some real competition at least. I’m hopeful Apple Maps gets continued improvements so it can get the job done well enough I can drop Google maps this year.
I feel a bit different: Email is a standard. You are talking about an app. Send later is the job of the application,not the standard. Same with reply all. Intelligent priority inbox is _hard_ but i. Principle the same.
When you use gmail you conflate the standard with the app.
I largely agree with this, except that "Send Later" really does want some form of server support so it will happen even if you quit the app (especially on mobile). That said, there are third-party apps that do this, such as Spark (though they require storing your credentials on their servers).
Priority inbox is also something that can be done client-side. FWIW FastMail does actually have internal flags for "$ismailinglist" and "$isnotification" that you can access via advanced search, but they don't have any intelligent customization of these flags, no way to tell FastMail "hey this email was categorized wrong". You can write a Sieve script that adds/removes the flags yourself but that only works for stuff you can detect in a sieve script, i.e. no ML. Still, it's better than nothing when using the web app.
The point of these discussions is that the standard (IMAP specifically) is inadequate to a lot of modern use.
One good thing that Fastmail is doing is promoting a REST-like IMAP alternative ( https://jmap.io/ ) that makes it easier[1] to go back to the distinction application/protocol.
[1] by this I mean that implementing an app like gmail over IMAP would be a terrible idea, while JMAP would be at least a bit better (it also adds browser support as it allows HTTP as transport layer)
What, exactly, do you feel is deficient about IMAP vs. JMAP, other than the latter being a protocol that doesn't require a bespoke parser? The only thing even remotely semi-annoying about IMAP that I can think of is the way message identifiers are per-connection (but in some very important way that actually makes sense).
The only thing I know about IMAP are from JMAP, so I cannot say what is lacking in IMAP per se.
As far as I know a couple things that are pain points for me when using thunderbird/other IMAP clients (weird search limitations, strict folder hierarchy organization) are due to how IMAP was designed, but these are mostly minor issues that I imagine would not require a new protocol.
What I hope the advantage of JMAP will be is that it will provide a more flexible foundation for gmail-like interfaces on an open protocol.
At least all IMAP clients I have used have always felt... clunky and counter intuitive (I started using email with gmail, so maybe I just never learned the skills) even if IMAP already had all the good things JMAP claim, I think that the different focus on message and less historical baggage have a good change of producing designs that will feel more natural to me.
That "stateless" paragraph in that article is explicitly referring to the per-connection message identifiers I was referring to; but that state burden is mostly carried by the server (which is put in the awkward position of dealing with separate clients with individual state sharing a mailbox) not the client (which by definition has a unique state anyway), which the article even admits.
I will argue that if you use the right data structures--not that anyone does--it really isn't that hard to make that work on the server, and the benefits to the client are actually enormous... particularly on mobile!
The way IMAP handles message identifiers allows for the client to pretend to manage a ridiculously large list of messages without storing any state locally that isn't visible on the screen (like it is _so good at this_ as Mark Crispin seriously intended the original IMAP protocol to be used by thin clients for mail: synchronizing mail over IMAP was never the intended usage model), as the entire problem of managing that consistent view has been pushed to the server (where it is solvable, just no one cares enough to even do a basic implementation correct much less a good one as everyone misunderstands and detests IMAP).
FWIW, the argument for how JMAP supports update batching over push notification channels is in fact interesting for mobile clients :(. That is so totally the fault of the mobile networks and OS people, though :(. The correct solution for that is to provide a flow control layer for wireless IP, at which point every app could be doing its own end-to-end encrypted push notification stuff without having to go through Apple/Google, but the incentive structure to centralize notifications through a middleman was just too great :/.
> push notification... That is so totally the fault of the mobile networks and OS people
The issue for mobile is that unrestricted push notifications are a serious battery drain. I think that JMAP makes the correct choice here, a push notification is just an external action/url, how the notification is delivered to the human is left out of the protocol. I would say that it allows for both openness and centralization without a bias for one or the other.
Yes, I both understood that, acknowledged it, and then not only noted that a better solution was available but actually sketched how that better solution would work ;P. Given the poor incentives on the platform players here, I will thereby repeat the part where I understand and acknowledge the issue, but am going to then once again note how sad I am that we are in a world that didn't just solve this issue in an egalitarian way that doesn't require middle-man (using a flow control layer for wireless IP, rather than simulating that using an oligopoly of middle boxes).
oh, the reason for my answer is that I implicitly assumed that something like `a flow control layer for wireless IP` capable of solving the problem could not exist. Or better I cannot even imagine how it could work.
My understanding is that a important property is that the device does not receive network packets that are not "replies". So that it has control on when it is fine to power down the network (in a very gross simplification)
So maybe something like what you are describing would be a protocol where the client can say "pin me back with this for this category of events but no sooner than X minutes", but at a network level, like a tagged TCP sleep function.
I never thought of this possibility. In the form I have imagined it it is technically inferior, but it would be an interesting approach to decentralization and surely could be improved.
I’ve never been able to search my entire mail archive quickly over IMAP, using Gmail or Fastmail. Mobile IMAP clients seem especially slow and inconsistent.
IMAP exposes a pretty comprehensive server-side query system. If your email is being synced locally then you aren't dealing with an IMAP limitation, as it isn't even using IMAP. If it is searching remotely, wither the email isn't being indexed for those searches or the client is doing some ridiculously poor search strategy. Like, if you actually look at the mechanism IMPA exposes for this, it is pretty powerful. (The only real limitation is that the original SEARCH mechanism is per-"mailbox", but this was fixed a long time ago with the SEARCHM extension. But arguably the correct way to map Gmail to IMAP is to put all your email in one "mailbox" and use IMAP "flags" as labels anyway.)
So I’m told, and yet searching my mail from the iOS mail app over IMAP is slow and unreliable, so I use the Fastmail app, even though it is slower to launch. Have you found a mobile IMAP client that works? notmuch [1] looks like it would solve my problems on the desktop, but searching from mobile devices is important to me.
I've gotten better email support from fastmail than phone support from G Suite. It's not much use getting on the phone with people who can't solve any problems. Especially since you can't get on the phone with them unless you can login to see the code, and chances are auth issues are about the only actionable thing they'll actually help you with.
Do people use phone support? I've never used it for anything in my life. If I was unable to make something work without phone support I would just switch to another service.
I once got on to Microsoft for some phone support, After asking me lots of questions about myself which were necessary before they could answer the specific question I'd already asked, the person on the other end finished up by saying that this was a question I needed to put instead to the vendor who had sold me the product. I can't remember if they asked if there was anything else they could help me with today.
Microsoft Support can be quite good depending upon the product you need help with.
I’ve called them for help with a Office 365 issue and they were very helpful.
I’ve called them once for an Xbox issue (I wanted to buy an Xbox 360 game and it wasn’t letting me) and the rep didn’t really have a clue. I ended up finding the answer after searching a few Xbox forums.
Oddly enough though, even the enterprise product support can be very bad. I've had dealings with Microsoft over issues related to Azure while under EA, and they still took weeks to even look at the issue, which turned out to be a problem on their end.
When it comes to big-brand software and services, it can really pay off to buy via a good reseller or consultancy, who often offer much better support than the company that actually makes the product. Of course, that's not actionable advice when we're discussing which mail provider is best for personal use. (Although I suggest the answer is still "not O365".)
You can and it is good. Had to a couple of times the last couple of years and every single time the support was stellar. Not just did the first person on the phone know what s/he was doing, they went to lengths to verify my credentials, which is a bit of a hassle but I appreciate it since it makes me feel my accounts are "save".
Yes, I do several times a month on behalf of my clients. You can call them, chat with them, they call you back. They aren't perfect, but far from "you're on your own".
How often are you calling support? The only time I've needed them was when I was locked out of the admin account, and there was no way to reach a human.
Indeed. I've been using FastMail for email (only) for a couple of years at this point, and I've literally never had to contact their support.
It just works.
(I'd actually be more worried about the AU legislation about permissible snooping, but... and I can't believe I'm saying this... It works well enough that I don't care. Most providers have learned to not send actual sensitive info by email.)
I am happy with Fastmail too. Use it for more than 3 years and never look back. There is a hype about Hey mail recently but I won't buy it:
- It is more expensive than my current plan with Fastmail. Hey mail is 99$/year.
- As all of my current emails and contacts are in fastmail, I am not likely to switch to another providers. Also, because I am happy user, I don't see the need to switch.
I used to love google inbox but switched to fastmail when google killed Inbox and it was easy to choose between old gmail and fastmail. Hey might address why I loved about Inbox. However, it’s clearly designed with companies in mind. The $100/yr is steep for a personal email service. Plus, they don’t have custom domains yet.
I used to run my own mail server and it's not actually fun. If you run everything on the cheapest VPS possible then you still end up paying about $50 or thereabouts. So they're in the right ballpark. I'm happy to pay them extra so I don't have to worry about email server maintenance.
Replacing the data hungry black box of Maps with the closed ecosystem of Apple via Apple Maps isn't a win in my book :(. Still, may be better than no change. I just happen to be intentionally outside of Apple's all-or-nothing ecosystem so it isn't an option for me. Who makes a system like that, are they trying to dominate the world??? If they succeed in their business model, they will probably be more dangerous than Google - a ticking time bomb waiting for shareholder or executive level change toward nafariousness with gargantuan incentive begging for corruption. We already see the dangers based on how they operate the App Store.
There are three things that are hard to leave Google for:
1. My email address, I've had my firstname.lastname@gmail.com from almost the beginning of Gmail.
2. $99 a year for 2TB of storage that is shared across my email, images and Google Drive
3. Google One, I can share that storage with my wife and kids and also monitor my kids accounts.
I hate myself a little for tying my kids into Google with their own Gmail addresses but the process is too easy to ignore, I don't have time to cobble together a mishmash of services. One part of me thinks Google needs to be broken up, the other thinks it will be a pain in the ass.
First, no phone support. Hardly acceptable when even Google has this.
Second, no collaboration suite like Drive/Docs.
Third, no addons I’m accustomed to having in my daily driver email suite. Things I miss include schedule to send later, default reply all, and no priority inbox.
Im stuck using Google for email and maps. I hate google and want to get off them entirely but Gsuite with 1Tb of disk space for my single user personal domain is so powerful and so cheap it’s impossible for me to switch without giving up too much.
Google maps I think has some real competition at least. I’m hopeful Apple Maps gets continued improvements so it can get the job done well enough I can drop Google maps this year.