1,587 karma · joined April 26, 2012
The senior staff have all been working on it for over 15 years. Anything can happen of course, but you’ll be hard pressed to find a tech company with more apparent longevity.
(Source: I am one of those senior staff)
> every email ended up in spam. This included emails from myself, others from my own gmail, and even replies from people I'd emailed first.
It should go without saying, but that's definitely not the common (or expected!) experience. Our support team would be very happy to look into it for you: https://www.fastmail.com/support/
Normally when people see this kind of behaviour, it's because of one of the following: * They've connected an IMAP client that has its own spam filter turned on, and it's actually this moving all the messages to Spam, not Fastmail's spam filter. * They've accidentally mis-trained their personal filter by reporting email they want as spam.
Having said that, of course we can have issues on our end too — that's why we have a real human support team with the power to escalate to the relevant engineers.
(You can also read more on our open source and standards work at https://www.fastmail.com/company/open-source/)
Yes.
> How much additional work went into the desktop-app?
About 4 months work for 2 developers (but with both of them handling other things that arose during that time too).
# Why Electron?
Because it lets us build an app that works well across all major platforms with the resources we have available. Building an email/contacts/calendar app is a huge undertaking. Doing it from scratch on each platform is just not feasible for us.
With Electron, we can maintain a single code base across all platforms so we can move faster, and keep feature parity everywhere. More than that though, we believe it lets us build a really great experience on each of these platforms, while offering a consistent UI for our customers across all their devices. Honestly, we can never out-native Apple because by definition whatever they do is "native", even if it sucks (Liquid Glass on the Mac is … not great UX). If that's your primary consideration, you will always be better with Apple's own Mail app, so it's pointless us trying to build something in that space. (And instead we work to also make Fastmail the best service to use Mail.app with — which we believe it is!)
# Why would you use this instead of the webmail?
If you prefer to keep Fastmail in your browser, great! You can do so. But we hear from many customers that they would rather not have their email mixed in with their tabs. With a separate app you can see it in the dock, Cmd-tab to it, make it your default email app system wide etc. It also lets us integrate with the system, like the Mac menu bar and native context menus.
# Why would you use this instead of an IMAP client?
If you've ever used the Fastmail web interface you probably already know the answer, but for everyone else…
1. It's a lot faster. Compared to Apple's Mail.app for example (which is a good IMAP client!):
- It resyncs way faster when you open the app, and uses a lot less data (JMAP is so much more efficient).
- Moving between messages is quicker. With Mail.app there's often a slight lag between clicking a message and it rendering. In Fastmail, it's usually instant.
2. It's more powerful. We provide the best standards support out there, and are also working to make the standards better. But there's always going to be more that we can do when we control both the server and the client. With the Fastmail UI you can: - Add private memos to emails
- Mute conversations to ignore replies
- Pin important messages to the top of your inbox
- Schedule messages to send in the future (and not need your laptop to be online then for it to work)
- See related emails when you open your contacts.
- Add events straight into your calendar
- And much more (https://www.fastmail.com/features/).
3. It's got much better search. (Yeah, this is kind-of just "more powerful", but I'm calling it out because search sucks in most email clients0.# And finally…
This is just a choice. We hope this is something that some of our customers will love, but we're not backing away from our commitment to open standards and encourage everyone to find what works best for them.
I'll try to answer any other questions as I can.
The performance has been pretty decent, even with multi-gigabyte mailboxes.
You can hack around it by converting to monthly billing (which will give you a credit), then immediately convert back to 3-year subscription (your credit will be used, so you'll only pay the difference). The end result is essentially identical to an early renewal.
I'd also like to reassure you that we don't immediately delete your account if renewal fails! We have a slow degradation process that gradually disables sending, then receiving, then finally access to anything other than billing if the account continues to go unpaid over several weeks. But our support team can (and do) delay this process if for whatever reason you are having difficulty making a payment and reach out to us.
True … but the reaction to this by the vast majority of users is to go "stupid password manager autofill not working again", and copy and paste their password out of the pw manager and paste it straight into the phishing site…
Once your next step is not necessarily a password, having just the single username input up front becomes necessary to avoid confusion. To support non-resident passkeys (passkeys on devices that can't store the username with the cryptographic key), we need to be able to prompt for the username, then offer them their passkeys to log in.
This does have the effect of making it slightly less ergonomic for just username/password input, but we did everything we could to mitigate this:
> First, I can’t do username <tab> password <enter>.
True, but we made it so you can do username <enter> password <enter>.
> Secondly, with auto fill, it requires two clicks to sign in.
True, but the way we've set it up should ensure the autofill did both immediately, so you don't have to activate your password manager twice.
The flip side is if you do use passkeys, it can be much quicker than any username/password input. For example, 1Password will show you your list of accounts as soon as the login page loads, and it's just one click to sign in.
> no partial matches
To make your search fast, we use an index. This means we match on stemmed whole words by default (so a search for "bus" would match "busses", but not "business" for example). We also support prefix matching, if you end with a `` (e.g. "bus" would match both "busses" and "business"). We cannot support pure substring matches. This is exactly the same as Gmail as far as I can tell (although their stemming algorithm is probably slightly different). Gmail also doesn't support prefix searches as far as I know, just stemmed whole word matches.
> no matches for spelling mistakes
I see if your result has no matches in Gmail, it applies spelling correction and shows you what results this produces instead — I agree, this is a nice feature, I'll add it to our ideas bank.
> weird indexing of some sort of email content (attachments?) that leads to a match when there is absolutely nothing related in that email
We index the contents of attachments (again, as does Gmail I believe). By default we search everywhere, including inside attachments if you just search for a word. Most users find this helpful. If you want to restrict to just searching the message content, you can do so with the `body:` operator.
> it has no idea about the context of the search to improve matches, like 'flight' being possibly related to e.g. travel
I'd love to hear more about how you expect this to work. Searching a Gmail account on the web for "flight" doesn't seem to do anything special I can see, but maybe it does so in their app?
You always use your username for authentication. (But it's not special other than that; you can send from any of your addresses equally.) You can rename your user to your address at the custom domain in Settings -> Team & Sharing -> User management. (Direct link: https://app.fastmail.com/settings/team/users).
Firstly, I will say this incident was unacceptable, and we were deeply sorry about it. However, it is also the only time it has happened in our over 20 year history (to the best of our knowledge of course). We already had several projects underway to improve the security of account recovery at the time, which unfortunately hadn't quite landed yet. Since then we have introduced an automated recovery tool with a very carefully designed flow (more info: https://www.fastmail.com/blog/security-account-recovery/) that securely handles most common cases (e.g., forgotten password, or user's account stolen due to password reuse/phishing). Human support is still available, but any account recovery request can only be handled by senior support agents who have undergone rigorous training, and in the case of any doubt are escalated all the way up to our senior security engineers.
Elsewhere it's been mentioned that different people may have different priorities in balancing ensuring they don't lock themselves out, versus ensuring an attacker can never access their account. We provide some flexibility here. If a user has 2FA enabled, we must verify two separate means of verification to grant access, whether via our automated tool or support-assisted recovery. Users can also submit a support ticket to request we add a note to their account to never do human-assisted recovery.
I realise it's very hard to assess the security competence of an organisation from the outside, and for what it's worth, we think the Google security team also do an excellent job. But overall I think we do a very good job of keeping users secure while not locking them out of their own account.