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.
Let's be realistic: it's an email service. Complaining it doesn't do everything Google does seems a little unfair.
When you use gmail you conflate the standard with the app.
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.
IMAP actually has client-defined flags, but support on the clients is sketchy and not uniform
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)
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.
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 :/.
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.
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.
IMAP has one (two actually, IDLE and NOTIFY) but they are not really adapted to the way we use email today (mobile and browser-based apps).
If you want reliable email service without the nice app, there are much cheaper alternatives.
...you can reach Google over the phone?
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.
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".)
The single case where I used it was a good experience (though obviously you'll find a lot of people who had issues the support couldn't resolve).
You cannot if you just have your personal @gmail.com email.
Did I not understand you statement correctly? Like did you mean that you cannot set it up with other mail apps on the phone?
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.)
- 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 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.
This contrasts with Hey which will forward your old hey.com address to another address after you stop paying, and not make it available to future customers.
I also use a lot of the other fastmail features, like mail aliases, DNS, and file storage and web site serving. I'm very happy to pay the money.
While I would like to be able to, I suspect this is a typo...? :-)
The better option is to register your own domain for $10 a year, something hey doesn't seem to support?
i'm happily paying for e-mail and tend to think putting money down ensures I keep myself honest and maintain a workflow. Now I only save e-mails that are important to me, instead of archiving everything.
Spammers are going to find your domain name and spam it at obvious usernames anyway (eg contact@).
Besides what use-case do people have for throwaway addresses? In my experience in most cases the addresses you use aren't throwaway at all.
Fastmail does subdomain aliasing and I've been using that for years with my own domain without issues. Every subscription I have has its own email address. I don't need someone else's domains for that.
I don't think it's a given that spammers will find your domain, if you only provide your email to real people, and give generated emails to online services.
Email addresses that I use now look like this: [email protected]
If this leaks, I can track the source and I can bounce messages for this address.
While what you're saying is possible, a spammer needs to target you personally and that's not cost effective. It's not easy for them to try every possible English name at that address, because then they quickly get blacklisted.
Spammers collect addresses via scripts that crawl the web or via data leaks. It's more cost effective for them to get addresses that have been validated. All the spam I get are on these aliased addresses, biggest problem being the one I publish on my website, which I change periodically.
---
I like using my own domain even for aliased addresses because I can change service providers on a whim. I love Fastmail, but if they ever piss me off, I can change to Google Suite or whatever over night, the only thing required is some flexibility in setting up aliases.
Seems like it is Apple, Google, Outlook or nothing.
Isn't it down to the app to support those standards?
That’s entirely calendly’s fault.
An open spec is great, but it has to be adopted to be used.
If you want secure, you wouldn’t be using email in the first place.
I wouldn't consider them equivalent. Australian laws are some of the most intrusive on the planet and are shared amongst the 5/14 eyes without a warrant.
1) Sign up for Fastmail.
2) Sync all mail from GMail account to Fastmail (via the Fastmail web UI; you grant FM access to your GMail data through OAuth - once sync is complete you can revoke this access).
3) Set up an auto-forward rule in GMail for all incoming mail to go to your Fastmail address.
4) Set up a rule in Fastmail to put all incoming mail sent to your GMail address into a separate folder (or labeled with a special label if you're signed up for Fastmail's label beta). Any time you get email in that folder, that's a task for you to either unsubscribe or update the corresponding account to your new email address.
I'm currently in month #10 of migration. Most commonly used accounts were updated during the first couple of weeks. But be careful that the tail of services that are still configured to use your old email address tends to be long, and in my experience those are some of the more important emails that you don't want to miss. The ones that are only sent once every couple years.
Also, it really helps if you've been using GMail with a personal domain name (e.g. through Google Apps). In this case migrating is a matter of pointing the MX DNS records to Fastmail's servers. Bonus points: Fastmail allows wildcard recipients, so if you prefer to have unique addresses for each service you sign up for, you don't even need to set up a separate [email protected] alias. Just register with <whatever>@example.com and you'll get all email delivered to that address in your inbox, and you'll be able to specify it as the sender's address if you decide to reply to some of those mails. Having a separate email address for each web service also makes looking up who leaked what on haveibeenpwned.com more fun.
0) Get your own domain and set up MX record to fastmail servers
This way if you ever migrate again, you will not need to do it all over again. One word of advice - keep your registrar login and emails associated with the domains _not_ on your domain, otherwise it is going to present a problem should you ever need to fix anything related to domains.
Recently my provider decided to randomly cancel my domain, getting it back from transfer with everything out of date was painful.
Basically, if you register your domain through namecheap, then after setting up email at *@ximeng.net, don't update your email address to be [email protected] when changing the rest of your accounts. Reason being, if for some reason there is a problem with the domain, you don't want your only means of fixing that problem to potentially be invalid.
Therefore it wouldn't be a bad idea to keep the account associated with your registrar still on the original Gmail address (or if you are really paranoid, create a new email address through someone like protonmail just for your registrar account).
I have to manage a domain and have a basic understanding of how DNS works, that is unavoidable.
DNS is a bit complicated to describe in short reply but on a very high level: say I register a domain example.com. Registrars usually give you an interface to manage DNS where you can set A records (association with IP), you basically put there 2-5 IP addresses of the DNS servers serving your domain. You can also setup MX records that are used to resolve mail servers for your domain. Setting up fastmail is simple: you tell them that you want them to serve mail for example.com and setup couple of MX records pointing to the Fastmail servers (they give you the full host names).
Eventually, when I jumped to FastMail, I repointed my domain name to it, and most of my new emails started coming over automatically, since the email address is now something I control. I monitored Gmail for a while regularly to catch straggler services. (I chose not to forward to avoid complacency with stuff going to Gmail before reaching my FastMail account.)
First, do a one-time import from Gmail. Fastmail has an import tool that does this over OAuth. Took me ~45 minutes to import ~50,000 emails.
Next, setup IMAP and SMTP on Fastmail for your Gmail account. This way, you can continue to receive and reply to emails sent to Gmail, using Fastmail as the client. When replying to an email, Fastmail defaults to the right sender (identity) based on whom the email is sent to ([email protected] or [email protected]).
An alternative is to setup email forwarding in Gmail, so you get a copy of emails sent to your old address.
If you don't have a custom domain, I highly recommend getting one and use that going forward. There might come a day when you want to migrate off Fastmail. With a custom domain, you just need to update the MX records.
See https://www.fastmail.com/help/account/migratetofastmail.html
No connection to them, just a happy customer!
- Frontier
- Green Man Gaming
- Paperspace
- Rainway
- SquareTrade
On top, I had some burts of motivation to step through my password manager vault occasionally and update accounts I don't log in to too much.