Fastmail Blog

Multi-window support and a better compose experience

2026-03-05T00:00:01Z

Today we’re releasing a major update to the Fastmail interface, with improvements focused on making mulitasking and compose better. Here’s what’s new.

Multi-window support

Sometimes you need to reference one email while replying to another, or draft several messages at once. Fastmail now supports opening compose and conversation views in separate windows.

Hold Shift when clicking reply, forward, or any compose action to open it in a new window. You can also use Shift+R to reply in a new window, or Shift+A to reply all. Or pop out a whole conversation into its own window by shift-clicking in the message list, or using the button next to the subject in the top right if it’s already open.

Your undo send timer works across windows too — if you send from a pop-out window, the undo notification appears in your main window so you’re still in control.

Inline replies

Replying to a message in a conversation now keeps you right where you are. Instead of switching to a separate compose screen, your reply appears inline within the thread, so you can see the full conversation while you write. It’s the most natural way to reply — you stay in context, and your draft lives alongside the messages you’re responding to.

If you’d rather compose in a focused view like before, you can expand your reply to full screen at any time. We’ll remember your preference.

A cleaner compose

We’ve unified the look of our compose view across mobile and desktop, giving you a cleaner, more consistent interface wherever you’re writing.

A few highlights:

Switch between Reply and Reply All mid-compose without losing your work. A new button in the compose header lets you change your reply mode on the fly, and Fastmail will intelligently recalculate the recipients for you.
Hide the formatting toolbar if you prefer a distraction-free writing area. A toggle in the toolbar lets you show or hide formatting options with a single click, and your preference is remembered.
Drag and drop recipients between To, Cc, and Bcc. The Cc and Bcc fields appear automatically when you start dragging an address, and tuck away again when you’re done if not needed. You can select multiple recipients using Shift-click for a range, or Cmd/Ctrl click to select individually.
Quickly add a recipient to your contacts or view their contact information if already a contact. Just click the recipient to select their token, then click again to get a menu of options.

Move the reading pane below your inbox

You’ve always been able to show a reading pane to the right of your message list. Now you can choose to place it below instead. This horizontal split gives you the full width of the screen for reading, which is especially useful on narrower monitors. You’ll find the option in your mail preferences.

And more

For those of us who don’t want our signature repeated in every thread, there’s now an option to turn off signatures on replies, forwards, or both. Head to Settings → Mail preferences to choose whether your signature appears above or below quoted text — or not at all.

We’ve also added find-in-conversation to our desktop app. Just hit Cmd-F on Mac, or Ctrl-F on Windows/Linux, to get a search box letting you quickly find text in a long conversation.

Why customers trust Fastmail

2026-02-23T14:00:00Z

We’ve been providing email since 1999. Over 25 years later, we’re still here, still independent, still employee-owned, and still focused on one thing: giving you the best email experience possible.

But we know trust isn’t built by what a company says about itself. It’s built by what customers say when they’re talking to each other. So we went looking. We searched numerous reviews, forums and tech blogs to understand what people think about Fastmail and why they choose to stay. Here’s what we found.

You’re the customer, not the product

This phrase came up more often than any other when people spoke about us. Across all of the forums and reviews we searched, the single biggest reason people trust Fastmail is the simplicity of our business model: you pay us for email, and we provide you with feature-rich email. It’s that simple.

When a business you deal with makes its money by serving you, not by selling your data to someone else, trust naturally follows.

Real humans, real support

This is the theme that surprises people most. At a time when reaching a real person at a tech company feels increasingly rare, all our customers can raise a support ticket and have that ticket directed to a real person. We saw in the forums that one of the most upvoted reasons for choosing Fastmail is that if something goes wrong, you can reach a real person without needing to write a viral blog post to get attention.

History — we have been around since 1999, and we aren’t going anywhere

Email is infrastructure. People always want to know that the service they have trusted for decades will still be there tomorrow. Fastmail’s history, dating back even before Gmail, is a consistent signal of trust across all reviews we found.

Innovative features such as Masked Email and aliases changed the way many people manage their online identity

Our alias feature and the Masked Email integration (with 1Password) are among the most frequently celebrated features across the reviews. Customers can have many aliases, and create a unique email address for different services, subscriptions and vendors. This was seen as transformative for many users; they were able to identify which companies sold their data, be able to isolate spam to a single disposable address, and maintain different accounts for personal and professional use — all from one location.

Across the reviews we read, custom domains and aliases came up repeatedly as the tipping point — the features that turned consideration into a decision to switch.

Speed and usability — “It is fast, clean and just works”

Our name isn’t a coincidence. Reviews across Trustpilot, Capterra, and Hacker News all describe the web interface as noticeably faster and lighter than Gmail’s. Add to this that there are no ads, our users have a clean, focused interface where the only thing competing for your attention is simply your actual email.

Open standards mean freedom

Our tech-savvy users value our commitment to open standards — IMAP, SMTP, CalDAV, CardDAV and now our very own JMAP protocol. We are also a major contributor to the open-source Cyrus IMAP project, providing a dedicated team of developers.

What this means for all our customers is that you are not locked in. You can use different email clients such as Apple Mail, Thunderbird, and Outlook. If you ever decide to leave, your data and your domain go with you. In short, your email works with virtually any app, and it belongs to you — not us.

Why does any of this matter?

We didn’t write these reviews. Our customers did — on open forums that we don’t control, in conversations we weren’t part of. The themes are consistent — people trust Fastmail because we are transparent about what we do, honest about what we don’t do, and focused on keeping their trust every single day.

Your email is personal. Your email is important. You deserve a provider that treats it that way.

Safer Internet Day: Why your search engine matters more than you think

2026-02-09T05:00:00Z

You chose Fastmail because you care about your privacy. You understand why independent providers matter. But there’s a crucial piece of the privacy puzzle that often gets overlooked: your search engine.

Every time you search the web, you share what you’re curious about, what problems you’re solving, what health symptoms you want to understand, what you’re shopping for, and what matters to you. For many of us, that search bar is the gateway to everything we do online. So why hand that data over to companies whose business model depends on tracking you?

The ‘search’ problem

Even with the most private browser, if you’re using a search engine that tracks you, you’re still handing over valuable data about your interests, location, and browsing patterns.

Traditional search engines make money by:

Tracking your search history to build detailed profiles
Following you across the web to see which results you click
Selling your data to advertisers who use it for targeted campaigns
Combining your search behavior with other services to create comprehensive profiles about you

It’s the same surveillance model we’ve been helping you escape by moving away from other commercial service providers.

Then there’s Kagi: Search that works for you

We’re excited to share that Fastmail has joined Kagi’s “Friends of Kagi” program — a collection of privacy-first companies that share our values and commitment to putting customers first.

Kagi (pronounced KAH-gee) is a paid search engine that delivers high-quality results without tracking, profiling, or advertising. Like Fastmail, they’re user-funded with no external shareholders pushing for data monetization.

What makes Kagi different?

No tracking: Kagi doesn’t track your searches, IP address, or browsing behavior. They don’t build profiles or share data with third parties.
Better results: Without the need to maximize ad clicks, Kagi focuses on giving you the best answer quickly. You can customize which sites you see more or less of.
Ad-free: No sponsored results competing with actual answers. Just the information you’re looking for.
Privacy by business model: Just like Fastmail, you pay for the service, and they work for you. No split loyalties.

Completing your privacy stack

If you’ve already switched to Fastmail and a private browser, adding Kagi creates a powerful privacy stack:

Private email (Fastmail): Protects your communications and blocks tracking pixels
Private browser (Vivaldi, Firefox, Brave, or Safari): Limits cookies, fingerprinting, and tracking
Private search (Kagi): Keeps your queries and interests confidential

How it works

Kagi is a search engine, not a browser. You can use Kagi with any browser you prefer. Simply set Kagi as your default search engine, and when you type a search into your browser’s address bar, it sends that search to Kagi — all without tracking you.

Ready to build your privacy stack?

Switch to Fastmail for private, ad-free email
Choose a privacy-focused browser
Change your default search to Kagi
Use browser extensions like Privacy Badger for additional protection

Final thoughts

Privacy isn’t about having something to hide — it’s about having the right to control your own information. By choosing Fastmail, a private browser, and now Kagi, you’re building a digital environment where you’re in control. Where companies serve you rather than the other way around. Where your data stays yours.

That’s the internet we believe in, and we’re proud to partner with companies like Kagi who share that vision.

Special offer for Fastmail customers

As part of our “Friends of Kagi” partnership, Fastmail customers will get the first 3 months free on the Kagi Professional plan using this link.

Being better with passwords

2026-02-01T19:00:00Z

February 1 is global Change Your Password Day. In the past, many companies would force users to change their password every month or so, even if there was no evidence of compromise. This was annoying, and did not generally make you more secure — mostly people would just reuse the same password they used everywhere with a different number on the end. Thankfully, this is no longer considered best practice. However, we thought it would still be a good day to reflect instead on what we should do.

How to be better with passwords

The number one thing you can do to improve your security online is to always use a different, random password each time you create a new account on the web. Not everyone has the same tight security as Fastmail, and you don’t want a hacker that gains access to your local library to now also have the password to your email and your bank!

But coming up with random passwords is hard, and memorising them even harder, which is why these days we strongly recommend you use a password manager to create and remember your passwords for you.

What is a password manager?

A password manager is a digital vault, similar to how the banks of yesteryear stored jewels and high-value items for their customers. The vault securely stores your passwords in an encrypted format that cannot be accessed by anyone but you. When required, it will create unique, complex passwords and auto-fill them across your various applications.

We like and use 1Password, which keeps your passwords securely in sync across all your devices and integrates with Fastmail’s Masked Email feature. However, there are other good alternatives too, and a built-in one in every browser these days — find one that works for you and use it!

As well as remembering your passwords for you, password managers help protect you against phishing by only auto-filling your password when you’re at the genuine website for the account.

The zero password future

Today’s password managers don’t just store passwords, they can also store something better — a passkey.

In 2024, Fastmail introduced passkey support to provide you with even greater online security. A passkey is a highly secure cryptographic key that works like a digital handshake between your password manager and the website you are logging in to. This ensures it’s definitely you logging in, and — just as importantly — definitely the real site you are logging in to! We wrote a great blog post if you want to learn why passkeys are better than passwords.

Online scams like phishing emails are increasingly hard to distinguish from legitimate messages. Scammers, or even AI agents, can now convincingly impersonate your trusted contacts and companies. As a result, even technically savvy individuals can unknowingly give away passwords. Passkeys provide the strongest protection against these threats.

How does Fastmail work with 1Password?

In 2021, Fastmail partnered with 1Password to bring Masked Emails to our customers. This lets you create a unique email address for each account you have online, keeping your real email address private. Working together, you can use Fastmail with 1Password to achieve the greatest protection online through private and secure email addresses and passwords every time you sign up to a new site.

For more information on how to use 1Password with Fastmail, you can read our help article here.

When many isn’t better than one: Managing your life with Fastmail and Morgen

2026-01-11T08:00:00Z

We all know that checking three different calendar apps before agreeing to coffee with a friend is simply not fun. Or realizing mid-dentist appointment that you’re also supposed to be on a work call. Or playing calendar Tetris across multiple screens just to figure out when you can squeeze in that thing you actually want to do.

We’ve all been sold the idea that more is better — more apps, more tools, more ways to “organise our lives.” But when it comes to calendars, more usually means chaos.

Here’s the truth: you don’t need multiple calendars. You only need one place to see them all.

The calendar multiplication problem

Calendars are a reality. There’s your work calendar (probably Outlook or Google, because that’s what IT chose). Your personal Fastmail calendar. The shared family calendar where someone keeps scheduling things without asking. Maybe a volunteer committee calendar. Oh, and that sports league schedule that lives in yet another app.

Your reality — managing five separate windows into your life, and none of them talk to each other.

The mental math alone is exhausting. “Okay, I’m free at 2 pm on Tuesday… wait, no, that’s just in my work calendar. Let me check my personal… and the family one… actually, can I get back to you?”

One view to rule them all

This is exactly why we partnered with Morgen. Because they get it: the problem isn’t that you have multiple calendars. The problem is looking at them separately.

Morgen lets you bring all your calendars together — your Fastmail calendar, your work calendar, even that random shared calendar from your book club — into one unified view. Suddenly, you’re not playing calendar detective anymore. You can actually see your life.

And here’s the best part: Morgen has the same values as Fastmail, and for this reason, treats your Fastmail calendar as a first-class citizen. No hacks, no workarounds, no “well, technically you could…”— just straightforward integration that actually works.

‘Time Blocking’: The adult version of planning your day

Remember when you used to plan out your day with a paper planner? Color-coding your classes, blocking out study time, actually having a sense of what you were doing when?

Time blocking is basically that, but for grown-ups with too many responsibilities.

The concept is simple: instead of letting your calendar fill up with whatever comes at you, you proactively block time for what matters. Focus work. Exercise. That project you keep saying you’ll get to. Time with actual humans you care about.

The problem? Time blocking only works if you can see your entire schedule. And that’s where most people give up — it’s too hard to coordinate across multiple calendars.

With Morgen and Fastmail, time blocking becomes ridiculously easy:

Drag tasks straight onto your calendar instead of maintaining a separate to-do list, you’ll never look at
See all your commitments at once so you know what time you actually have available
Block out focus time that appears across all your calendars, so people stop booking meetings during your deep work hours
Balance the work-life thing by actually seeing both work and life in the same place

It’s not revolutionary. It’s just finally… possible.

Your data, your rules

Here’s where it gets important: both Fastmail and Morgen are built on the simple idea that your data belongs to you. Not to advertisers. Not to data brokers. You.

When you connect your Fastmail account to Morgen, you’re using OAuth — which is tech-speak for “secure connection that respects your privacy.” You control what gets shared. Neither company will sell or distribute your data. Your calendar stays yours.

In a world where most “free” productivity apps are monetizing your every click, this actually matters.

Making it ridiculously simple

Here’s how the Fastmail-Morgen integration makes your life easier:

All your calendars in one place: Work, personal, shared — they all show up together so you can finally see what you’re working with
Smart scheduling: Morgen’s booking pages check your availability across all your calendars, eliminating the “wait, let me check my other calendar” dance
Tasks that become time: Stop maintaining a to-do list separately from your calendar - drag tasks onto your schedule and actually make them happen
Works everywhere: Mac, Windows, Linux, iOS, Android - your unified calendar view goes wherever you do

Getting started takes only minutes

Sign up and download Morgen
Connect your Fastmail account
Add any other calendars you’re juggling
Start actually seeing your whole life in one place

That’s it. No complex setup, no IT degree required — just a few clicks to get started.

The Real Bottom Line

More calendars don’t make you more organized. They make you more stressed.

What you need isn’t another app or another system, or another calendar. You need to see everything in one place so you can make actual decisions about your time.

That’s what Morgen and Fastmail deliver: one view of your entire life, tools that actually help you manage it, and zero compromise on privacy.

Because at the end of the day, managing your life better isn’t about having more tools. It’s about having one clear view of what matters.

Understanding email encryption

2025-12-17T00:00:01Z

Encrypted email sounds good, but what does it really mean? Email can be encrypted in many different ways, at different times, for different purposes. Each protects against different threats, and may have downsides to be weighed up. Understanding your options helps you make informed choices about your privacy and security.

What are you protecting against?

Before diving into encryption methods, it’s worth asking: what threats actually matter for your email? For most people, the realistic concerns are:

Account compromise: phishing or password reuse giving attackers access to your account
Mistaken spam detection: causing important mail to go missing
Malware: getting a virus via email, either linked or as an attachment
Accidental deletion: losing vital data due to human error

Far less common, although also important, are:

Network eavesdropping: someone on your WiFi or ISP intercepting your traffic
Data breaches: attackers gaining access to stored email through a security vulnerability
Physical theft: stolen devices or hard drives exposing your data

For a smaller number of people — journalists protecting sources, activists in hostile countries, or those facing sophisticated adversaries — the threat model expands to include insider threats at providers and legal compulsion by governments. Different encryption approaches help protect (or may even hinder protection) against subsets of these threats, and understanding this helps you choose the right balance.

Encrypting the connection to your email provider

Whenever you connect to your email provider, TLS (Transport Layer Security) encrypts everything between your device and the server. This protects you from eavesdroppers on your local WiFi network, your ISP, and anyone monitoring network traffic between you and your email service. This standard has been widely adopted and modernised, the latest version being TLS 1.3, which mandates the strongest ciphers and is the foundation of today’s secure internet.

But encryption alone isn’t enough. You also need assurance you’re actually talking to your email provider and not an imposter. This is where Public Key Infrastructure (PKI) comes in. When you connect to Fastmail or Gmail, the server presents a certificate that’s been digitally signed by a trusted Certificate Authority (CA) like Let’s Encrypt. Your browser or email client checks this signature against its built-in list of trusted CAs, verifying that the certificate was legitimately issued to that domain. This prevents attackers from intercepting your connection by pretending to be your email provider — even if they can redirect your traffic, they can’t obtain a valid certificate for a domain they don’t control.

The system was strengthened significantly with the introduction of Certificate Transparency (CT) logs: public, append-only records of every certificate issued by participating CAs. Domain owners can monitor these logs to detect if someone fraudulently obtains a certificate for their domain, and browsers now require certificates to be logged before trusting them. While no system is perfect — CAs have occasionally been compromised or tricked into issuing bad certificates — PKI combined with Certificate Transparency provides strong, practical assurance that your encrypted connection terminates at the server you intended to reach.

Fastmail fully supports the latest TLS 1.3 standard. We also use HTTP Strict Transport Security (HSTS) to ensure browsers never try connecting to us without TLS. Similarly, we ensure the ports for unencrypted IMAP/POP/SMTP are closed on our servers, so email apps do not try to connect without encryption (this is why we have always preferred “implicit” TLS over STARTTLS, which is also now the recommendation of the IETF).

Encrypting email between servers

When you send an email, it first goes to your email provider’s server, and then they send it on to the recipient’s email server. The more interesting challenge lies in that transit between different servers.

Server-to-server encryption relies on “opportunistic TLS”, meaning servers attempt encryption but fall back to unencrypted delivery if the receiving server doesn’t support it. Fastmail has supported this for inbound mail since April 2009 and for outbound mail since January 2010.

The fundamental limitation is that opportunistic TLS can be defeated by active attackers, commonly referred to as a man-in-the-middle (MITM) attack. A sophisticated adversary positioned between mail servers can strip the STARTTLS command from the initial handshake, forcing an unencrypted connection. There is still enough legitimate mail sent to, or received from, servers that don’t support encryption that mandating it for everyone would lose an unacceptable amount of wanted email.

Additionally, servers don’t verify certificates by default. They accept any valid-looking certificate without confirming it actually belongs to the destination server. This is because verifying the certificate adds no security when an active attacker could just fall back to an unencrypted connection.

MTA-STS and DANE attempt to close the gaps

Two protocols address these vulnerabilities, though adoption remains limited.

MTA-STS (Mail Transfer Agent Strict Transport Security) lets domains declare they support and require STARTTLS encrypted connections, including a valid certificate, when receiving email for addresses at that domain. Senders can check this policy and must refuse to send mail if they are unable to establish an encrypted connection with a valid certificate for the receiving domain.

MTA-STS is reasonably straightforward to deploy: it requires only a DNS record and a policy file hosted over HTTPS. If something goes wrong, the worst case is that some incoming mail gets delayed or bounced — it cannot affect websites or other uses of the domain.

DANE (DNS-Based Authentication of Named Entities) takes a different approach, publishing TLS certificate information directly in cryptographically-signed DNS records via DNSSEC. This eliminates dependence on certificate authorities and the “trust on first use” weakness of MTA-STS — but at significant operational cost.

DNSSEC is not supported by all domains (it depends on the registry for the top-level domain). More importantly, DNSSEC’s deployment complexity significantly increases the likelihood of a serious outage. Unlike most system failures, DNSSEC errors are uniquely unforgiving: when there’s a routing problem, you fix it and service is restored immediately, but when there’s a DNSSEC problem, broken records can persist in caches across the internet for hours or days.

Even sophisticated operators get this wrong. In October 2023, Cloudflare’s 1.1.1.1 resolver — one of the world’s most popular DNS services — experienced hours of failures when DNSSEC signatures in their cached root zone expired. In May 2023, New Zealand’s .nz country-code TLD triggered a multi-day availability incident during a routine DNSSEC key rollover. There is a long history of similar outages.

At Fastmail we know security is not just about confidentiality (no one else can read your email). Availability (you can read your email) and integrity (your email cannot be corrupted or modified by others) are just as important. For this reason, we don’t currently consider the confidentiality benefits of DANE over MTA-STS to be worth the trade-off against increased availability risk. Other major providers such as Google and Yahoo have made similar choices, favouring MTA-STS over DANE. However, we regularly re-evaluate our position on this as the global ecosystem evolves.

For most users, the practical upshot is that email traveling between major providers is almost certainly encrypted in transit. Sophisticated nation-state attackers who can manipulate network traffic may be able to downgrade connections to intercept mail in the absence of DANE or MTA-STS. However, doing so at scale would almost certainly be noticed, and targeting specific individuals is very difficult in high-volume mail flows between major providers.

Encrypting email at rest

Once email reaches a server, encryption at rest protects it while stored on disk. This typically means full-disk encryption using technologies like BitLocker, LUKS, or ZFS dataset encryption, using keys held by the email provider.

This architecture protects against specific threats. If someone physically steals a hard drive from a data center, or if decommissioned drives aren’t properly wiped, the data remains unreadable. Encryption at rest defends against physical data center breaches and helps meet compliance requirements for regulations like GDPR and HIPAA.

As the email service holds the keys, legal requests backed by valid court orders can compel providers to decrypt and hand over data. And if attackers gain full control of a server, encryption at rest provides no protection because the keys are already loaded.

Fastmail stores all user data on encrypted disk volumes, including backups, with encryption keys retained solely under our control. We maintain strict access controls with comprehensive logging and auditing. Our transparency report details the number of legal requests we receive and respond to each year.

The trade-offs of zero-access encryption

Services like Proton Mail and Tuta offer zero-access encryption, where encryption keys are derived from your password on your device, meaning even the provider cannot decrypt your stored email. When you log in, your password decrypts the key locally; the server never sees it.

For users whose threat model prioritises protection against insider threats or government compulsion — and who are willing to accept significant trade-offs in functionality — zero-access encryption is a legitimate choice. It can provide real protection against insider attacks, data breaches, and limit the data handed over in response to court orders. However, it’s important to understand both what it protects against and what it doesn’t, as the additional protections of zero-access encryption are limited in ways that are sometimes understated:

New mail can still be intercepted. Unless the email is end-to-end encrypted (see the next section), the provider will have access to the unencrypted version before encrypting it with the user’s public key. An interception court order or rogue employee could still take a copy at this point.
Not all data is encrypted. Email addresses, timestamps, and in Proton Mail’s case, subject lines, stay unencrypted. Who you’re talking to, when, how often, and the summary of what it’s about is often more important than the contents of the email itself.
Only protects against read-only server compromise. Most people access their email through the browser. The code that decrypts the email is therefore loaded on demand from the provider’s server — if the server is compromised, the code can be modified to capture your password. Law enforcement may also be able to compel this change for specific users subject to a court order.
An unencrypted copy exists elsewhere. Even if your copy is encrypted, the senders likely retain a fully readable copy of every message you receive.

Zero-access encryption also has significant trade-offs in functionality:

Password loss means data loss. Forget your password without a recovery phrase, and your email is gone forever. There’s no “reset password” in the traditional sense. Many years of experience have taught us that people forget or lose their password all the time. Even sophisticated users who swear it would never happen to them have found themselves locked out. Password reset flows can be a weak point in securing an account, but at Fastmail we have a very carefully considered automated system for secure account recovery.
Search capabilities are constrained. Encrypted content cannot be seen or indexed on servers. Client-side search indexes are possible, but require downloading all mail to every device — often impractical for large accounts with tens of gigabytes of mail.
Standard email clients don’t work. Zero-access encryption prevents the provider directly offering standard IMAP or JMAP protocols. This also makes migrating to another provider difficult — it’s the ultimate vendor lock-in.
Customer support is limited. Because the provider cannot access your mail even with your permission, many issues become impossible to help with. Business features like shared mailboxes and compliance tools are often unavailable.

End-to-end encrypted email

True end-to-end encryption, where only the sender and recipient can read the message, has existed for email since the 1990s through S/MIME and OpenPGP. Yet neither has achieved meaningful consumer adoption despite decades of availability.

S/MIME uses certificates from Certificate Authorities and is supported by some enterprise email clients. It has some traction in organisations with existing PKI infrastructure where you can find a recipient’s public key in an internal corporate directory, but is rarely used outside of this.

OpenPGP uses a decentralized “Web of Trust” where users vouch for each other’s keys. The Web of Trust is practically dead according to security researchers, and PGP suffers from a myriad of design problems: it leaks metadata, is not forward secure, and lacks practical key rotation. The seminal 1999 study “Why Johnny Can’t Encrypt” found that only 4 of 12 participants could properly encrypt email with PGP within 90 minutes. Follow-up studies in 2006 and 2019 found users still struggling with “finding and verifying other people’s public encryption keys.” Even PGP inventor Phil Zimmermann had difficulty decrypting an email in 2015 due to version incompatibility.

A fundamental challenge for any end-to-end system is key distribution and rotation. To send an end-to-end encrypted message to someone, you first need to obtain their public key (and be absolutely sure it’s theirs!). There is no infrastructure for doing this at the moment, let alone for rotating keys regularly in accordance with cryptographic best practice. Without key rotation, a compromised key or password means all previously intercepted email can be decrypted.

Contrast all this with Signal or WhatsApp, where encryption works automatically because a single organisation controls the full software stack rather than using open protocols. They generate keys automatically when you install the app, discover contacts through phone numbers, and update security protocols universally. Email’s federated architecture — where any client can talk to any server — makes this unified approach impossible.

End-to-end encryption also fundamentally conflicts with features email users depend on. Server-side search becomes impossible when the server can’t read content — even just keeping a searchable archive of all your messages is antithetical to security best practice. Phishing detection and malware prevention (two of the biggest security risks!) require inspecting messages. Multi-device access requires synchronising private keys across devices — a security risk. And crucially, email headers including To, From, and Date cannot be encrypted without breaking email’s basic functionality.

As cryptographer Bruce Schneier concluded: “The things we want out of e-mail, and an e-mail system, are not readily compatible with encryption.”

The necessary trade-off between privacy and security

There’s an inherent tension between strong privacy protections and the ability to combat abuse. Spam filters, phishing detection, and malware scanning all require reading email content, or at least work more effectively when they can. A provider that truly cannot see your messages cannot protect you as effectively from threats within them.

This creates real consequences. With server-side content inspection, providers can identify phishing attempts by analysing links and sender patterns. They can quarantine malware before it reaches your inbox. They can detect account compromise by recognising unusual behaviour patterns. These protective capabilities are reduced or eliminated with end-to-end encryption.

Choosing your own balance

Email security isn’t binary — it’s a spectrum of trade-offs. Transport encryption (TLS) is now universal and protects against passive surveillance. Encryption at rest guards against physical theft. Zero-access encryption limits insider access but sacrifices functionality. True end-to-end encryption provides the strongest content protection but remains impractical for most users and has significant usability and security issues of its own.

For highly sensitive communications, dedicated messaging apps like Signal offer much stronger guarantees than any email solution can provide. For everyday email, transport encryption combined with encryption at rest provides meaningful protection against the most likely threats while preserving the searchability, spam filtering, and convenience that make email useful.

Here’s the honest truth: if you are a journalist trying to protect a source, or face nation-state adversaries, you probably shouldn’t use email — use an encrypted messaging app instead. But for the vast majority of communications, modern email security offers substantial protection while maintaining the features that make email indispensable.

Fastmail’s ongoing approach to email and encryption

Fastmail has been doing email for over 25 years. We know that email is your electronic memory and keeping your messages accessible, private and secure are our top priorities. We keep your emails private and secure with encryption in transit and on our servers, strong authentication options, and innnovative features like Masked Email. We keep your email accessible by concentrating on rock-solid reliability, with full multi-data center redundancy, and a lightning-fast interface with powerful search, capable of handling decades of mail with ease. We regularly evaluate the tradeoffs required to provide the best overall user experience and privacy possible taking into account all the technical and practical options available.

Introducing the Fastmail desktop app

2025-10-13T00:00:01Z

Fastmail is now available as a dedicated desktop app for Mac, Windows, and Linux. It’s the same Fastmail you know and love, now with the focus and convenience of a standalone app.

With our desktop app you can:

Launch Fastmail from your dock or taskbar and find it in your platform’s app switcher.
Make Fastmail your default email client, so email links create a new message directly in Fastmail.
Work whenever, wherever, with full offline support, just like our mobile apps. You can always read your mail, manage your calendar, and write replies — your changes sync back seamlessly when you reconnect.

Whether you’re on macOS, Windows, or your favourite Linux distribution, you’ll find the app feels right at home on your platform, with native notifications, menus, and system integrations.

Getting started is simple. Download the app for your platform, sign in with your Fastmail credentials, and you’re ready to go.

This blog post was not written with AI

2025-10-02T00:00:01Z

It’s all the rage right now. Everyone is scrambling to put AI into their products. The uncanny valley is shrinking enough that it’s hard to see how much AI was used to write something.

This isn’t entirely new, auto-complete on my phone already suggests the most likely word when I’m typing. AI writing tools are an extension of this, but they’re also much more capable.

Your electronic memory

I stand by one of the most important truths about email. It’s not only the largest and most diverse social network, email is your electronic memory.

In the novel 1984, the “Ministry of Truth” has a whole massive department which rewrites history. In a world where there’s enough AI capability to process the entire web and rewrite every page to remove something, the cost of “changing history” is much reduced, so we can expect more of it.

This is where the immutability of email really shines. An email is your copy, and the sender can’t revise it later. This is frustrating when you’ve sent the wrong thing and have to send a separate correction later, but in the long term it’s insanely valuable.

It makes a huge difference to be able to go back and double-check your memory against an email you saw years ago and know that if they disagree, the email is correct. This is already not the case with web pages — they change, and it’s only becoming worse.

Adapting to a changing world

My son is studying at University now, and he’s one of a few students in his class who refuses to use AI to write his assignments. As he said “what’s the point of paying to be here if I’m not going to build the knowledge and skills for myself, and come out knowing how to do the thing” (near enough… I didn’t write the exact words down in an email, so I’m going off my own fallible memory!) I am so proud of him for having that attitude.

I’m also pleased to see that Fastmail’s staff, and many of our customers, are wary of AI tools.

But they are that, tools. The world is changing, and we need to adapt and understand it.

Our service, your data

For our service, we want you to be able to do what you desire with your own email, calendars, and contacts. We will continue to build tools and integrations to make that easier.

You are welcome to operate your Fastmail account with AI tools, so long as that usage doesn’t otherwise breach our Terms of Service, or degrade the performance of our systems for other customers.

Our staff, your privacy

For our staff, we encourage understanding the tools that exist in the world, and how to use them safely. Our policy makes it clear that any use of tools, including tools with AI in them, must follow clear privacy-preserving principles:

Data Protection: All data protection, confidentiality, and privacy policies must be followed (our vendors for things like anti-abuse and support are moving towards using AI for translation, categorization, abuse detection – and we are ensuring that their policies continue to provide protection for our customers)
Accountability for work: Any AI generated writing or code must be reviewed and understood by a human being, and go through our regular second-set-of-eyes processes before being used
Bias awareness: Actively look for biases or hallucinations in AI output
Human authority: Always have a path for appeal to a human from any decision that is made by automated tools

The future

Who knows what the future will bring, but we continue to be guided by the principles that we first publicly articulated in 2016 and have held even longer. The data is yours, and we will be good stewards and good internet citizens, helping enable you to use your data in the ways you choose.

The Cache Crash

2025-09-17T00:00:01Z

Software Freedom Day is this week, and we thought we’d mark the occasion with a post about some of our work on open source software that we maintain. Fastmail believes in being a good internet citizen, and that belief means we participate in the development of free software, both by sharing software that we write and by contributing to the maintenance of free software that we use.

This is a highly technical post about how we solved a crash in our automated test systems. You do not need to make any changes to your Fastmail account or your email software, and you can ignore this post if it’s not interesting to you!

What happens when a mysterious bug causes all your tests to fail once or twice a week? We try to solve these mysteries, even if it takes a year.

At Fastmail we have a strong testing culture around our code. When we write a new feature or fix a bug, we include tests to show that our feature works or the bug has actually been fixed. We open a Merge Request, and GitLab CI kicks off a job to run the project’s full test suite. We also have a scheduled job that runs once a day, testing our mainline branch. This checks that the tests haven’t started failing because of changes to the outside world.

The job stands up a virtual machine, installs all of the necessary software, updates configurations, starts the various services that make up Fastmail, and then runs all of the tests. Finally, it shuts down the box and generates some downloadable artifacts with the test results. There are quite a few tests. All told, this process takes about 13 minutes. As a developer, you’re hoping to see this:

File Count: 441
Assertion Count: 22040
    -->  Result: PASSED  <--

Starting some time in early 2023, we’d occasionally have jobs fail in strange ways. We didn’t see failures around the features we were changing. Instead, we’d see a bunch of random tests would fail with the error “Signal: 6” and “Signal: 11”:

( STDERR )  job 364    free(): invalid size
< REASON >  job 364    Test script returned error (Signal: 6)
< REASON >  job 364    No plan was declared, and no assertions were made.
< REASON >  job 369    Test script returned error (Signal: 11)
< REASON >  job 369    No plan was declared, and no assertions were made.
< REASON >  job 373    Test script returned error (Signal: 11)
< REASON >  job 373    No plan was declared, and no assertions were made.

That means one process got a SIGABRT and then after that a bunch of processes got SIGSEGV. Something, somewhere, was going wrong with the software’s use of memory. “Use of memory”, though, covers a lot of what any given program is doing.

At the time, our test runs didn’t have much logging, so we couldn’t really tell what was going on, and we couldn’t easily reproduce the problem. On any given run, either it happened or it didn’t. For a while, I just assumed our VMs were occasionally dodgy somehow. The problem was rare, so we tried to ignore it and just click “Re-run job” as needed.

Soon though, it began to happen more frequently.

I added logging to our builds, and I made sure that the job’s build artifacts would always contain all the logs. With this evidence in hand, we began to see a pattern:

t1[43556]: segfault at 8 ip 00007fca57fde1ee sp 00007ffdeab5ef00
  error 4 in FastMmap.so[7fca57fda000+6000] likely on CPU 2 (core 2, socket 0)
t3[43580]: segfault at 8 ip 00007fca57fde1ee sp 00007ffdeab5ef00
t9[43685]: segfault at 8 ip 00007fca57fde1ee sp 00007ffdeab5ef00
  error 4 in FastMmap.so[7fca57fda000+6000] likely on CPU 3 (core 3, socket 0)

The crash was always in FastMmap.so! This comes from Cache::FastMmap, a Perl module of ours that provides an mmap-backed cache for use across processes.

Armed with this information, I modified our builds to collect the on-disk cache files, too. With those, I’d be able to examine what was in the cache when a crash happened. Unfortunately, the cache files were corrupt, leaving me with more questions than answers.

Over the course of months, I started taking a day here and there to dig through this problem – poring over the Cache::FastMmap code, our available logs, and our reproductions using the captured files. I tested and tossed out a lot of theories.

Eventually, I added the ability to capture the core files generated during the test runs, because I realized that when this problem triggered, there was always a SIGABRT first with the error message seen below, which previously I hadn’t thought of as significant:

( STDERR )  job 364    free(): invalid size
< REASON >  job 364    Test script returned error (Signal: 6)

It seemed pretty clear that the first crash was corrupting the file, and all of the processes using the cache file after were crashing because of that.

So after adding the core file collector, I sat there clicking “Run job” on my merge request over and over and over and over and over, trying to trigger a crash.

Eventually, it worked… but unfortunately I had no debugging symbols in the core files, so it didn’t help. I modified the build again, including those, and then clicked “Run job” a bunch more.

Finally, I got what I needed, but this was even more confounding. The stack trace showed that the crash happened here:

#3  0x00007f8c429d6195 in mmc_do_expunge (cache=cache@entry=0x56113b842070,
    num_expunge=<optimized out>,
    new_num_slots=<optimized out>,
    to_expunge=0x56113b506210) at mmap_cache.c:800
800	  free(to_expunge);

to_expunge was a valid pointer, and nothing else had freed it yet from what I could tell by looking at the source.

This told me that most likely we were writing over memory somewhere where we shouldn’t be, and we were stomping on malloc’s internal structures. Unfortunately, these kind of bugs are really hard to track down unless you can catch them in the act using tools like Valgrind or AddressSanitizer.

I tried various things from there, including modifying the build to output every action taken against the cache file. The logs included a high-resolution timestamps, the action that was taken (fetch, store, delete), and whether it resulted in success or not.

I replayed these recordings (single threaded - not a perfect test since it didn’t imitate inter-process locking or coordinating) with Valgrind and AddressSanitizer, but I got nowhere.

I stared at the code, thought for a while longer, and then did some web searching for the “free(): invalid size” error to see if that could maybe help me pinpoint where a bad write was happening.

That led me to a post on StackOverflow that pointed toward negative indexing. After reading that, I tried a few experimental programs until I reproduced the abort:

#include <stdlib.h>

void main(void) {
  int **x = (int**)calloc(5, sizeof(int*));
  int **y = (int**)calloc(5, sizeof(int*));
  int **z = x;
  int *num = malloc(sizeof(int));
  *--z = (int *)&num;
  free(y);
  free(x);
}

$ gcc negative-array-index.c
$ ./a.out
free(): invalid size
Aborted (core dumped)

Could it be that we were underflowing an array? That is, were we accidentally writing to memory below the lower bound of an array we’d allocated? With this theory in mind, I looked through the Cache::FastMmap source to find where we might be underflowing an array, and I spotted this loop in mmc_calc_expunge():

MU32 ** copy_base_det = (MU32 **)calloc(used_slots, sizeof(MU32 *));
MU32 ** copy_base_det_in = copy_base_det + used_slots

//[... more code ...]

/* Loop for each existing slot, and store in a list */
for (; slot_ptr != slot_end; slot_ptr++) {
  MU32 data_offset = *slot_ptr;
  MU32 * base_det = S_Ptr(cache->p_base, data_offset);
  MU32 expire_on, kvlen;

  /* Ignore if if free slot */
  if (data_offset <= 1) {
    continue;
  }

  /* Definitely out if mode == 1 which means expunge all */
  if (mode == 1) {
    *copy_base_det_out++ = base_det;
    continue;
  }

  /* Definitely out if expired, and not dirty */
  expire_on = S_ExpireOn(base_det);
  if (expire_on && now >= expire_on) {
    *copy_base_det_out++ = base_det;
    continue;
  }

  /* Track used space */
  kvlen = S_SlotLen(base_det);
  ROUNDLEN(kvlen);
  ASSERT(kvlen <= page_data_size);
  used_data += kvlen;
  ASSERT(used_data <= page_data_size);

  /* Potentially in */
  *--copy_base_det_in = base_det;
}

This code allocates a new region of memory based on how many used slots we have (used_slots) and takes a pointer to the end of that region of memory:

MU32 ** copy_base_det = (MU32 **)calloc(used_slots, sizeof(MU32 *));
MU32 ** copy_base_det_in = copy_base_det + used_slots;

Then, we loop over every slot in the cache, looking for ones that have data…

for (; slot_ptr != slot_end; slot_ptr++) {
  MU32 data_offset = *slot_ptr;
  MU32 * base_det = S_Ptr(cache->p_base, data_offset);

…skipping ones that don’t…

  /* Ignore if if free slot */
  if (data_offset <= 1) {
    continue;
  }

…and finally copying over ones that do have data to the new region of memory, starting at the end of the memory region and working towards the front:

  *--copy_base_det_in = base_det;

(Later, copy_base_det ends up in to_expunge seen above.)

In order for this loop to underflow, the cache would have to have more slots with data in them than used_slots accounts for.

The only way I could see this happening was if two processes wrote to the cache at the same time, corrupting its accounting. That, though, would mean locking had failed somehow…

To chase that down, I modified the build to log when a lock was acquired, when a write happened, and when the lock was released. I clicked “Run job” wildly, like I was playing the world’s worst Cookie Clicker game… and eventually I got another hit.

This time, there was a smoking gun:

1739384152.734390 [32464] locked page 3: p_offset: 786432 pns: 179 pfs: 115 size: 262144
1739384152.737327 [32928] locked page 3: p_offset: 786432 pns: 179 pfs: 115 size: 262144
1739384152.738589 [32928] unlocked page 3 (with changes): pns: 179 pfs: 114
1739384152.738776 [32464] unlocked page 3 (with changes): pns: 179 pfs: 115

Here, pns is the number of slots, and pfs is the number of free slots.

Above, we see that process 32464 locked the cache, and then before 32464 could write to the cache, process 32928 also locked the cache! That’s supposed to be impossible! Then, the second process wrote an entry to the cache, using up another slot, so it decremented the free slot count. And then, the first process wrote out its changes. Those didn’t include the use of any new slots, and so it set the free slot count back up to 115!

This is what caused mmc_calc_expunge to underflow – it allocated memory for 64 slots (179 total slots minus 115 free slots) but ended up seeing 65 slots with data that it needed to copy over!

Using the available logs on the machine, I identified the two processes, and found that one of them was a test that I had long suspected was the culprit.

That test uses IO::Async::Process to fork a child, then run some Perl code in that child. It turns out that IO::Async::Process closes all file descriptors except STDIN, STDOUT, and STDERR when forking. This is a surprising thing to do when forking – often a parent might intentionally leave file descriptors open for a child to continue using.

A file descriptor is just a number representing an open file or socket (like a network connection).

When Cache::FastMmap first starts up, it opens the cache file for reading/writing:

int fh = open(cache->share_file, O_RDWR);
if (fh == -1) {
  return _mmc_set_error(cache, errno, "Open of share file %s failed", cache->share_file);
}
cache->fh = fh;

It then maps that file into memory:

cache->mm_var = mmap(0, cache->c_size, PROT_READ | PROT_WRITE, MAP_SHARED, cache->fh, 0);

Later, when it needs to write out changes to a specific page in the cache, it locks that region of mapped memory by locking specific ranges of bytes within the file using the file descriptor number:

/* Setup fcntl locking structure */
lock.l_type = F_WRLCK;
lock.l_whence = SEEK_SET;
lock.l_start = p_offset;
lock.l_len = cache->c_page_size;

/* Lock the page (block till done, signal, or timeout) */
lock_res = fcntl(cache->fh, F_SETLKW, &lock);

If another process using Cache::FastMmap with the same file tries to write changes, it will block trying to get the same lock until the current process is finished and unlocks the file.

However, when IO::Async::Process closes all open file descriptors, cache->fh becomes invalid, since that number no longer belongs to any open file or socket. Then, later, if the child process opens up any new files or sockets, that number could be reused(!), so when Cache::FastMmap attempts to lock the cache in the child, it succeeds, but locks the wrong file!

The memory mapped region is not tied to the file descriptor after having been mapped, so any changes written to memory would still overwrite the cache data, and stomp on whatever work any other process is doing at the same time.

We fixed all this by ditching the “fork and run more Perl in the child” and replacing it with “fork and exec a brand new process”. With exec, we replace our running program entirely, so we no longer have the mmaped regions available. We’ve been segfault free ever since! We also added code to a new open source release of Cache::FastMmap, to try to prevent anybody else from going through all this.

What’s really frustrating about this is that I almost cracked it months ago. I had suspected that the fork-and-close-children behaviour of IO::Async::Process was the problem, but when I tested some code manually to trigger the bug, I always got “invalid file descriptor” in the children during locking of the mmaped region… because my tests weren’t opening up new file descriptors. The lock file descriptor wasn’t valid and so the mmaped region couldn’t be be written over.

Alas.

Work offline with Fastmail

2025-08-26T00:00:01Z

The internet is available in more places every day, from subways to aeroplanes. But it’s still not universal, and it always seems to disappear at the most inopportune time. The overwhelmed mobile network cuts out just when you need that concert ticket. You realise you don’t have the address of your hotel just after landing in a country with no roaming agreement.

Today, we’re pleased to announce full offline support for all our customers, in our apps and even on the web. No internet? No problem.

How do I turn on offline support?

We’ll be automatically enabling offline support for users of our iOS and Android apps progressively over the coming weeks. But if you can’t wait, or want offline support in your web browser, you can turn it on in Settings → Offline.

Depending on the size of your account and the speed of your internet connection, it can take a few minutes or sometimes longer to do the initial sync. To allow the syncing to occur just leave the tab open in the browser (even in the background) until it shows it’s ready. Due to background processing restrictions on mobile platforms, our app can only do this initial sync while running in the foreground, but you can keep using it as normal while this is happening.

By default, we’ll download the contents of recent messages, plus messages you open on your device. You can change this to all messages in the settings. Attachments are only cached for offline use when opened on the device.

A few things to note if you want to enable offline support in your web browser:

You must tick “Keep me logged in” when logging in to be able to turn on offline support.
Offline support requires a modern browser — if you’re running something we can’t support, you’ll see a banner telling you this on the settings page.
Remember to bookmark your inbox to make it easy to get to. If you usually use a search engine to get to Fastmail, this won’t work without internet. A bookmark lets you open Fastmail’s webmail directly, which will load even when offline.

What if I don’t want offline support?

You can turn it off at any time in Settings → Offline. Turning it off will delete the local mail cache, so you will have to download it again if you change your mind.

Is there anything I can’t do offline?

We wanted to make the online-offline transition seamless, so you mostly shouldn’t need to think about it. Almost everything you can do online you can do offline, such as reading mail, replying, viewing and editing your contacts or calendar, and changing most settings. As soon as you’re online again, it will all sync back to the server.

There are however a few minor differences to be aware of when working offline:

Mail search will not look inside attachments, and will give slightly different results to when online. And of course if you don’t choose to make every message available offline, it won’t be able to match against content it hasn’t downloaded!
Snoozed messages will not move back to the inbox while offline.
Calendar reminders will not show a notification while offline.
You can’t delete attachments from a message you’ve received.
You can’t add or change users or domains, change your plan or update your billing details, or change your security settings.

What’s the tech behind your offline support?

Interested in how we made this all work? We wrote up the technical details of the general architecture, how we sync changes back to the server, and how we made offline email fast when we launched the public beta late last year.

Fastmail remains at the cutting edge of web development, with one of the fastest and most sophisticated apps anywhere on the internet. We’re super proud of this huge step forward in functionality, and our biggest hope is you almost don’t notice it — Fastmail now just works wherever you need it to.

The new phishing: How to spot email scams in 2025

2025-08-17T12:00:00Z

Your inbox is the key to almost everything you do online. No wonder scammers keep showing up

Think about it: your inbox is where your personal and professional worlds collide, from two-factor authentication codes, to delivery notifications, to medical prescriptions. It’s an archive of ancient calendar invitations and messages from your ex in 2008.

That’s why email is the perfect attack vector for scams. It only takes a few minutes, a free email account, and a list of scraped or purchased email addresses to get malicious messages into thousands of inboxes. And those messages are getting smarter every day.

At SaneBox, we filter millions of emails daily. We’ve seen it all: the suspicious invoices, near-perfect Apple login alerts, mysterious princes earnestly trying to transfer you billions of dollars…and we’ve noticed a worrying trend. Today’s phishing scams are getting smarter, more personalized, and much harder to spot.

Here’s how to recognize the smartest email scams and stay ahead.

Today’s scams don’t always look like scams

It used to be easy to spot scams. If the typos didn’t give it away, the message beginning “Dear Esteemed Beneficiary” surely did.

But phishing today has credible language. It’s not just your mom you need to worry about, even the most skeptical, and perennially online, people can be fooled. In fact, millennials are more likely to be victims than their Gen X counterparts!

Phishing emails use AI to generate convincing replies in any language or tone, and they are perfecting the dark art of “brand mimicry” to pose as legit companies. Scammers are playing the long game, too. They might not immediately present you with a suspicious form, or ask for your credit card details. They want to gather just enough breadcrumbs — your employer, your role, maybe some personal intel — to make their next attack even more believable, or to impersonate you. Some email scams you’d never see coming, like impersonating Lady Gaga to buy your painting!

Why even tech-savvy users fall for scams

Don’t feel bad if you can’t spot anything wrong with this email. Other than the spacing and address, it’s almost a complete replica of a legitimate email. Here’s why these emails work so well:

1. They hijack our trust

Well-loved companies like Facebook, Apple, and Spotify spend years conditioning us to associate their logo, colors, and tone with a warm fuzzy feeling of trust. They’ve done such an incredible job that our favorite brands light up our brains with the same emotional force as our families and partners! Your guard is down, and you’re more likely to click.

2. They exploit urgency and FOMO

“You’ve been tagged in a document.” “Your subscription failed.” These messages use social engineering to stir up anxiety. When we see something urgent and immediately actionable, like verifying a transaction or confirming that a login wasn’t us, our brains are seeking out the dopamine rush of completing a task. Except the task we just rushed to complete was clicking on a scam.

3. We’re experiencing cognitive overload

We’re skimming our emails, juggling tabs, and looking for quick wins in our inbox. Cognitive overload makes us more impulsive, and the urge to “just handle it” is exactly what phishers exploit. As long as we have a noisy inbox, we’ll be vulnerable to scams.

SaneBox Tip: Our SaneLater filter ensures only important emails go to your inbox. This reduces overwhelm, so you’re less likely to make hasty decisions and fall for a scam.

Email scam red flags to watch for in 2025

Subtle Domain Spoofing: Lookalike domains — think subtle changes like saneb0x.com, spot1fy.com — helped create $12.5B of losses from impersonation scams in 2024. Hover before you click. Watch for homograph attacks, too — which use the visual similarity of characters in different scripts to create URLs that look almost identical to ones you trust.

Sneaky attachments: “Invoice754332_PDF.exe for your recent service” uses a classic trick to make us believe we’re opening a PDF. At first glimpse, it looks like a regular invoice but it’s actually an executable file that can run malicious code on your machine. We’re conditioned to open attachments that reference money; don’t fall for it.

Vague personalization: “Quick question about {Your Employer} last payment.” Scammers use just enough detail to make a message sound legitimate, without proving they know who you are. Do not feed them more intel, no matter how minor it seems. Even something as simple as “I no longer work there,” or “is this meant for Brenda’s team?” gives scammers ammo for future scams.

SaneBox Tip: If it seems suspicious, drag the message to the BlackHole and you’ll never hear from that sender again.

Suspicious Timing: A request to update your credit card information on Christmas Day? A Friday night invoice demanding payment before the weekend? Phishing scams are often timed to strike when you’re distracted (or tipsy!) and less likely to scrutinize them. If the timing primes you to act with urgency, all the more reason to slow down.

Your email scam defense stack: SaneBox + Fastmail

Fighting against email phishing isn’t just about vigilance, it’s about stacking the right tools so you don’t have to battle alone.

Fastmail:

All data is encrypted to the highest level
Strict Transport Security header protecting all modern browsers against SSL stripping
Regular internal security audits

SaneBox:

AI filtering that’s based on your actual behavior
One-click unsubscribe to banish senders to the BlackHole
No ads, no tracking — ever

Dmitri Leonov is the CEO of SaneBox, an AI-powered email tool that helps people save time and stay focused. He has over 20 years of experience growing startups, leading strategy, and building high-performing teams.

Better themes, better navigation, better search

2025-08-05T00:00:01Z

Today we released another significant update to the Fastmail web and mobile apps, introducing more beautiful theming and faster navigation on desktop, plus a powerful new search tool to help you find the email you’re looking for.

Beautiful new themes

We’ve revised the Fastmail UI to make it more balanced, more focused, and pull in more color from your theme. Head over to the settings and you’ll find many beautiful new default themes to choose from, or make it personal with custom colors.

The tab bar in our mobile app has allowed switching between your mail, calendar, and other apps in just one tap for years. Now, webmail gets quick app switching too. Just like on mobile you can choose which apps to show in the settings, or turn them all off to hide the navigation bar entirely.

For our customers with multiple accounts, it’s now much faster to move between them with our new quick user switching in the top right. Log in to more than one account in our mobile app and you’ll see the quick user switcher appear there too.

Finally, our calendar on desktop now has faster navigation between day/week/month view. Want something more unusual? Click on the selected tab again to customise the number of days/weeks on show.

Fine-tune your search

Our new search refinement toolbar lets you quickly add, remove, or change filters to narrow down your search.

We already have intelligent autocomplete to start you off, but sometimes the first attempt doesn’t quite give you the results you’re looking for. Our new toolbar makes it faster to quickly add useful filters to find the email you want.

Have you ever done a search and found your results are being dominated by a particular sender you’re not interested in, or from a folder you know doesn’t have what you need? We intelligently offer to exclude these with just a few clicks, based on the previous search results.

We hope you find this useful in getting the most out of Fastmail’s powerful search.

And more

Mistakes happen. That’s why Fastmail has multi-level undo/redo support for almost every action. But after the initial notification disappeared, you had to know the keyboard shortcut. Now you can undo/redo from the actions menu in your inbox as well.

Fastmail files makes it easy to host a basic website. Now we’ve added simple editing of plain text files, so you can make basic changes without leaving the app, or create a new text file on the go.

Fastmail joins the Internet Society

2025-06-20T00:00:01Z

At Fastmail one of our values is “we are a good internet citizen”. A key driving principle behind our work on JMAP is our commitment to keeping email open, and not just another proprietary messaging platform.

The Internet Society’s mission of making the internet be for everyone is right in line with our own goals and values, and Fastmail are proud to announce that we have joined them as a Bronze level member.

We look forward to participating in more of the Internet Society’s outreach and advocacy, as well as our ongoing commitments to open source and open standards work.

Addressing Privacy Fatigue

2025-06-15T11:00:00Z

Privacy fatigue is a real feeling — here’s how to make it manageable

Supporting the Office of Australian Information Commissioner Privacy Awareness Week 2025: Privacy — It’s Everyone’s Business

Do you ever feel that when you start reading about privacy, you’re suddenly overwhelmed by endless lists of tips such as enable two-factor authentication (huh?), check app permissions (what for?), review privacy policies (from where?), use encrypted messaging (is this another language?), switch browsers (truly?), audit your social media settings and even get off social media (will I lose all my friends?). The list goes on and on.

We know the problem isn’t that people don’t care about privacy. It’s that the privacy ecosystem has become so complex that it’s genuinely a scary place to start. When every digital choice feels like it requires a PhD in cybersecurity to evaluate properly, it’s natural to…give up.

So, in support of this year’s OAIC Privacy Awareness Week, I want to give you some of my tips, in everyday language that I hope will help this topic appear less overwhelming.

Step 1: The foundation (High Impact, low effort)

Use a password manager: While there are many reasons why we have partnered with 1Password; remembering all of your passwords can feel unachievable. Most browsers will have a built-in option these days, however, using tools such as 1Password provides additional options, such as sharing password vaults between families and syncing easily between devices and different browsers. A password manager will securely manage your passwords, removing all of the pain you would be feeling otherwise, and it works for all technical skill levels!

Use strong, unique passwords. As I have already mentioned, using a password manager such as 1Password means you can build out unique and strong passwords. Even moving to the level of using a passphrase. This protects you across every service you use, and these modern password managers make it nearly effortless. They truly are worth the investment.

Step 2: Cleaning up (Moderate impact, some effort)

Review and clean up your social media privacy settings. Not because social media is all that bad, but because the default settings are usually designed to share more than you might want. This isn’t about ruling people out of your life, it’s about giving you back some control of who or what you want to let in! Don’t forget to also check your recent followers list to remove or block the unknowns. Tim234567jur89 may not be the same person you think they are!

Also, be selective about app permissions. You probably don’t need to give that flashlight app access to your contacts or location history for it to work. Providing apps with additional permissions that are unnecessary for their operation allows the builders of that app to gather additional information. This information may be used for marketing purposes, such as targeted advertising to you based on your behaviours. Consider all permission requests and if they are not necessary for it to operate, is it truly required?

Step 3: Aiming for protection excellence (Varying level of impact, greater effort)

I’m definitely far from a technical expert here, but this is where I know encrypted messaging and regular security audits come in. Depending on what products you choose, the level of protection provided by the way they encrypt your data will vary. Personally, this is where I see a difference in using Fastmail over other email products; I have greater control of my data, and Masked Email addresses mean I can have even better control of my digital presence.

So, this is where I do recommend to switch to a privacy respecting email provider such as Fastmail. Your email is the hub of your digital life - it’s connected to every account, contains your most sensitive communications, and often stores years of personal history. It even stores this sort of information about your family and friends too. Moving to an email service that doesn’t scan your messages or sell your data is probably the single most impactful privacy decision you can make. For you and for anyone you ever have or will communicate with digitally!

Making privacy sustainable

I feel that the key to overcoming privacy overwhelm is to remember that privacy protection is an ongoing focus, not just a one stop destination. You don’t need to achieve perfect privacy security to benefit from better privacy habits. Every small step you take reduces your exposure and puts you more in control of your digital life.

Start with one change that matters to you. Get comfortable with it. Then consider what might make sense next. Privacy isn’t about living in digital isolation - it’s about making intentional choices about how your personal information is used.

At Fastmail, we’ve structured our entire business model around the principle of privacy matters. We’re a paid service so we never have to sell ads or your personal data. You pay us, so you’re our priority, not advertisers. We don’t scan your emails to build advertising profiles. We don’t sell your data to third parties. We make money when you pay us for a top quality service you value that we constantly improve on - it’s that simple.

Fastmail provides fast, private email that respects your privacy and puts you in control. No ads, no data mining, no nonsense. Learn more about how we’re different at fastmail.com.

Introducing the twom database format

2025-06-13T00:00:01Z

I wrote back in December about my ideas for a new skiplist based database format for the Cyrus IMAP server.

I spent a bunch of time over the next month writing just that. It’s called twom, “two” for the dual level0 pointers (the same as twoskip) and “m” for mmap and mvcc. I had planned to pronounce it “tomb” (for “it has tombstone records”) but have wound up usually saying “two em” for clarity. Maybe as this is posted on a Friday 13th we can call it “tomb” just for today.

All the code was in a merged pull request. The database itself is just a single standalone C language source file and associated header file. There’s also a cyrusdb interface wrapper, and a copy of xxHash directly in our source tree as well:

brong@elg:~/src/cyrus-imapd$ wc -l lib/*twom* lib/xxhash.h
   421 lib/cyrusdb_twom.c
  3298 lib/twom.c
   157 lib/twom.h
  7091 lib/xxhash.h
 10967 total

Amusingly, xxhash.h takes more space than anything else (and the lion’s share of the CPU usage as well, despite being much faster than crc32 as used in twoskip).

Why a new database format?

As I wrote during our advent series, twoskip has served us well, but it had a couple of major performance issues - particularly with our current ZFS on NVMe architecture. Retro-fitting some improvements to twoskip would have been possible, but it couldn’t do the most important thing (MVCC reads) because the on-disk format didn’t have the right structure.

We wanted MVCC because you could then repack an entire database without holding a lock the whole time, and replay the log at the end. I discovered that I didn’t even need an exclusive lock at all to do a repack, it could all be done with short-lived readlocks.

Overall these changes made twom faster. We don’t have performance data to show how much faster because we changed too many things at the same time to isolate it, but one simple repack test of a giant file showed repacks that had been 35 minutes with the twoskip file taking just over a minute with twom. A rather massive improvement! And even better, you could write to the file during the repack without losing data, while twoskip would have held an exclusive lock the entire time.

These are the major changes:

xxHash

The performance of xxHash vs CRC32 over small amounts of data is much better.

Twoskip and twom formats both hash blocks of about 40 bytes for the tracking pointers, and our keys and values are quite short in a lot of Cyrus formats too.

A faster hash function for small amounts of data is a big win. We chose xxHash for its friendly license and great performance.

MVCC repacks

This is massive. We have databases in the tens of gigabytes on the largest accounts, and when one of those chose to “checkpoint” - rewrite to remove stale data, it could lock an account for 30 minutes. This is obviously unacceptable.

The same repack taking one minute and allowing reads plus a thousand or so opportunities for writes during that repack is a completely different story; speaking of which…

Starvation-free locking

I can’t believe I got all the way to testing this thing to discover how little I knew about fcntl locking.

TIL: fcntl isn’t fair. Releasing the lock didn’t magically let a waiting writer proceed, the same process would often pick up the lock again without giving another process a chance. On busy files, writers could entirely starve.

We decided to use a two-offset locking strategy within the single database file, so writers can queue up waiting while all the readers are busy, and be ensured of their place in the line.

The git history will show I didn’t get this right the first time, and had to do a patch while testing across our fleet on just the statuscache file, an ephemeral database with high churn. The great thing about testing with statuscache is that users won’t notice if it breaks, since any error will just cause the status to be re-computed!

MMAP for reading and writing

Twoskip (and all the other Cyrus internal formats, like cache and index) uses mmap for read but write for writes. On most operating systems this is fine, they share a common cache, but it seemed simpler and nicer to use mmap for both reads and writes rather than creating in-memory structures to copy over.

And yes, we did read and watch the arguments against it (video)!

Of course we’re using msync to get reliable commits, and twom still has robust transactions with the same 3-syncs-per-commit pattern that made twoskip so solid.

MMAP also reduces syscalls. With twoskip we had to make multiple seek and write syscalls for each update, as we rewrote the backpointers (the average record has level 2, so needs to write 2 different backpointers plus the record itself).

This means that a single twoskip transaction writing to a single key/value pair makes an average of 19 syscalls (2 fcntl, 2 fstat, 6 lseek, 4 write, 2 writev, and 3 fdatasync).

Even with the more complex locking, the equivalent twom change makes half as many (4 fcntl, 2 fstat, and 3 msync).

But even better - a transaction which updates multiple key/value pairs adds an additional average of 6 syscalls on twoskip (3 lseek, 2 write, 1 writev) per record, while twom has no additional syscalls per transaction, no matter how many changes are made. This is particularly obvious during a repack, where the initial transaction on the new file contains every record in the database!

Pre-emptive allocation

Every time twom needs to make the file bigger, it extends it by 25% and then fills in the empty space. This seems a good tradeoff between low numbers of truncate and mmap operations, while not making files insanely large. It doesn’t actually use that space on most filesystems, the file remains sparse until writes fill the space.

This was by far the biggest performance increase (and the one we tested) - we had noticed with twoskip that a large amount of CPU was going on munmap and mmap calls, as with every new record the file became longer than the mapped space, and had to be re-mapped before the next write.

Twom decouples the file size from the committed size, which can leave junk from aborted transactions on the tail of the file, but the header length never gets updated until the third msync, so nothing ever reads that junk, and it gets overwritten as new commits come in.

Just straight POSIX

The twom library is written to be standalone. It doesn’t use any of the supporting libraries from Cyrus, opting to do fcntl locking and mmap manipulation directly. This allows it to keep a list of active transactions with their own mmaps so pointers remain valid; and for many other optimisations. Many things from twoskip were tightened up and simplified by not relying on other libraries.

This makes twom easily portable, and since it’s written from whole cloth (and I’m the only author on twoskip as well) I was able to put it under the CC0 public domain license; though obviously if you want to use xxHash you need to follow its 2-Clause BSD license as well.

Twom databases are a single file, containing an ordered key-value list. It’s transactional, with single threaded exclusive writers and multiple parallel readers. Twom files can be accessed by multiple un-related programs concurrently, so long as they all obey the locking rules.

I plan to lift the code out into its own repository at some point, and test it against all the other usual suspects in the key-value database space. The lib/cyrusdb_twom.c file is just a lightweight wrapper around the twom functions to convert cyrusdb semantics to twom style, and to convert error codes on the way back.

OK what does it look like?

Cyrus comes with a tool ‘cyr_dbtool’ which can be used to interact with any database formats, so here’s some interactions with a new DB, setting and deleting some records, and showing prefix iterators and dump output.

brong@elg:~/src/cyrus-imapd$ /usr/cyrus/bin/cyr_dbtool -n /tmp/test.db twom set a b
brong@elg:~/src/cyrus-imapd$ /usr/cyrus/bin/cyr_dbtool -n /tmp/test.db twom show
a       b
brong@elg:~/src/cyrus-imapd$ /usr/cyrus/bin/cyr_dbtool -n /tmp/test.db twom dump
UUID: uuid=fe720dec-4525-4e5d-a3c4-da665f3b0b40
FNAME: fname=/tmp/test.db
CHECKSUM ENGINE: XXH64
HEADER: v=1 g=1 fl=10000000 num=(1/1) sz=(00000000/000001B0/00000170) ml=1
00000060 DUMMY kl=0 dl=0 lvl=31 ()
        00000170 00000000
        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 00000000 00000000 00000000
00000170 ADD kl=1 dl=1 lvl=1 (a)
        00000000 00000000
00000198 COMMIT start=00000170
brong@elg:~/src/cyrus-imapd$ /usr/cyrus/bin/cyr_dbtool -n /tmp/test.db twom set xxa hello
brong@elg:~/src/cyrus-imapd$ /usr/cyrus/bin/cyr_dbtool -n /tmp/test.db twom set xxb world
brong@elg:~/src/cyrus-imapd$ /usr/cyrus/bin/cyr_dbtool -n /tmp/test.db twom show xx
xxa     hello
xxb     world
brong@elg:~/src/cyrus-imapd$ /usr/cyrus/bin/cyr_dbtool -n /tmp/test.db twom delete xxa
brong@elg:~/src/cyrus-imapd$ /usr/cyrus/bin/cyr_dbtool -n /tmp/test.db twom set xxa hi
brong@elg:~/src/cyrus-imapd$ /usr/cyrus/bin/cyr_dbtool -n /tmp/test.db twom dump
UUID: uuid=fe720dec-4525-4e5d-a3c4-da665f3b0b40
FNAME: fname=/tmp/test.db
CHECKSUM ENGINE: XXH64
HEADER: v=1 g=1 fl=10000000 num=(3/5) sz=(00000048/000002C8/00000170) ml=3
00000060 DUMMY kl=0 dl=0 lvl=31 ()
        00000170 00000000
        000001F8 000001F8 00000000 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 00000000 00000000 00000000
00000170 ADD kl=1 dl=1 lvl=1 (a)
        00000280 00000250
00000198 COMMIT start=00000170
000001B0 ADD kl=3 dl=5 lvl=1 (xxa)
        000001F8 00000000
000001E0 COMMIT start=000001B0
000001F8 ADD kl=3 dl=5 lvl=3 (xxb)
        00000000 00000000
        00000000 00000000
00000238 COMMIT start=000001F8
00000250 DELETE ancestor=000001B0
00000268 COMMIT start=00000250
00000280 REPLACE kl=3 dl=2 lvl=1 (xxa)
        00000250 <-
        00000000 000001F8
000002B0 COMMIT start=00000280

That’s a version 1 file, generation 1 (never been repacked), flags just means “using XXH64”, 3 commits, 5 records, some interesting sizes (last repack, current size, estimated repack size) - with the highest skiplevel of 3.

Let’s repack it:

brong@elg:~/src/cyrus-imapd$ /usr/cyrus/bin/cyr_dbtool -n /tmp/test.db twom repack
brong@elg:~/src/cyrus-imapd$ /usr/cyrus/bin/cyr_dbtool -n /tmp/test.db twom dump
UUID: uuid=fe720dec-4525-4e5d-a3c4-da665f3b0b40
FNAME: fname=/tmp/test.db
CHECKSUM ENGINE: XXH64
HEADER: v=1 g=2 fl=10000000 num=(3/1) sz=(00000000/00000218/00000200) ml=2
00000060 DUMMY kl=0 dl=0 lvl=31 ()
        00000170 00000000
        00000198 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 00000000 00000000 00000000
00000170 ADD kl=1 dl=1 lvl=1 (a)
        00000198 00000000
00000198 ADD kl=3 dl=2 lvl=2 (xxa)
        000001C8 00000000
        000001C8
000001C8 ADD kl=3 dl=5 lvl=2 (xxb)
        00000000 00000000
        00000000
00000200 COMMIT start=00000170

All the tombstones removed, and the file is back in order. Any new writes will stitch themselves into the various linked lists by updating the back pointers. Finally, let’s look at the raw file:

00000000  a1 02 8b 0d 74 77 6f 6d  66 69 6c 65 00 00 00 00  |....twomfile....|
00000010  fe 72 0d ec 45 25 4e 5d  a3 c4 da 66 5f 3b 0b 40  |.r..E%N]...f_;.@|
00000020  01 00 00 00 00 00 00 10  02 00 00 00 00 00 00 00  |................|
00000030  03 00 00 00 00 00 00 00  01 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 02 00 00 00 00 00 00  |................|
00000050  18 02 00 00 00 00 00 00  02 00 00 00 8a 57 92 ee  |.............W..|
00000060  01 1f 00 00 00 00 00 00  70 01 00 00 00 00 00 00  |........p.......|
00000070  00 00 00 00 00 00 00 00  98 01 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000160  00 00 00 00 00 00 00 00  6c d0 f8 56 00 00 00 00  |........l..V....|
00000170  02 01 01 00 01 00 00 00  98 01 00 00 00 00 00 00  |................|
00000180  00 00 00 00 00 00 00 00  d8 de f5 3d 84 a4 92 c8  |...........=....|
00000190  61 00 62 00 00 00 00 00  02 02 03 00 02 00 00 00  |a.b.............|
000001a0  c8 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  c8 01 00 00 00 00 00 00  05 8c 71 d7 70 cf ff c3  |..........q.p...|
000001c0  78 78 61 00 68 69 00 00  02 02 03 00 05 00 00 00  |xxa.hi..........|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  19 cf b0 45 a7 69 06 9d  |...........E.i..|
000001f0  78 78 62 00 77 6f 72 6c  64 00 00 00 00 00 00 00  |xxb.world.......|
00000200  07 00 00 00 00 00 00 00  70 01 00 00 00 00 00 00  |........p.......|
00000210  1d 44 bd 3d 00 00 00 00  00 00 00 00 00 00 00 00  |.D.=............|
00000220  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00004000

There’s not much fat in there! There is probably 50 bytes of overhead per record once you factor in trailing nulls on key and value, 8 bytes of header, 8 bytes of checksums, an average of 3 64-bit pointers, and padding out to an 8 byte boundary.

Fastmail is running twom

Since February 12, 2025, all Fastmail email servers have been using the twom backend in all the places they used to use twoskip. The switch was done in three phases over two days.

I’m very happy to have removed one of the places in which Fastmail could fail to live up to its name! No more pauses for database repacks.

I’m hoping that in some future release of Cyrus, the twom backend will be the default - but mostly, once twom was finished I was just glad to take a break from reading hexdumps and do something else for a while!

A revamped Fastmail inbox

2025-04-28T00:00:01Z

Today we’re launching a new look for your inbox, in both our webmail and mobile apps. Familiar but refined, the message list is now cleaner and more focused. Avatars help quickly identify who’s in the conversation, and one-click hover actions let you easily archive or delete.

Make it yours with easier customisation, with live updates as you try out different options. Don’t have a Fastmail account yet? Here’s what you’re missing:

And more

We’ve also focused on fixing the niggling small things. We’ve improved support for using a mouse or pencil in our iPad app. Made it easier to quickly create a contact or event while reading a message. Added an option to stop messages from being automatically marked as read when you open them. We’ve even moved the “report phishing” action to be next to “report spam”. Finally.

On mobile you can also now choose what apps are shown in the mobile navigation bar at the bottom (or turn them all off to hide it). Missing your quick hover actions? Configure up to four custom swipe actions to fly through your mail on the go. To select a message, just press and hold, or swipe with two fingers.

We hope you enjoy the new look. Thanks to all our beta testers for the feedback they sent in. If you too want to get a sneak peek of what’s coming next at Fastmail, just log in at beta.fastmail.com. Coming soon … full offline support!

Happy International Email Day

2025-04-22T14:00:00Z

Today, on International Email Day, I’m taking a moment to appreciate the communication tool many of us use and rely on every day. At Fastmail, email isn’t just our business – it’s our passion. The team and I believe email deserves recognition as one of the digital age’s most powerful, flexible, and lasting technologies.

Email: Still going strong

Let’s take a moment to appreciate some history! From the first ever electronic messages in the early 1970s to the modern multimedia communications we send today, email has come a long way. While other technologies have come and gone, email has adapted, thrived, and become a necessary tool for most of us in our day-to-day lives.

Why is this the case?

I feel it is because email just works. It puts the mailbox owner in control of their communications. Email is based on open standards that anyone can implement. This generates competition and innovation to keep building better email products. Closed platforms will inevitably try and lock you in and then maximise your attention and their advertising revenue. You don’t need to be on the same service to communicate with someone else – email connects everyone globally every day.

What makes email special?

In a world of passing trends, shortened attention spans, and conflicting priorities, an email received or sent feels refreshingly respectful; things that make email special for me:

I control the pace: Email waits for me to respond, when I am ready, not the other way around.
It breaks down barriers in communication: It makes me feel connected. Many people have access to an email address.
I can refer to it when I need to: Important information stays accessible and searchable (for when I forget!). Bron, our CEO, wrote about this here in 2018.
It’s private: My messages aren’t fodder for algorithms (at least not at Fastmail!).
It’s professional: For work and essential matters, nothing beats email!

How here at Fastmail, we are making email better

At Fastmail, we don’t just provide email; as a team, we’re actively improving it for both our customers and the world. Here’s how:

We created JMAP: Our team was the driving force behind JMAP, an open API standard for modern mail clients and applications to manage email faster. JMAP significantly improves on existing outdated protocols to provide a better email experience across all devices.

We prioritise privacy: No tracking pixels, no ad targeting, no reading your messages to sell you things.

We contribute to open source: The team regularly contributes code to projects like Cyrus IMAP, and have made core parts of our own technology available for others to build upon. We believe that open standards and cooperation make email better for everyone.

We build thoughtful features: From masked email addresses that protect your privacy (one of my favourite features) to powerful filtering rules that organise your inbox, the team are constantly adding tools that put you in control.

Your email is your business, not ours.

What’s next for email?

Email isn’t standing still, and neither are we.

Right now we’re in the final stages of beta testing full offline support for the Fastmail app, as well as refinements to our look and feel. In partnership with others in the industry, we’re also improving the email ecosystem with work on everything from making it easier to securely set up your email client to improving message authentication to protect your inbox.

Email thrives because it continues to evolve while staying true to its core purpose: connecting people reliably. As an industry leader, I know all of the team at Fastmail are committed to ensuring email remains the versatile, powerful tool we all rely on every day.

Join us in celebrating email

Whether you’re a power user with diligently organised folders or someone who simply appreciates sending a quick message to a friend, today is a good day to appreciate how email connects all of us to the people and information that matter.

I am proud to be part of a great team that delivers a service that respects privacy, enhances productivity, and helps all of us communicate on our own terms.

Happy International Email Day from myself and everyone else here at Fastmail!

Not OK, Cupid

2025-03-21T00:00:01Z

I don’t usually like to call out the bad behaviour of specific companies, but the egregious mis-design and lack of acknowledging it justify this case.

Welcome to OkCupid

A couple of weeks ago, I started seeing many “Welcome to OkCupid” emails, both on my personal address and a couple of related addresses, but also to multiple Fastmail official contact addresses — legal, partnerships, press, etc. Specifically, this list included trash@brong.net — an address that has never been used to send or receive email and appears in precisely one place — an article on our blog! It seems quite clear that somebody scraped our website and used the addresses to sign up. I’m aware of at least 10 addresses, but there are likely others that either go to someone else or addresses that no longer exist.

It didn’t stop there, though. I’ve been getting tons of “someone likes you”, “you have an intro,” and even an “IMPORTANT: We removed your photo on OkCupid.” email saying that inappropriate content was posted to “our” account!

The real-world consequences of poor email validation

This isn’t just an inconvenience — it has real security implications. Websites that fail to properly validate email ownership can be exploited for malicious purposes. Attackers can use unverified sign-ups to flood inboxes, making it easier to hide critical emails among the noise — something we’ve discussed our own experience of in our post on 2FA vulnerabilities. There are established best practices (PDF) for handling email sign-ups responsibly, practices that OkCupid is failing to follow.

No way out

When I tried to unsubscribe using the one-click unsubscribe button in one of the emails, I was met with an error: “Something went wrong, please try again later.”

Curious, I tried to recover a password on one of these accounts (the one with my personal email address) and successfully changed the password. Then, I was asked to confirm my login with a message sent to the number associated with the account. A number I didn’t know. A number that wasn’t mentioned on that page, so I still don’t know anything about it — not even which country it was from.

This raises further security concerns; the attacker could have also caused random recovery numbers to be texted to another poor victim’s phone. Alternatively, they could confirm that my email address is actively monitored, increasing its value for further attacks. Either way, what I couldn’t do was actually close the account.

Whack-a-mole

So, I contacted OkCupid’s support. Here’s what they said:

I’ve removed the user from the site and banned the email address to prevent any new accounts from being created. That should resolve the issue, but if you encounter anything like this again in the future, please don’t hesitate to reach out, and we’ll address it right away.

So, I need to contact support manually for each new email address. This is neither scalable nor acceptable; people don’t have this amount of time.

Furthermore, my email address is now on another random blocklist somewhere on the internet, where I have no control and no way to unblock it. I don’t anticipate wanting to use OkCupid’s service, but if I did in the future, I would have to go through another dance to get the address unlocked again — or more likely, treat that particular email address as soiled and create another one.

Not OK

So I say, not OK, OkCupid. Not OK.

The usefulness of email depends on responsible behaviour from all service providers. Companies that engage in shady or outright inappropriate practices make the internet worse for everyone.

OkCupid’s failure to implement even the simplest form of email validation is unacceptable. Until they address these issues properly (not through the support response provided here), they remain part of the problem, not the solution.

Could we have avoided this?

In this case, we published those addresses online. There’s always a risk of receiving spam when you do that, one could even reasonably say “we were asking for it”. We expected spam. If you want to reduce your risk of being spammed, it helps to not publish your email address on the public web!

What we we didn’t was expect a relatively reputable service being used to facilitate us being spammed.

One great protection is using different address for each different organisation you deal with — that way if your address leaks (or they sell it), you know where the breach happened, and you can more easily block just the problem messages.

Fastmail’s masked email feature is a great way to implement this strategy. Masked emails are designed, particularly when integrated with a password manager, to make it very easy to create new addresses, and track where they are expected to be used.

Being a good internet citizen is one of Fastmail’s core values. We require verification for sending identities, ensuring that only legitimate users can send from an address they claim they own. This is the level of responsibility every email provider should uphold, and we applaud the others who also do.

The evolution of the advanced fee scam

2025-02-14T05:00:00Z

As one of Fastmail’s customer support agents, part of my job is making sure that our customers are well-informed about rising trends in fraud so that they can be sure to steer clear of them. While our customers tend to be tech-savvy enough to spot the average scam email from a mile away, online scammers grow increasingly more sophisticated every year.

I recently attended the 62nd General Meeting of the Messaging, Malware, Mobile Anti-Abuse Working Group (M3AAWG) in Toronto. There, I spoke with others in the email and anti-abuse industry about the increase in advanced fee scams they’d observed in the years since the onset of the COVID-19 pandemic.

Advanced fee scams are not a new type of scam, but scammers have begun running a much more sophisticated version of this old-school scam. One that can convince even those who know to be cautious when navigating the internet.

Historically, advanced fee scams involved scammers promising the victim some sort of too-good-to-be-true opportunity or reward. The only catch is that the the victim has to pay a fee before they can receive the promised reward or opportunity. Generally, the scammer claims this fee is just to cover processing fees, background checks, training materials, or some other reasonable sounding expense. They assure the victim that they’ll be reimbursed for this expense down the road. Once the victim pays the fee, the scammer goes silent and the victim realizes that they’ve been conned.

Until recently, advanced fee scams were your garden variety “Nigerian prince” scam that savvy internet users quickly learned to avoid. Someone would offer the victim a large payoff if the victim could just cover the relatively small wire transfer or bank processing fees. For most email users, this type of con was easy to detect and most people knew to watch out for them.

Advanced fee scams have recently evolved to masquerade as hiring and work-from-home opportunities, targeting people who are looking for work in an already highly competitive job market. The scammers will pose as hiring managers or recruiters, and will even go so far as to reach out to victims over legitimate hiring websites, such as LinkedIn.

The victim is led to believe that they are being considered for a job or internship opportunity, but they’ll be asked to pay a fee as part of the hiring process. In some cases, the victim is given a link to the company’s preferred online vendor, where they are told to purchase the items they’ll need for the job. The scammer tells the victim that they’ll be reimbursed for these purchases later. However, the link takes the victim to a fake webstore where the payment is taken, but no goods are ever sent. At this point, the scammer stops responding to the victim.

More frequently, the scammers ask the victim to pay a small fee to cover some other aspect of the hiring process. Generally, the scammer will claim this is an application fee or something similar. Of course, the scammer stops responding to the victim’s messages as soon as they receive the payment.

In some cases, scammers will even conduct actual phone or video interviews with the victim as part of the phony hiring process. There’s no way to know how this data is being used by the attackers without insider knowledge.

This combination of fraudulent hiring and advanced fee scams allows attackers to collect both money and personally identifying information from vulnerable populations.

I recommend the following precautions to avoid becoming the victim of one of these scams:

Confirm the legitimacy of any jobs you are interested in applying for by verifying that the position is listed on the company’s website.
Make sure that any emails you receive from a hiring manager are actually coming from the company’s domain or from the domain of a legitimate staffing agency. Double check that there are no typos or look-alike characters in the domain.
Take the same precautions with any URLs that are shared with you via email or on hiring sites. Scammers can set up convincing look-alike websites, but you can check the URL to verify that you are being directed to the company’s legitimate website.
Even if a message appears to be sent from a company’s actual domain, there’s a chance that the message could be spoofed, meaning the scammer forged the email’s “From” address to make it look like it came from a certain person or company. Chances are that these messages would get flagged as spam, but it’s still a good idea to confirm that a message hasn’t been spoofed by checking the headers of the message. Fastmail makes it easy to view the full headers of a message. Simply click the Actions drop down and select Show raw message to see the full headers of the message and verify that the message passed sender authentication checks. If you’re not familiar with how to read email headers, you can always reach out to Fastmail’s friendly and knowledgeable support team to help confirm a message’s legitimacy.
If a job opportunity seems too good to be true, or you’re told that you’ve been accepted for a position almost immediately with little to no interview process, chances are the hiring manager or recruiter that you’re talking with is actually a scammer.
If at any point in the interview process the recruiter asks to stop communicating via email and asks you to contact them on Telegram, WhatsApp, or any other end-to-end encrypted communication platform, they are almost certainly trying to scam you.
If the company requires payment from you for a job opportunity, we ultimately recommend that you do not proceed. It’s extraordinarily rare for a legitimate company to require payment from you for a job opportunity.

As these scams become more pervasive, it’s crucial that those on the job market educate themselves on the potential scams that are out there. Knowing how to recognize and avoid these fraudulent job listings can ensure you don’t waste your time, lose money, or divulge your personal data to scammers.

Dec 24: Twenty five years of Fastmail

2024-12-24T00:00:01Z

This is the twenty-fourth and final post in the Fastmail Advent 2024 series. The previous post was Dec 23: Ten years of JMAP. Thanks for reading, see you again next year.

As we conclude this year’s Advent posts, we are reflecting back over 25 years! Fastmail was founded in 1999, to fill a gap which existed at the time — in the space between ISPs, slow and ad-riddled free email services, and clunky, bloated Enterprise systems, there was no professional email service for a small business or sophisticated email user.

So we built one! Fastmail: a slick, professional, web-based email service.

In the 25 years since, we have seen many changes in the email landscape and the world around us. The advent of Gmail and conversations as a standard email model. The rise of encryption focused services like Protonmail (with the pros and cons of storing email as opaque, unsearchable blobs). Highly opinionated “reinventions” of email like Hey. And of course the multiple premature announcements that email was dead, to be replaced by the latest new craze.

We were purchased by Opera Software in 2010, but after some changes in Opera’s strategic direction, thankfully a handful of the staff managed to buy the company back in 2013. We then purchased another email service Pobox in 2015, who had been running an email service even longer than us. We have recently finished merging their product into our system; who knew it was going to take so long to integrate everything!

Through all of this we’ve been grateful to have such loyal customers. We regularly hear from customers how much they appreciate the Fastmail service. Our fantastic customer support. The continuous, thoughtful, and well designed improvements to our product. The high performance and reliability of our service. The ongoing commitment to integrity, privacy, and longevity.

The result is that we have a greater than 90% annual renewal rate, and an ongoing stream of new customers from the word of mouth recommendations of existing customers. We have and continue to grow every year in a sustainable and deliberate way. We’re insanely grateful for this. We get to focus on making email better for our customers, to work with and build cool technology — with really smart colleagues. We can solve complex problems, build well-designed solutions, and improve email standards without having to always hustle for the next sale.

It’s an enviable position to be in. Email remains the largest open federated communication network on the internet. Not controlled by a single company. Not part of any walled garden that can change at any time. Through open standards, email allows you to choose the best provider and to move your email where is best for you. As we said in our first post of this series, we will continue to “Make email better”, for our customers and for everyone.

We love our work, and the customers who trust us with their email and make this all possible. So cheers to you, Fastmail’s customers. We get to make email better, the product you use and the ecosystem we all operate in, while having fun and working on interesting problems with great people.

Here’s to another 25 years.

Dec 23: Ten years of JMAP

2024-12-23T00:00:01Z

This is the twenty-third post in the Fastmail Advent 2024 series. The previous post was Dec 22: Why we use our own hardware at Fastmail. The final post is Dec 24: Twenty five years of Fastmail.

Exactly 10 years ago, we announced JMAP on our blog, along with a video by baby-faced Bron and Neil!

JMAP: A better way to email. We knew it would be a long road, but we’re really glad we did it and created an open standard rather than staying with our own custom protocol.

Some moments along the way

We started by workshopping the idea around the industry. I did a lightning talk at OSCON in 2014, our first attempt to find developers who could give us feedback on our design. By far the best find was Ricardo Signes, Pobox developer, who I met at a bar on the last day! This led to us acquiring the product and (our main goal) acqui-hiring Rik, who is now one of the company owners, as well as a JMAP enthusiast!

Neil and I attended Inbox Love in the Bay Area in 2014 as well. This gave us a chance to meet some of our technical peers in the big companies, relationships which we have continued to foster over the years. This hasn’t led to everyone dropping everything and implementing our protocols, but it has led to some collaborative design and ongoing conversations, and I believe its has prevented a proliferation of other protocols since people point to JMAP instead of inventing a new thing themselves. We also were told “go to the IETF”, but the IETF seemed big and scary and we didn’t know how, so that took a while.

Instead, we joined CalConnect and started working on Calendar formats and standards, while promoting JMAP more generally. Eventually we made more contacts in the IETF, and finally in 2017 went to our first IETF meeting in Chicago. At this point, the JMAP working group was born.

In the crucible of the IETF, we made major changes. The authentication was removed. Method names were split into Object/action and a ton of smaller changes were made. The Core and Mail JMAP specifications were published in 2019, and then we got to work on the rest of the stack.

JMAP Contacts was published just last week, and JMAP Calendars is very close to being published. I’m also keen to add Filenode support, but we want to get more experience with other filesystem providers before we standardize that (it’s currently based very closely on Fastmail’s own custom Node objects for our filestorage feature).

What’s next

We created JMAP because we could see that without it, the email world was going to become more insular, with the only modern standards for email access being proprietary. With Calendars and Contacts, we’re bringing the same easy-to-use JSON objects under a single protocol.

We started the Make Better Email conference last year, focused on improving the authentication workflow and also promoting JMAP usage. It’s a very small, invite-only conference where we do deep technical design work on improving interoperability and discoverability between clients and services. It was in Philadelphia last year, London this year, and we expect to be in Philadelphia again next year — likely in mid November after IETF 124 so we don’t cross over Halloween. If you think you’d be a useful addition to the meeting, pop us an email via the link at the bottom of the site.

Some work products of the previous conferences have been:

An OAuth profile for open-protocol clients
A profile for JMAP push allowing you get some of the benefits of JMAP’s push capability without having to do a full JMAP implementation
A specification for auto-discovery of configuration information

Over the past year some of us have also been working in the server-to-server space with an idea that may wind up replacing or enhancing DKIM.

And finally, next year we will be investing a lot more effort into making the Cyrus IMAP server not just a reference implementation for JMAP, but much easier to both develop and run.

In 10 years time, I hope to post about how Cyrus and JMAP have taken over the world, but I’ll also happily settle for them having both improved Fastmail’s product immeasurably, having plenty of happy customers, and continuing to help make email better for everybody through our work.

Dec 22: Why we use our own hardware at Fastmail

2024-12-22T00:00:01Z

This is the twenty-second post in the Fastmail Advent 2024 series. The previous post was Dec 21: Fastmail in a box. The next post is Dec 23: Ten years of JMAP.

Why we use our own hardware

There has recently been talk of cloud repatriation where companies are moving from the cloud to on premises, with some particularly noisy examples.

Fastmail has a long history of using our own hardware. We have over two decades of experience running and optimising our systems to use our own bare metal servers efficiently.

We get way better cost optimisation compared to moving everything to the cloud because:

We understand our short, medium and long term usage patterns, requirements and growth very well. This means we can plan our hardware purchases ahead of time and don’t need the fast dynamic scaling that cloud provides.
We have in house operations experience installing, configuring and running our own hardware and networking. These are skills we’ve had to maintain and grow in house since we’ve been doing this for 25 years.
We are able to use our hardware for long periods. We find our hardware can provide useful life for anywhere from 5-10 years depending on what it is and when in the global technology cycle it was bought, meaning we can amortise and depreciate the cost of any hardware over many years.

Yes, that means we have to do more ourselves, including planning, choosing, buying, installing, etc, but the tradeoff for us has and we believe continues to be significantly worth it.

Hardware over the years

Of course over the 25 years we’ve been running Fastmail we’ve been through a number of hardware changes. For many years, our IMAP server storage platform was a combination of spinning rust drives and ARECA RAID controllers. We tended to use faster 15k RPM SAS drives in RAID1 for our hot meta data, and 7.2k RPM SATA drives in RAID6 for our main email blob data.

In fact it was slightly more complex than this. Email blobs were written to the fast RAID1 SAS volumes on delivery, but then a separate archiving process would move them to the SATA volumes at low server activity times. Support for all of this had been added into cyrus and our tooling over the years in the form of separate “meta”, “data” and “archive” partitions.

Moving to NVMe SSDs

A few years ago however we made our biggest hardware upgrade ever. We moved all our email servers to a new 2U AMD platform with pure NVMe SSDs. The density increase (24 x 2.5" NVMe drives vs 12 x 3.5" SATA drives per 2U) and performance increase was enormous. We found that these new servers performed even better than our initial expectations.

At the time we upgraded however NVMe RAID controllers weren’t widely available. So we had to decide on how to handle redundancy. We considered a RAID-less setup using raw SSDs drives on each machine with synchronous application level replication to other machines, but the software changes required were going to be more complex than expected.

We were looking at using classic Linux mdadm RAID, but the write hole was a concern and the write cache didn’t seem well tested at the time.

We decided to have a look at ZFS and at least test it out.

Despite some of the cyrus on disk database structures being fairly hostile to ZFS Copy-on-write semantics, they were still incredibly fast at all the IO we threw at them. And there were some other wins as well.

ZFS compression and tuning

When we rolled out ZFS for our email servers we also enabled transparent Zstandard compression. This has worked very well for us, saving about 40% space on all our email data.

We’ve also recently done some additional calculations to see if we could tune some of the parameters better. We sampled 1 million emails at random and calculated how many blocks would be required to store those emails uncompressed, and then with ZFS record sizes of 32k, 128k or 512k and zstd-3 or zstd-9 compression options. Although ZFS RAIDz2 seems conceptually similar to classic RAID6, the way it actually stores blocks of data is quite different and so you have to take into account volblocksize, how files are split into logical recordsize blocks, and number of drives when doing calculations.

               Emails: 1,026,000
           Raw blocks: 34,140,142
 32k & zstd-3, blocks: 23,004,447 = 32.6% saving
 32k & zstd-9, blocks: 22,721,178 = 33.4% saving
128k & zstd-3, blocks: 20,512,759 = 39.9% saving
128k & zstd-9, blocks: 20,261,445 = 40.7% saving
512k & zstd-3, blocks: 19,917,418 = 41.7% saving
512k & zstd-9, blocks: 19,666,970 = 42.4% saving

This showed that the defaults of 128k record size and zstd-3 were already pretty good. Moving to a record size of 512k improved compression over 128k by a bit over 4%. Given all meta data is cached separately, this seems a worthwhile improvement with no significant downside. Moving to zstd-9 improved compression over zstd-3 by about 2%. Given the CPU cost of compression at zstd-9 is about 4x zstd-3, even though emails are immutable and tend to be kept for a long time, we’ve decided not to implement this change.

ZFS encryption

We always enable encryption at rest on all of our drives. This was usually done with LUKS. But with ZFS this was built in. Again, this reduces overall system complexity.

Going all in on ZFS

So after the success of our initial testing, we decided to go all in on ZFS for all our large data storage needs. We’ve now been using ZFS for all our email servers for over 3 years and have been very happy with it. We’ve also moved over all our database, log and backup servers to using ZFS on NVMe SSDs as well with equally good results.

SSD lifetimes

The flash memory in SSDs has a finite life and finite number of times it can be written to. SSDs employ increasingly complex wear levelling algorithms to spread out writes and increase drive lifetime. You’ll often see the quoted endurance of an enterprise SSD as either an absolute figure of “Lifetime Writes”/“Total bytes written” like 65 PBW (petabytes written) or a relative per-day figure of “Drive writes per day” like 0.3, which you can convert to lifetime figure by multiplying by the drive size and the drive expected lifetime which is often assumed to be 5 years.

Although we could calculate IO rates for existing HDD systems, we were making a significant number of changes moving to the new systems. Switching to a COW filesystem like ZFS, removing the special casing meta/data/archive partitions, and the massive latency reduction and performance improvements mean that things that might have taken extra time previously and ended up batching IO together, are now so fast it actually causes additional separated IO actions.

So one big unknown question we had was how fast would the SSDs wear in our actual production environment? After several years, we now have some clear data. From one server at random but this is fairly consistent across the fleet of our oldest servers:

# smartctl -a /dev/nvme14
...
Percentage Used:                    4%

At this rate, we’ll replace these drives due to increased drive sizes, or entirely new physical drive formats (such E3.S which appears to finally be gaining traction) long before they get close to their rated write capacity.

We’ve also anecdotally found SSDs just to be much more reliable compared to HDDs for us. Although we’ve only ever used datacenter class SSDs and HDDs failures and replacements every few weeks were a regular occurrence on the old fleet of servers. Over the last 3+ years, we’ve only seen a couple of SSD failures in total across the entire upgraded fleet of servers. This is easily less than one tenth the failure rate we used to have with HDDs.

Storage cost calculation

After converting all our email storage to NVMe SSDs, we were recently looking at our data backup solution. At the time it consisted of a number of older 2U servers with 12 x 3.5" SATA drive bays and we decided to do some cost calculations on:

Move to cloud storage.
Upgrade the HD drives in existing servers.
Upgrade to SSD NVMe machines.

1. Cloud storage:

Looking at various providers, the per TB per month price, and then a yearly price for 1000Tb/1Pb (prices as at Dec 2024)

Amazon S3 - $21 -> $252,000/y
Cloudflare R2 - $15 -> $180,000/y
Wasabi - $6.99 -> $83,880/y
Backblaze B2 - $6 -> $72,000/y
Amazon S3 Glacier Instant Retrieval - $4 -> $48,000/y
Amazon S3 Glacier Deep Archive (12 hour retrieval time) - $0.99 -> $11,880/y

Some of these (e.g. Amazon) have potentially significant bandwidth fees as well.

It’s interesting seeing the spread of prices here. Some also have a bunch of weird edge cases as well. e.g. “The S3 Glacier Flexible Retrieval and S3 Glacier Deep Archive storage classes require an additional 32 KB of data per object”. Given the large retrieval time and extra overhead per-object, you’d probably want to store small incremental backups in regular S3, then when you’ve gathered enough, build a biggish object to push down to Glacier. This adds implementation complexity.

Pros: No limit to amount we store. Assuming we use S3 compatible API, can choose between multiple providers.
Cons: Implementation cost of converting existing backup system that assumes local POSIX files to S3 style object API is uncertain and possibly significant. Lowest cost options require extra careful consideration around implementation details and special limitations. Ongoing monthly cost that will only increase as amount of data we store increases. Uncertain if prices will go down or not, or even go up. Possible significant bandwidth costs depending on provider.

2. Upgrade HDDs

Seagate Exos 24 HDs are 3.5" 24T HDDs. This would allow us to triple the storage on existing servers. Each HDD is about $500, so upgrading one 2U machine would be about $6,000 and have storage of 220T or so.

Pros: Reuses existing hardware we already have. Upgrades can be done a machine at a time. Fairly low price
Cons: Will existing units handle 24T drives? What’s the rebuild time on drive failure look like? It’s almost a day for 8T drives already, so possibly nearly a week for a failed 24T drive? Is there enough IO performance to handle daily backups at capacity?

3. Upgrade to new hardware

As we know, SSDs are denser (2.5" -> 24 per 2U vs 3.5" -> 12 per 2U), more reliable, and now higher capacity - up to 61T per 2.5" drive. A single 2U server with 24 x 61T drives with 2 x 12 RAIDz2 = 1220T. Each drive is about $7k right now, prices fluctuate. So all up 24 x $7k = $168k + ~$20k server =~ $190k for > 1000T storage one-time cost.

Pros: Much higher sequential and random IO than HDDs will ever have. Price < 1 year of standard S3 storage. Internal to our WAN, no bandwidth costs and very low latency. No new development required, existing backup system will just work. Consolidate on single 2U platform for all storage (cyrus, db, backups) and SSD for all storage. Significant space and power savings over existing HDD based servers
Cons: Greater up front cost. Still need to predict and buy more servers as backups grow.

One thing you don’t see in this calculation is datacenter space, power, cooling, etc. The reason is that compared to the amortised yearly cost of a storage server like this, these are actually reasonably minimal these days, on the order of $3000/2U/year. Calculating person time is harder. We have a lot of home built automation systems that mean installing and running one more server has minimal marginal cost.

Result

We ended up going with the the new 2U servers option:

The 2U AMD NVMe platform with ZFS is a platform we have experience with already
SSDs are much more reliable and much higher IO compared to HDDs
No uncertainty around super large HDDs, RAID controllers, rebuild times, shuffling data around, etc.
Significant space and power saving over existing HDD based servers
No new development required, can use existing backup system and code
Long expected hardware lifetime, controlled upfront cost, can depreciate hardware cost

So far this has worked out very well. The machines have bonded 25Gbps networks and when filling them from scratch we were able to saturate the network links streaming around 5Gbytes/second of data from our IMAP servers, compressing and writing it all down to a RAIDz2 zstd-3 compressed ZFS dataset.

Conclusion

Running your own hardware might not be for everyone and has distinct tradeoffs. But when you have the experience and the knowledge of how you expect to scale, the cost improvements can be significant.

Dec 21: Fastmail in a box

2024-12-21T00:00:01Z

This is the twenty-first post in the Fastmail Advent 2024 series. The previous post was Dec 20: How Fastmail uses Fastmail!. The next post is Dec 22: Why we use our own hardware at Fastmail.

They say everybody has a testing environment. Some people are just lucky enough enough to have a separate environment for production. At Fastmail, every staff member can get their own isolated testing and development sandbox. We call this Fastmail-In-A-Box, or more commonly just “fminabox”.

Like many technologists, I learn most by fiddling with things, often breaking them along the way and putting them back together again. With fminabox, we give everyone their own world to break apart and put back together, risk free. This makes it an invaluable place for new hires to cut their teeth, and for existing staff to come up to speed in an area of Fastmail’s stack they haven’t worked on before.

Fminabox is a complete Fastmail deployment on a single host. This includes Cyrus for IMAP storage, Postfix for incoming and outgoing mail, MySQL for non-mail data, our JMAP web API, and all the frontend assets. It also runs the ancillary services we use to monitor Fastmail such as Prometheus, all managed by the same configuration and service management system we use in production. This allows for fast, iterative development with very little waiting time between making a change and seeing the effect, while eliminating most “it worked on my machine” bugs.

We use Hashicorp Packer to create fminabox, following the provisioning scripts we use in production as closely as possible. Who hasn’t made a change to a system where it works going from state N → N+1, but then discovered weeks later that it’s broken when bootstrapping from nothing? Each night we build a new image from scratch. This allows us to catch those types of failures, and to do so while the changes are still front-of-mind in the developers that made them.

Any staff member can tell our chatbot Synergy to box create, and Synergy will handle provisioning a VM in the cloud, set up DNS, and provide VPN configuration upon request. Fastmail continues to eschew the public cloud in favour of our own hardware to run our product, but it turns out the public cloud is really useful for creating test environments.

Fminabox is also a key part of our testing workflow. Fastmail has thousands of tests, from simple sanity compile checks to complex integration tests between systems. We use fminabox with our CI/CD pipeline so every change is automatically tested before it is merged. This was the ultimate progression from developers just running a handful of tests manually, to overnight runs, to fully integrated continuous testing.

As new needs arise, we continue to evolve the infrastructure. A few years ago I was making an improvement to our tooling that balances users between machines in our Cyrus backup system. At the time, fminabox only had a single target that all users were backed up to, so my first step was to add support for multiple backup targets. Only then did I feel comfortable that I could properly test any changes to the tooling.

I’m not the only user, so I asked some other Fastmail staff members “what’s your favourite feature of fminabox?”, and here’s what they had to say.

Fastmail is able to send via externally authenticated submission via OAuth, but Fastmail is also an OAuth provider and provides authenticated SMTP submission via OAuth. We were able to update our test suite to do full end-to-end OAuth authentication with ourself, send an email back to ourselves, and see that this entire path works.

—Rob Mueller, CTO

The best thing about fminabox is that it’s cheap and disposable. If I mess it up, I throw it away and make a new one and act like nothing happened. (The previous solution took hours to create a new box.)

—Ricardo Signes, Head of Special Projects

Although it only takes 5 minutes to setup, inaboxes provide a fully contained sandbox that includes all of our code ready to test. Minutes to build, seconds to tear down.

—Marcus Love, System Engineer

And that’s the story of fminabox. It isn’t perfect but it’s pretty damn good and it helps enable my colleagues to get their work done.

Dec 20: How Fastmail uses Fastmail!

2024-12-20T00:00:01Z

This is the twentieth post in the Fastmail Advent 2024 series. The previous post was Dec 19: Building offline: mail storage. The next post is Dec 21: Fastmail in a box.

At Fastmail, our features are designed to make email management seamless and efficient. But how do our own staff use these tools in their daily lives? While all the features are incredibly helpful, there will always be some personal favorites for one.

We asked team members to share their favorite Fastmail features and how they’ve customized them to fit their workflows. As support staff, we’re familiar with every feature, but each of us uses them in unique ways—and you might just discover a hidden gem in this article by seeing how we put them to work. And here’s what they had to say.

Vysakh: Mastering Inbox Zero and Organization

“I enjoy maintaining an Inbox Zero approach, so I organize my emails into folders for various services.”

Vysakh takes organization to the next level with Folders and Rules. He creates folders for specific categories like “Bank” (with subfolders for each bank) and “Purchases” (with subfolders for each website he purchases from like Amazon and Flipkart).

He also raves about Saved Searches, calling them an “underrated feature”:

A saved search for Unread Emails allows him to see all unread messages across folders.
Another for Emails Delivered Today is perfect for quickly finding new emails, even if they’re in Spam or Trash.

For self-organization, Vysakh uses Plus Addressing to save important documents by emailing them to himself with a folder-specific alias like username+Docs@fastmail.tld. He adds, “Fastmail supports searching inside attachments, so finding them later is super easy.”

Vysakh also highlights the efficiency of Keyboard Shortcuts for email navigation and Customizable Notification Actions in the Android app, which let him manage emails without opening the app.

I must say, he’s truly a pro-user of all our power features!

Merlin: Timing and Efficiency Made Easy

Merlin’s favorite is Schedule Send, which allows drafting emails at their convenience and sending them at the perfect time. I couldn’t agree more—it’s like having a personal assistant keeping your inbox in check!

She goes on to say, “My second favorite is Snooze—it lets me come back to emails when I have time to act on them.” Smart, right? Fastmail features truly help you work smarter, not harder.

Merlin also loves Mail rules to keep her emails organized effortlessly and appreciates their simplicity, saying, "It is a cinch to use even for beginners.”

Maya: A Domain for Every Interest

Maya’s love for email personalization shines through her extensive use of Domains and Aliases:

“I have a whole bunch of domains just for fun—some professional, some for hobbies like photo essays and writing.”

Her go-to feature is Masked Email combined with a custom domain. Whenever she signs up for a service, she creates a unique masked address, assigning each one to a folder. This setup lets her instantly identify breaches, unsubscribe from unwanted notifications, and organize her inbox for easy prioritization.

Maya also uses:

Pins to flag important emails in folders.
Snooze for emails she wants to revisit later without cluttering her inbox.
Tamper-Proof Retention, ensuring emails she’s deleted can still be recovered if needed.

She admits with a laugh, “It’s probably not something a non-business user like me should need, but it’s handy!”

Thu: Seamless Sharing and Catchall Convenience

Thu finds Catchall aliases and Mail sharing to be game-changers. “The catchall is super handy for creating new email addresses anytime I want”. She’s even set up a Fastmail account for her partner with shared aliases, mail, and calendars. Excitedly, she adds, “The sharing function works very well with integration to Apple devices and Gmail account,” making collaboration a breeze. You can almost feel her joy through those words—don’t you? I bet you do!

Leslie: Staying Organized with Pins

Leslie swears by the Pin and Keep pinned on top features to stay on top of essential emails. “I use this on my staff account quite a lot because we get various emails with a bit of information in them. When I go through my emails every morning, I will pin the emails that I want to go back and read and also emails about support trends that are occurring. This allows me to quickly refer back to the emails since I’m seeing them at the top of the list in my inbox.” Leslie clearly has a knack for using this feature to keep important information right at her fingertips—guess I know who to turn to for a quick reference!

Yassar: Power User of Labels and Searches

For Yassar, Labels are indispensable. “I love organizing everything in my mailbox, and I can’t imagine working without labels!” If you’re a fan of staying organized, you’re probably nodding in agreement right now.

But Yassar doesn’t stop there, his other go-to features include:

Masked Emails for secure online shopping.
Aliases to classify emails and route them to specific folders such as documents@mydomain.com or gmail@mydomain.com.
Saved Search for quick filtering of emails without creating a label for everything.

Yassar’s approach combines security, organization, and speed, showing how powerful these tools can be for anyone looking to optimize their email experience!

Jed: Streamlining Inbox Management with Keyboard Shortcuts

Jed relies heavily on Keyboard Shortcuts as one of his favorite Fastmail features:

“As someone who lets a lot of email build up before I get around to sorting them, I like how quickly I can label, archive, and delete large numbers of messages using these shortcuts.”

Wow! That’s brilliant—such a simple feature, yet so powerful! He’s turned what could be a daunting task into a seamless process. I’m definitely going to start using these more, and you should too!

Jess: Memos, Snoozing, and Smart Searching

Jess praises Memos for saving key details from lengthy emails. With a grin, she shares, “I just used it to note a coupon hidden in a long marketing email.” Who else can relate? I know I can—if you’re like me, always hunting for those elusive discount codes, Memos are here to save the day!

She’s also a big fan of the Snooze feature, which she frequently uses for bills or shipping notifications that need attention later.

Lastly, Jess makes extensive use of Search to streamline her inbox. The is:unread search helps her capture all unread emails across labels, enabling her to quickly sort through them and get closer to Inbox Zero. That’s an amazing tip—you’ll get a unified inbox with all unread emails in one place!

Aric: Sending at the Perfect Time

Scheduled send is one of the features Aric relies on the most, and it’s no surprise why, as he shares: “Working with teams across the globe and working on a non-traditional schedule, I often find myself sending mail outside of people’s general working hours. Using scheduled send allows me to send mail so that my message is one of the first things the recipient sees when they check their inbox." Impressive—that explains why his emails always seem to land at just the right time!

It’s been such a joy hearing from our team members about their favorite features. Inspired by them, how can I not share mine? I’m certainly not stepping back—here are my favorites.

One feature I find myself using a lot is the Login Log, which is crucial for maintaining the privacy and security of my account. It lets me instantly review login activities whenever I spot something suspicious. The interface is simple and intuitive, showing logins from the Fastmail web UI, Fastmail app, and third-party apps, along with any failed login attempts. This feature gives me the confidence to monitor and act swiftly when needed—no more panic attacks when something looks off!

Next up is the Advanced Search, a powerful yet user-friendly tool. For someone new to search tools and struggling to remember search syntax, this feature would be a real lifesaver. I use it all the time to refine my searches by selecting criteria from the available fields—whether it’s finding emails with specific attachment types, emails within a date range, or so much more. It’s fast, easy, and incredibly efficient! If you haven’t tried it yet, give it a go today—you’ll be amazed at how simple it is!

Then comes the Passkey feature making my life easier and logging into my account across different devices both simpler and more secure.

Honestly, I love all the features! They’ve taken me—once a self-proclaimed email management avoider (guilty as charged!)—and turned me into a full-fledged Inbox enthusiast.

A big thank you to my team for sharing their insights. It’s been great learning how everyone makes the most of these tools!

That wraps up an exciting dive into these amazing features and creative ways to use them—I hope you’ve found some inspiration to explore and make them your own!

Still not on Fastmail? Now’s the perfect time! Get your whole family on board with the Family plan and enjoy an exclusive 20% off your first year—don’t miss out!

Dec 19: Building offline: mail storage

2024-12-19T00:00:01Z

This is the nineteenth post in the Fastmail Advent 2024 series. The previous post was Dec 18: Building offline: syncing changes back to the server. The next post is Dec 20: How Fastmail uses Fastmail!.

Yesterday, we looked at how we store changes you make offline so we can accurately and efficiently sync them back to the server when you come online. Today, we’ll discuss why email is special, and what else we do to make this super fast, with support for full-text search offline.

Why offline email is hard

As discussed earlier, because we use JMAP for all of our APIs, once we can implement generic offline support and have it work for everything (currently 56 data types and counting in our app!). However, mail is special. And the reason it’s special is purely the volume of data.

Most web apps severely underestimate how small their data is. In almost all cases, you will be more efficient and way faster to just suck it all into memory and do a linear filter pass whenever you need to query it. This is the difference between response as-you-type autocomplete and frustrating loading spinners on each key stroke. Even for users with 10,000 contacts this is only a few megabytes of data — perfectly cacheable.

Email is different though. We have users with millions of messages. Even with attachments handled separately in JMAP, each message could have hundreds of kilobytes of HTML as the body. But we expect opening a mailbox to load a listing pretty much instantly, and searches to be fast too. To make this work, we have to add a number of tricks to our standard offline approach.

Splitting the data

The first trick is to split the data into two separate object stores:

EmailMetadata: this stores just the data that’s not parsed from the email content, like the id, thread id, keywords it has, and mailboxes it’s in. This keeps it small, but crucially also contains all the mutable data. This is treated like our standard JMAP object store for a data type.
EmailContent: this stores the email content; who it was sent from/to, the subject, body, list of attachments (but not the attachment data itself) etc.

Due to the volume of data, we can’t load everything at once. We page in the data in stages instead:

We fetch a list of just the ids and create placeholder entries in the EmailMetadata object store.
We page in the metadata and basic headers (like to/from/subject) for all messages in batches. This gives us everything we need to show the listing for any folder or label.
We page in the body for pinned and recent messages, or everything if the user has selected this option in settings, again in batches.

This split is useful, because for most queries we can get away with just loading the metadata into memory, not the content. This is a big saving in time and memory when deserialising the objects from the underlying datastore.

Efficient mailbox querying

A linear pass through all the metadata is surprisingly tractable, even for large mailboxes, however it’s slower than we want for common queries (like opening your inbox). This is where we introduce a couple of extra custom indexes — separate object stores we are careful to update in lock step with any changes to our data.

The first of these is EmailMailboxes. This stores an entry for each addition or removal of a message from a folder/label, allowing us to both very efficiently compute the list of messages/conversations in a particular mailbox, and also calculate a delta update to the query when making changes.

The key for this object store is:

[MAILBOX_ID, REMOVED_MODSEQ, ADDED_MODSEQ];

The values look like:

[EMAIL_ID, THREAD_ID, DATE, IS_UNREAD];

Whenever a message is added to a mailbox, a new entry is created. ADDED_MODSEQ is the current “updated” moseq of the message, and REMOVED_MODSEQ is 0.

If the message is removed from the mailbox, the old entry is deleted, and a new one added with the same ADDED_MODSEQ, but REMOVED_MODSEQ set to the new “updated” modseq of the message.

From this, we can quickly get the list of current messages in a particular mailbox by doing a range query for entries with keys that start: [MAILBOX_ID, 0]. The values include the date and thread id, allowing us to do the most common sort, and remove duplicates for the same thread id, without having to even fetch the metadata objects for the emails.

Delta query updates

JMAP has a way for a client to ask for what’s changed in a query. This allows it to more efficiently update its local store and uses less bandwidth. With the EmailMailboxes index, we can also implement this. First we fetch the entries for the current messages as before, but then we also fetch the entries for messages that have been removed since our last state (this is a range query between [MAILBOX_ID, sinceModSeq + 1] and [MAILBOX_ID, max_int]). We sort these entries together according to the sort order the user has requested, normally date descending:

mailboxRecords.sort(
    (a, b) =>
        b[DATE] - a[DATE] ||
        (a[EMAIL_ID] < b[EMAIL_ID] ? 1 : a[EMAIL_ID] > b[EMAIL_ID] ? -1 : 0) ||
        a[ADDED_MODSEQ] - b[ADDED_MODSEQ],
);

Then we can iterate through to calculate what has been added or removed from the query, like so. (“Exemplar” is our term for the email that’s representing a thread when the “collapseThreads” argument is true.)

let index = -1;
const seenExemplar = collapseThreads ? new Set() : null;
const seenOldExemplar = collapseThreads ? new Set() : null;
let uptoHasBeenFound = false;
let total = 0;
const added = [];
const removed = [];
for (const record of mailboxRecords) {
    const isDeleted = !!record[REMOVED_MODSEQ];
    // Created and deleted after our previous state? Ignore.
    const isNew = record[ADDED_MODSEQ] > sinceModSeq;
    if (isNew && isDeleted) {
        continue;
    }

    // Is this message the current exemplar?
    let isNewExemplar = false;
    let isOldExemplar = false;
    const emailId = record[EMAIL_ID];
    const threadId = record[THREAD_ID];
    if (!isDeleted && (!collapseThreads || !seenExemplar.has(threadId))) {
        isNewExemplar = true;
        index += 1;
        total += 1;
        if (collapseThreads) {
            seenExemplar.add(threadId);
        }
    }
    // Was this message an old exemplar?
    // 1. Must not have been added to mailbox after the client's state
    // 2. Must have been removed from mailbox before the client's state
    // 3. Must not have already found the old exemplar.
    if (!isNew && (!collapseThreads || !seenOldExemplar.has(threadId))) {
        isOldExemplar = true;
        if (collapseThreads) {
            seenOldExemplar.add(threadId);
        }
    }

    if (isOldExemplar && !isNewExemplar) {
        removed.push(emailId);
    } else if (!isOldExemplar && isNewExemplar) {
        // If the message has been moved out and back in again
        // we'll have separate mailbox records for added/removed
        // so not detect it's both the old and new exemplar;
        // check for that here.
        const removedIndex = isMutableSort ? -1 : removed.indexOf(emailId);
        if (removedIndex > -1) {
            removed.splice(removedIndex, 1);
        } else {
            added.push({
                index,
                id: emailId,
            });
        }
    }

    // Special case for mutable sorts (based on isFlagged/isUnread)
    if (isMutableSort && isOldExemplar && isNewExemplar) {
        // Has the isUnread/isFlagged status of the message/thread
        // (as appropriate) possibly changed since the client's state?
        // If so, we need to remove the exemplar from the client view
        // and add it back in at the correct position.
        const mayHaveMoved = collapseThreads
            ? threadChanged.has(threadId)
            : emailChanged.has(emailId);
        if (mayHaveMoved) {
            removed.push(emailId);
            added.push({
                index,
                id: emailId,
            });
        }
    }
    // If this is the last message the client cares about, we can stop
    // here and just return what we've calculated so far. We already
    // know the total count for this message list as we keep it pre
    // calculated and cached in the Mailbox object.
    // However, if the sort is mutable we can't break early, as
    // messages may have moved from the region we care about to lower
    // down the list.
    if (!isMutableSort && !isNew && emailId === upToId) {
        uptoHasBeenFound = true;
        break;
    }
}

Mail search

Fastmail supports an extremely powerful set of search operators, allowing for fast, precise searching. We support almost all of it offline, with a few caveats discussed below.

To make full-text search work and be performant, we need to build another index. If you have hundreds of thousands of messages, it would be unusably slow to scan through all of them looking for a word, phrase or email address.

Our index is stored in another IndexedDB object store called EmailSearch. The key for each entry is [token, emailId]. The token is usually a word or other sequence of letters and numbers extracted from the email. We also have special token variations to represent a list-id or email addresses found in the headers. We create an entry in EmailSearch for each such token we find in the email. The value encodes where the token was found (e.g. in the To header, or the message body), and the index(es) of the token so we can do phrase searches.

We decided to index the content on the device, rather than download the indexes from the server. This ensured our search index would be completely in sync with the cached messages you have on your device, and we could index and make searchable messages and memos you wrote while you were offline.

However, this does mean the offline search works a little differently to our server-based search, so may return slightly different results (although we think both will do a great job in most cases). In particular:

Our offline search doesn’t index any text inside attachments. When online you can search for content in attached PDFs, spreadsheets, and other documents.
Our offline search doesn’t do stemming. Stemming tries to reduce a word to its common root, so if you search in English for bus you would also match emails containing buses, but not business. Stemming requires language analysis of the email content and custom stemming algorithms for each language, and we decided the extra complexity and code download size was not currently worth it for our offline search. Instead, our offline search does prefix matching by default, so bus will still match buses but also business. Of course, if you wrap the term in quotes (like "bus") it will only look for exact matches, just like with server-based search.

And of course, the search index will only contain messages you have downloaded for offline, which might not be everything in your account. We therefore try to do a search on the server first and only fallback to the local search if you are offline.

Search tokenisation

To create our index we have to be able to extract the tokens from a sequence of text. We have users around the world, so we knew we had to handle multilingual text and scripts. In the end, we settled on a simple but effective tokenisation algorithm:

We normalise the string into Unicode NFKD normal form. This will decompose diacritics to make it easy to strip them, and replace various variations of letters and numbers (such as typographic ligatures, or subscript numbers) with the baseline equivalent.
We divide the string into segments according to the Unicode text segmentation word boundary algorithm.
For each segment, we apply the full Unicode case folding substitutions (for example, this will replace uppercase letters with lowercase for Latin text), then we strip every code point that’s not categorised by Unicode as a number, letter, joining punctuation, or emoji.

If we have anything left, that’s our token. So to give an example, supposing we had the text:

The café is über cheap — only $3.60 a ☕️!!

We would end up with the following tokens:

the
cafe
is
uber
cheap
only
360
a
☕️

Wrapping it up

We now have the indexes we need for fast, precise search. There’s still a lot of work involved in putting it all together though! When you search for something complex like in:inbox from:@example.com (is:pinned OR "very important"), we analyse the query to work out which indexes to use and efficiently combine them to compute the results. The speed will depend on how much mail you have—and how fast your device is!—but we believe it lives up to the Fastmail promise of great search everywhere.

There’s so much interesting tech behind our offline support, but for now I need to stop writing. If you’ve read all of this mini series on how we are making our app work offline: thank you, and I hope you found it interesting! Please give the beta a go, and let us know any feedback you might have. We’re excited to finish polishing this highly requested feature and we hope to ship it to everyone early in the new year.

Dec 18: Building offline: syncing changes back to the server

2024-12-18T00:00:01Z

This is the eighteenth post in the Fastmail Advent 2024 series. The previous post was Dec 17: Building offline: general architecture. The next post is Dec 19: Building offline: mail storage.

Yesterday, we looked at how our offline caching layer fits into our app, and the way it stores data to efficiently respond to JMAP requests. Today, we’ll dive into how it keeps track of changes the user makes while offline, so it can reconcile this with the server.

Keeping track of changes

When a client makes a change offline, we update our local cache and have to keep track of it so we can sync that change back to the server when we come online. There are two main approaches you could take:

You keep a time-ordered log of every change, then replay the log against the server. One record may appear multiple times in the log if it has multiple modifications applied.
You keep a set of created/updated/destroyed records, along with the current server value. Each record can only appear once, in at most one of these categories. You calculate the difference between the server state and the current state to update the server.

The benefit of the first approach is it ensures we maintain any ordering dependencies. The benefit of the second approach is it’s more efficient in terms of both storage and synchronisation speed when there are multiple changes made to the same record.

The Fastmail offline cache uses a hybrid of these approaches to try to get the best of both worlds:

A log stores (in order) the [data type, account id, id] of any changes, along with what type of change this is (create/update/destroy).
The record itself stores the last known server state if it’s been updated, stored efficiently as a patch to get back to the server state from the updated state.
If the record is updated a second time, it:
- stays in its current position in the log if not yet present on the server (this is a create); or
- moves to the end of the log (remove the old entry and add a new one) if it already exists on the server (this is an update/destroy); or
- is removed entirely from the log if the change reverted it back to the last-known server state.

If we’re updating a record that’s not yet been created on the server, we may have to do an update as well as a create, due to an ordering problem. For example, suppose you do the following:

Create Mailbox X
Create Emails A & B in Mailbox X
Create Mailbox Y
Move Mailbox X to be a child of Y
Move Email A to be in Mailbox Y

You can’t move (a) later because (b) depends on it. You can’t move (d) earlier because it depends on (c). So if we update a record that’s not yet been created on the server, and we set a property that includes a local id (i.e., it references another object that’s been created locally but not yet synced to the server), we add it as a patch and apply it as an update later.

When loading data from the server, we do not need to look for an entry in the log of changes still to sync. We can just update the server state in the record. If the change is now inert, we’ll delete it from the log when we go to sync it.

For example, suppose we have a mailbox, id 1, with two messages in it, ids A & B, and the user does the following (contrived) actions:

Creates a new mailbox: 2
Creates a new child mailbox of that: 3
Moves A and B into mailbox 3
Marks B as read
Moves A back to its original mailbox.
Renames mailbox 2.

Our log will end up looking like this:

    [Mailbox, "#2", CREATE]
    [Mailbox, "#3", CREATE]
    [Email, "B", UPDATE]

Because A is back to its original state, we’ve eliminated it entirely from the log, and do not need to send anything to the server. Because #2 was a create in the log, we do not move it when we renamed it at the end, which is good because otherwise the other changes in the log would both fail as they depend on it. Despite making two changes to B, we only have to send a single update to the server for it.

Conflicts

Suppose you have a shared contact, let’s call him Joe Bloggs. While offline you edit to add his phone number. Meanwhile, a colleague updates his email address. This means when your client comes back online and synchronises the changes, the object it is updating has already changed. This is called a conflict.

For the data types we have to handle, we believe automatic resolution (rather than presenting the conflict to the user and asking them to choose what should happen) is the right way to go. We follow these simple rules:

Last write wins.
All updates are patches.

This means if the same object is updated by two different people, whichever client writes second will overwrite the data of the one that wrote first. (The first client will then sync this change back so you get a consistent state.) However, since all updates are patches, it will merge the changes unless they apply to the same property on the object. So in the case above, although there were two writes to the same contact, they were updating different properties. One user was updating the “emails”, the other the “phones”. So in this case, both changes would be preserved.

Next up, mail storage

In this post we looked at how we store changes you make offline so we can accurately and efficiently sync them back to the server when you come online. Like our discussion of data storage yesterday, everything here applies generically to all data types.

Tomorrow, we’ll discuss why email is special, and what else we do to make this super fast in our offline store.

Dec 17: Building offline: general architecture

2024-12-17T00:00:01Z

This is the seventeenth post in the Fastmail Advent 2024 series. The previous post was Dec 16: Offline support now in public beta. The next post is Dec 18: Building offline: syncing changes back to the server.

Yesterday we announced full offline support for Fastmail is now available in public beta, both in our app and on the web. Today, and over the next few days, I’ll dive into some of the technical aspects about how we’re making this work.

Making Fastmail work offline has been our most popular feature request for some time (ever since we added support for custom swipe actions, our previous top request!), and we wanted to make sure our support was done right. It should just work, seamlessly, and as far as possible you should be able to do everything you can do online. Open your calendar and update an event, perhaps inviting someone using autocomplete from your contacts. Search your mail and triage it. Write a new note. Add a memo. We want it all to just work.

When you come online it should seamlessly sync these changes back to the server, and fetch any new mail and other changes.

General architecture

The Fastmail app is very cleanly separated from our server, which was a huge benefit when adding offline support. All data in the app is loaded via a JMAP API, with all UI rendering and routing happening in the app. This means the data flow looks a bit like this:

[App] ← JMAP → [Server]

This gave us a really well defined boundary on which to build the offline support. If we built something that could handle and respond to the JMAP requests directly on your device then the app would work offline, and we wouldn’t really have to change anything else in it. So the architecture we came up with looks like this:

[App] ← JMAP → [Caching layer] ← JMAP → [Server]

Looking at our new diagram, we can see that we are building two things:

A JMAP server that can understand the requests the client makes, fetch and write the data from/to a local store, and return a JMAP response.
A JMAP client that can fetch data it doesn’t have from the server, and write back changes made while we were offline.

This is actually quite a lot harder than just building a JMAP server! We will often only have partial information, and we have to transparently pass through requests for data we don’t have to the server, and gracefully handle a fallback if we are offline.

The core function our caching layer needs to perform is handling a JMAP request from the client. Each JMAP request is a sequence of method calls. Once we have locally cached data, we may be able to handle the method call entirely locally, but we may always run into one or more that we can’t.

For performance, we want to batch our method calls into a single database transaction where possible. But we can’t hold open a transaction over a network request, so we divide up the execution into phases.

First, we attempt to execute the method calls locally. If all complete, we’re done! If any require us to fallback to the server, we stop and send it everything from that point on, as we want to avoid making multiple HTTP requests, which would be slow.

If the request completed successfully, we process the responses to save any new data into our local datastore. If the request failed, we call the offline fallback methods, which may be able to still return a response to the UI.

A separate thread for the caching layer

The caching layer runs on your device, just like the rest of the app. Because JMAP requests are already asynchronous network calls from the UI, we can easily run the caching layer in a separate OS thread so it never blocks the UI thread, which could cause jank.

Our app is built using web technology, which allows us, as a small company, to build an app that runs everywhere our users are, with a single code base and feature parity across all platforms. Separate threads are represented as workers in the web API. There are three types of worker:

Dedicated worker — this is a worker that is tied to a particular window or tab in your browser. If you have Fastmail open in multiple tabs, each would have to create its own worker.
Shared worker — this is a worker that’s shared between tabs or windows, so no matter how many you have there’s only a single instance of this worker.
Service worker — this is a special type of shared worker that can intercept network requests and change their response.

At first glance, a service worker seems the place to handle all of this, and this is what we tried first. However, we soon switched over to using a shared worker instead:

The service worker is designed to be short lived and only spun up when needed, but we wanted to hold open a persistent EventSource push connection while the app is open, for instant updates. The shared worker is a better conceptual fit for this.
We don’t need to intercept network requests, as we can just pass the JMAP request object directly to the worker using the postMessage API, avoiding some serialisation overhead.
We ran into a bug in iOS where network requests would sometimes not be intercepted even though the service worker was registered when the app was running in the background. This meant we had to pass the request directly to the worker anyway instead of intercepting it at the network level to ensure we didn’t hit this bug.

We wanted to use a shared worker rather than a dedicated worker for more efficiency when there were multiple tabs open — we can avoid some contention and locking issues, and ensure we have a single push connection open to the server.

Storing data: IndexedDB

The web API for storing large volumes of structured data is IndexedDB. This lets you create multiple object stores (the equivalent of SQL tables), which offer simple key-value storage with ordered keys. Indexes can be automatically built based on properties in the object being stored. Transactions ensure data consistency.

The IndexedDB API was unfortunately designed just before promises became ubiquitous in the web world. This means just fetching a record from a store requires code a bit like this:

const request = store.get(id);
request.onerror = () => callErrorHandler();
request.onsuccess = () => {
    const record = request.result;
    // Do something
};

This is clunky and becomes hard to read and follow. However, we wrote one tiny little wrapper function that converts it into a promise-based API:

const _ = (request) =>
    new Promise((resolve, reject) => {
        request.onsuccess = () => resolve(request.result);
        request.onerror = () => reject(request.error);
    });

Using this function, we can rewrite the above fetch like this:

const record = await _(store.get(id));
// Do something

(Note, if the fetch has an error this will result in an exception being thrown, which is generally handled at a higher layer, so avoids that cluttering our code here at all!)

With this simple addition, I found the IndexedDB API consistent and easy to work with.

The standard object store structure

The consistency of JMAP means we can write one generic implementation and then use it to provide offline support for all our data types. For each data type (such as Calendar, Email, Contact, etc.) we create an object store to store the instances of that type.

When we create the object store we also store a single metadata object in it, using a special key (a zero-byte ArrayBuffer). This stores some important bookkeeping information, in particular the following properties:

// Do we have the full set of data from the server for this data
// type?
hasAllRecords: false,

// State string representing the current server state we have
// synced with. The store may also contain newer information, but
// that's ok as it will still get to the correct state when we
// update from the old state.
serverState: '',

// This is the highest modseq of a record in the store.
lastModSeq: 0,

// This is the highest modseq of a record that was destroyed that's
// now been removed entirely from the store; we can only calculate
// changes accurately from this point on.
highestPurgedModSeq: 0,

// This is the number of records currently marked destroyed in the
// store. We keep them there so we can calculate changes. Once we
// cross a threshold, we'll clean up old ones.
numDestroyed: 0,

A key concept here is modseq, which stands for “modification sequence”. It’s a counter we keep per account, per data type. Every time we make a change to a record in our local store we bump the sequence number and assign that as the new “updated” modseq for that record. We also store a “created” modseq on each record, which is the same as the “updated” modseq when the record is first created. These simple bookkeeping properties allow us to efficiently calculate changes, as needed for the JMAP “/changes” method.

Aside from the metadata object, every other entry in the object store is a record — an instance of that data type.

The key for each record is [account id, id], because some data types exist in multiple accounts (e.g. shared contacts and your personal contacts) and ids are only unique within an account. As far as I could see from inspecting the source, string keys are stored as UTF-16 in all major IndexedDB implementations. This is a fairly inefficient encoding, especially as we know JMAP ids can only use the base64url characters, so for efficiency we encode this data into an ArrayBuffer, making use of this fact.

The value associated with the key is the record itself — an object representing an instance of that data type, as fetched from the server. In addition, we add a few bookkeeping properties, as discussed above:

The created modseq
The updated modseq
Is the record destroyed?

Each object store has an index built automatically based on the updated modseq of the records.

The modseq is used as the “state” string over JMAP. When asked for what’s changed since a particular state, we know:

Only records with a higher modseq have changed (which we can efficiently get from the index).
If the record’s created modseq is higher than lastModSeq, it’s new. Otherwise it’s been updated or destroyed (depending on whether the record is now destroyed). If it’s new and also destroyed, we can ignore it entirely.

Next up, local changes

In this post we looked at the basic overview of how our offline caching layer fits into our app, and the way it stores data to efficiently respond to JMAP requests. Tomorrow, we’ll dive into how it keeps track of changes the user makes while offline, so it can reconcile this with the server.

Dec 16: Offline support now in public beta

2024-12-16T00:00:01Z

This is the sixteenth post in the Fastmail Advent 2024 series. The previous post was Dec 15: Platform Team working agreement. The next post is Dec 17: Building offline: general architecture.

On an aeroplane, or down a tunnel. Roaming in a foreign land, or just out for a walk in the country. There are still times when we aren’t connected to the internet. As a strong supporter of open standards, you’ve always been able to use Fastmail with any email app you like, many of which work offline. However, many of our customers prefer the Fastmail app (we certainly do!), and offline support there has been our most popular request for some time. As Bron foreshadowed last year, we’ve been working hard on this big project for some time, and and we’re very pleased to announce it’s now ready for public beta testing.

What’s a beta?

Fastmail runs a beta version of our app to allow our users that like to live on the cutting edge to get early access to new features before they’re finished, and send us feedback while we’re still working on them. Things may be broken occasionally, but generally it’s pretty stable.

How do I get the beta?

If you are using our iOS or Android apps:

Check for updates in the app store — make sure you have the latest version.
Go to Settings → Device settings → Show Advanced Settings, and change the “server backend” to “Beta”.

If you are using Fastmail on the web, just log in at betaapp.fastmail.com.

In either case, once on beta you will find a new settings screen — Settings → Offline — where you can toggle on offline support. You must have ticked “Keep me logged in” when you logged in to enable offline support.

What can I do offline?

Almost everything! You can read mail, reply, view and edit your contacts/calendar, change settings, etc.…

Probably easier is to describe what won’t work offline:

Mail search will not look inside attachments, and will give slightly different results to when online. If you don’t choose to make every message available offline, it won’t be able to match against content it hasn’t downloaded!
Snoozed messages will not move back to the inbox while offline.
Calendar reminders will not show a notification.
You can’t delete attachments.
You can’t attach files to a message you are composing.
You can’t add or change users or domains, change your plan or update your billing details, or change your security settings.

How do I send feedback?

Found a bug? Got an idea? Something you like, or don’t like? Let us know! Our support team will pass all feedback on to the product team. We promise we read and carefully consider it all.

What’s the tech behind your offline support?

Interested in the technical details? Over the next few days I’m going to dive into how we built offline support into our app, starting with the general architecture.

Dec 15: Platform Team working agreement

2024-12-15T00:00:01Z

This is the fifteenth post in the Fastmail Advent 2024 series. The previous post was Dec 14: On-call systems. The next post is Dec 16: Offline support now in public beta.

Another Sunday, another document from our internal collection!

Over the past couple of years, we’ve been taking the bits that we like from scrum, agile, and all the other buzzword methodologies that are out there. One of the best things that all the good frameworks to is give a space for setting behaviours for ourselves and each other within a team — so you know what to expect from your colleagues, and also what they expect of you!

I posted about our Mission Statement and Guiding Principles already, now we narrow down to look at a single team. Our platform team maintains the infrastructure that the Fastmail product runs on top of.

We started from here:

Principles and duties

We are lifeguards:

We watch out for upcoming risks and for systems in distress.
Part of our day is keeping a watchful eye and scanning for strangeness and hints of something going down.

We are first-aiders:

When something goes wrong, our first principle is to keep the patient alive
For Fastmail: the patient is the data stored on our systems; the data we store on the behalf of others. This is a higher priority than uptime.

We are paramedics:

We do more than just keep the patient alive! We perform surgery and repairs to the level of our ability.
For more complex things, we stabilise and bring things to the specialists in that system to make more permanent repairs.
We get the service back up for as many as possible, as quickly as possible, without compromising data.

We are specialists:

For the basics of first aid and early response, we all need to become experts - and we all need to be vigilant.
But; we all have our areas of specialty, and it’s OK to lean into that!

The duties of a platformer:

Monitoring - looking at the alert emails, the metrics, etc and making sure things are nominal.
First-aid first - if the platform is in crisis, drop everything and fix it. This is the oncall duty, we all do this.
Janitorial - mop the floors, oil the joints, replace worn parts. We all do this, on rotation and as we see things. We keep the ship ship-shape.
Initiatives - look into possible improvements, experiment with possibilities, and build the future. Everyone should have an initiative they are leading or collaborating on. These make progress in the time we’re not doing first-aid or janitorial work.

A platform team shouldn’t be particularly busy. The first-aid and janitorial work should not be a large chunk of your day most of the time.

Everyone on the platform team is an experienced and senior Platform Engineer, though most of the current team are quite new to Fastmail, which is why I’m also embedded with them as the crusty old expert who knows where many of the bodies are buried!

Since the team is split between USA and Australia; we only spend an hour of dedicated synchronous time per week. So we brought everyone together in Melbourne in November, and came up with the following schedule and working agreement:

Over each 4 week period, this includes two set of task list gardening, two technical deep-dive sessions, a retrospective where we can change how we operate as a team! One member of the team runs all the ceremonies for a 4 week period, and hands off after the retrospective.

Working Agreement

We value action, forward progress and take ownership of tasks

We learn from each others successes and mistakes, and use good processes to protect ourselves from human error, always asking how we can be better.

We give and seek feedback, and encourage asking questions (no dumb questions)

We generate discussion and directional buy in, and make time per site for mobbing/pairing and getting clarity on solutions.

We celebrate our successes and show them off to the rest of the company.

To resolve conflict we:

Check with the customer (the Fastmail product team) - what do they need?
Check with an area expert
Use experiments

To agree things we:

Make solo calls if comfortable; or
Bring it ‘To Discuss’ - the fortnightly deep dive meeting

Dec 14: On-call systems

2024-12-14T00:00:02Z

This is the fourteenth post in the Fastmail Advent 2024 series. The previous post was Dec 13: It’s knot DNS. There’s no way it’s DNS. It is DNS! The next post is Dec 15: Platform Team working agreement.

After the scary interlude for Friday the 13th, here’s a follow-up to our blog about support and on-call.

At Fastmail, we own and operate most of our stack, from networking gear and servers in the hosted datacenters we use, server OS setup, internal services, backups and redundancy, through to user-facing services and mail flow.

In the last post, we introduced our organizational model of how our support and on-call team manage on-call and incidents. In this blog post, we get a little more technical into the systems we use to help us do this.

How Incidents are raised

We source alerts from our service stack through a number of mechanisms:

Prometheus alerts for infrastructure and service metrics such as disk usage and replication delay
Logwatchers that alert on things like Cyrus errors
Cron scripts that run regular tests and alert on failures
Alerts from external monitoring

We’re currently experimenting with integrating all of these sources into a single observability stack (I’m a big fan of the unified observability model) - maybe you will read about that in next year’s advent blog post series!

But right now, all of these alerts go straight to Pagerduty to create an incident there.

Our support team and any staff member is empowered to raise an incident at any time when they observe issues that indicate an infrastructure or service failure. This is done via slack pings during working hours, and otherwise by paging through our slackops bot.

Pagerduty alerts

Our Pagerduty on-call rotation and escalation process ensure that incidents are always promptly responded to.

The primary on-call engineer is also responsible for Business As Usual (BAU) tasks such as reviewing non-critical errors and escalations. When incidents have to be escalated past the primary on-call engineer, they go first to the team lead. This allows the on-call engineers that are off rotation to focus on project work during the day, and decompress outside of work hours without worrying about on-call.

In order to minimize the attention load of on-call alerts on the platform engineers, engineers can override the on-call schedule to take on-call when they do large deploys that result in alerts.

We have recently created a dedicated incident discussion channel. Previously, incident communication would take place either in the alerts feed channel, the “ops” channel where we post updates for visibility into changes and deploys, or in a team channel for the team principally responding to the incident.

A dedicated incident discussion channel removes incident discussion noise from other channels. We decided against going with the “create a dedicated channel for every incident” as we think this would create too much churn and reduce visibility.

Outage notifications

When our service is experiencing issues or outages, we want our users to know as soon as possible, both for their benefit and our support team. As we have support staff on shift 24/7, they handle outage notifications via our status page on https://fastmailstatus.com/, Zendesk banners, and posting on our social channels. During incidents, they act as the communication conduit to our users - ascertaining the extent of outages, ensuring timely updates, and checking that when services are restored this is reflected in user experience.

Pagerduty nitty-gritty

Some of the things we do to automate and simplify our life as on-call engineers butt up against the limits of Pagerduty.

For example, it would be nice to have an empty escalation layer as the first layer that during normal times falls through to the next layer instantly. Then people can add themselves in this layer to override the on-call escalation chain for doing deploys. However Pagerduty does not allow this so we have to override the schedules for primary on-call instead.

We also have regular unavailabilities during the week for on-call engineers for scheduled events such as gym training or dance classes. For this, we want to add exclusions to the schedule so that the alerts go to the fallback on-call immediately.

These unavailabilities are different for every individual engineer. Pagerduty doesn’t allow to model this - on-call schedules can have almost arbitrary scheduling through weekdays, but this is per schedule and not per on-call user. So we have to split the schedule and make a separate schedule for every engineer. However, we then can no longer make a rotating schedule - inside one schedule, a user can’t be on for a week and then off for a week - unless that off week is taken by another user.

To work around this we have created (and paid for) a “Blank” dummy user that has no contact methods and is only there to fill the off week for a user.

As you can see in the picture, there are 3 layers in the schedule: The first layer is a base layer that is a weekly rotation between the fallback engineer and the Blank user.

The second layer has the primary oncall engineer’s shift for the first half of the day, and the third layer has the second half of the day. This is also in a weekly rotation between the oncall engineer and the Blank user.

To understand what’s going on here, imagine that the primary oncall engineer needs to be offline every monday from 4PM to 6PM. For that, we put an 8AM - 4PM shift time for every monday in the second layer, and 6PM to 10PM in the third layer. During the 4PM to 6PM time, there is no on-call user in the second or third layer, so it falls back to the base layer and so the fallback engineer will be active.

Finally, we make a separate schedule for every on-call engineer following the same pattern, but offset by one week.

What works well

I have done overnight on-call at previous companies and that is a lot more stressful. I definitely think being able to split on-call is a lot better for engineers’ quality of life!

We have ops tools to do things like log searching, show replication stats, grafana dashboards, and prometheus alerts that give us quick insights into the state of our infrastructure and services to pin down the root cause of an incident quickly. These could be more comprehensive and better organized but they work well.

We have runbooks for some, but not all, alerts. Where they exist they are quite good and comprehensive and we frequently review and update them after incidents.

What could work better

Most of our incidents auto-resolve when the service / monitor returns to nominal service. This is good! We are lucky to have very few flappy alerts that bounce up and down.

But a handful of alerts do not auto-resolve because the alerting mechanism is not stateful. This is confusing for engineers, and it is an extra annoyance to clean up alerts after an incident.

We don’t currently have good categorization and prioritization of alerts. The only way to know whether an alert is important or not is to know from experience, or asking someone with experience. We need to spend more time and be more ruthless in weeding out low-quality alerts!

Fastmail Blog

Multi-window support and a better compose experience

Multi-window support

Inline replies

A cleaner compose

Move the reading pane below your inbox

And more

Why customers trust Fastmail

You’re the customer, not the product

Real humans, real support

History — we have been around since 1999, and we aren’t going anywhere

Innovative features such as Masked Email and aliases changed the way many people manage their online identity

Speed and usability — “It is fast, clean and just works”

Open standards mean freedom

Why does any of this matter?

Safer Internet Day: Why your search engine matters more than you think

The ‘search’ problem

Then there’s Kagi: Search that works for you

What makes Kagi different?

Completing your privacy stack

How it works

Ready to build your privacy stack?

Final thoughts

Special offer for Fastmail customers

Being better with passwords

How to be better with passwords

What is a password manager?

The zero password future

How does Fastmail work with 1Password?

When many isn’t better than one: Managing your life with Fastmail and Morgen

The calendar multiplication problem

One view to rule them all

‘Time Blocking’: The adult version of planning your day

Your data, your rules

Making it ridiculously simple

Getting started takes only minutes

The Real Bottom Line

Understanding email encryption

What are you protecting against?

Encrypting the connection to your email provider

Encrypting email between servers

MTA-STS and DANE attempt to close the gaps

Encrypting email at rest

The trade-offs of zero-access encryption

End-to-end encrypted email

The necessary trade-off between privacy and security

Choosing your own balance

Fastmail’s ongoing approach to email and encryption

Introducing the Fastmail desktop app

This blog post was not written with AI

Your electronic memory

Adapting to a changing world

Our service, your data

Our staff, your privacy

The future

The Cache Crash

Work offline with Fastmail

How do I turn on offline support?

What if I don’t want offline support?

Is there anything I can’t do offline?

What’s the tech behind your offline support?

The new phishing: How to spot email scams in 2025

Your inbox is the key to almost everything you do online. No wonder scammers keep showing up

Today’s scams don’t always look like scams

Why even tech-savvy users fall for scams

1. They hijack our trust

2. They exploit urgency and FOMO

3. We’re experiencing cognitive overload

Email scam red flags to watch for in 2025

Your email scam defense stack: SaneBox + Fastmail

Fastmail:

SaneBox:

Better themes, better navigation, better search

Beautiful new themes

Faster navigation

Fine-tune your search

And more

Fastmail joins the Internet Society

Addressing Privacy Fatigue

Privacy fatigue is a real feeling — here’s how to make it manageable