nmjenkins

(I work for Fastmail). That sounds odd – have you contacted our support team so we can look into it? https://www.fastmail.com/support/

Offline support was added in August last year: https://www.fastmail.com/blog/fastmail-works-offline/

Fastmail’s been around since 1999. (That’s 5 years older than Gmail…). It’s profitable and employee owned, not VC funded.

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)

(Chief Product Officer at Fastmail here.)

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.

Fastmail does not run on AWS: https://www.fastmail.com/blog/why-we-use-our-own-hardware/

No final decision, but possibly not. Given Apple are dropping support for x86 Macs next year, it's unlikely to be something we could support for the long term.

The desktop app will automatically pull from Gmail when you refresh the folder/label it fetches into, just like on the web.

I'm sorry you feel like this, but it absolutely doesn't mean that. I believe we probably devote more engineering resources to open standards development than any other company, with significant resources given to the mailmaint, calext and jmap working groups at the IETF, not to mention the maintenance of the open-source Cyrus IMAP/JMAP server. I don't know why would do that if we were trying to just keep people captive because it's hard to leave. "Your data belongs to you" is one of our core values: https://www.fastmail.com/company/values/

(You can also read more on our open source and standards work at https://www.fastmail.com/company/open-source/)

No product plans to announce here at the moment, sorry, but we're aware there are a bunch of people that would like this.

The main thing is better integration with the OS. So no browser chrome (even as a PWA, the browser adds buttons or a toolbar over the top of the app), integration with the Mac menu bar, native context menus, the OS semi-transparent background for the frame so it feels like it belongs.

Just to be clear, does this mean the app is mainly reusing the already existing codebase of the web-app?

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).

In Settings -> Mail Preferences you can choose to: * Show images by default for everyone (the images are always proxied via our CDN, so your IP is never leaked to the sender). * Show images for contacts by default. You can easily add new senders to contacts by clicking their name at the top of the email and selecting "Add to contacts".

Next day or two is my best understanding, we're just getting it onto Flathub to handle app updates.

Chief Product Officer of Fastmail here. I see a lot of comments here from people that don't appear to have actually tried using the app, which is a little disappointing; don't knock it 'til you've tried it! Happy to answer any questions, but to answer the main ones that are popping up:

# 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.

  - 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/).

# 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.

No, CRDTs wouldn’t be useful right for what we currently do. If we ever wanted collaborative text editing for something then we’d use them for sure.

Or you could … just build it directly on indexedDB. That's what we did for our offline support at Fastmail, with just a small wrapper function to make the API promise based: https://www.fastmail.com/blog/offline-architecture/

The performance has been pretty decent, even with multi-gigabyte mailboxes.

Support is coming soon, available now in public beta: https://www.fastmail.com/blog/offline-in-beta/

A user is not the same as an email address! You can have up to 100 domains and (with wildcard aliases) basically unlimited addresses with a single user at Fastmail - you just pay per inbox.

The short answer is our new billing platform (Paddle), which all new users are on and we're moving everyone to, doesn't support it. (We're moving from a home-grown billing solution to simplify our global tax compliance and give us support for more important things like billing in local currency.)

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.

Password managers are phishing resistant. The browser plugin will not offer to autocomplete passwords on an identical-looking punycode domain.

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…

(Chief Product Officer at Fastmail here.)

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.

Fastmail has way more powerful server-side filtering than either Exchange or Gmail. https://www.fastmail.help/hc/en-us/articles/1500000278122-Ma...

Have you contacted our support team about these issues? Both sound very unusual, and we'd be happy to look into them for you. Drop us a line at support@fastmail.com or you can create a ticket at https://support.fastmail.com/support/

We do this at Fastmail and, if I say so myself, our implementation is pretty damn good. We’ve had this for over a decade, so it was originally built for much lower powered devices.

(I work for Fastmail). I'm not quite sure what to make of this. We believe our search is generally as powerful as Gmail's, and in some ways more so (see all the things we support here: https://www.fastmail.help/hc/en-us/articles/360060591213-Sea...), but we're always happy to hear ideas for improvements.

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?

(I work for Fastmail). Our search is comparable and in some ways more powerful than Gmail's search. If you're having problems, please create a support ticket (or just email support@fastmail.com) and we'd love to look into that for you. Thanks!

(I work for Fastmail). That sounds very surprising. Please email support@fastmail.com with the details and we'll be happy to look into it for you. I don't believe we've ever had an instance of Sieve not working correctly. (We have had plenty of reports that boiled down to people making errors in their Sieve scripts; we recommend most people use our UI instead to make their rules, to allow you to preview results and help ensure the syntax is correct.)

To change your default "From" address, go to: Settings -> Signatures & Compose -> Compose options and it's the very first setting at the top. (Direct link: https://app.fastmail.com/settings/sending/composing).

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).

(Architect of Fastmail's login/account recovery protocols here.)

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.

If you go make an API key in Fastmail (Settings -> Password & Security -> API tokens), you'll see that it's prefixed very similarly to that (e.g. `fmo1-`) for this very reason! (There are some other neat things about our API key format I'd be happy to tell you about sometime if you're interested.)