>That distinction matters to us. Our long-term values include “Your data belongs to you” and “We are good stewards of your data”. The pattern we try to follow is: rather than continuously reworking our UI to follow every new trend, we give you the interfaces to use your data however it suits you. MCP continues that pattern. It’s there if you want it, and nothing changes if you don’t.

This is really refreshing and makes me feel like I made the right decision in moving off Gmail after 20 years to Fastmail last year

The three-tier scope split (read / write / send) is also a nice middle ground between god-mode tokens and OAuth granularity nobody actually configures.

Open question this raises: does every vendor need to hand-roll an MCP server, or does the ecosystem settle on REST→MCP auto-wrapping over OpenAPI specs? We've been exploring the latter (open source: github.com/ChronoAIProject/NyxID). Fastmail-specific nuances like JMAP pushing vs polling probably justify hand-rolling for now, but the pattern doesn't generalize.

> The OAuth consent screen will give you a choice of three levels of access: read-only (see emails, contacts, calendars), write (update emails, save drafts, edit contacts and events), and send (send emails).

They can say it's optional and that I don't have to use it myself, but what if a user I've communicated with, who also has me in his/her/their contacts, decides to use MCP? Then my contact details and the content of my emails will also be read and used by AI.

Completely insane decision by Fastmail. They probably couldn't resist the hype.

As a Fastmail user from the very beginning (since 1999/2000), the day has come for me to say goodbye to them. I'm going to migrate to Migadu or Tuta.

using imap idle in our multiple helpdesks (i use for many different app supports)