FastMail handles sessions slightly differently to most other web services, and coincidentally I’ve had a few questions about this recently, so I thought I’d write a blog post explaining what we do.

For most web services, the concept of a session is something like this:

  1. A user goes to site for the first time in their
  2. The server detects that the user has no existing session cookie, so
    it creates a new session on the server, and sends back a cookie to
    the browser (simply a string) that uniquely identifies that session
  3. After that, for every page within the domain that the
    user goes to, the browser sends the cookie back to the server with
    every request, so the application can get the session data stored on
    the server

This process is very important, because it allows the server to keep track of things for each user separately, even though they’re going to the same hostname or url path.

Because each cookie is usually associated with a domain, that usually limits you to one session per domain. So for instance when you use google or yahoo, you can only every be logged into one account at a time. There are certain things that work around this, like Mozilla Prism, or Chrome Incognito Window, but these work by creating entirely separate cookie jars, so you can log into different accounts at the same time.

FastMail does things a bit differently. It starts off the same, so when you go to, it creates a new session and associated cookie. However when you login to your account, it does two things:

  1. It renames the cookie so the cookie itself has a unique name with a
    random value (we call this the cookie “salt”)
  2. It redirects you to a new URL that includes the salt value in the
    URL, and all further URLs as you move around the interface include
    this salt value

What this means is that if you go to and login, and then open a new tab, and go to again, you’ll see the login screen again, and be able to login to the same account or a completely different account, and happily access both accounts in the separate tabs with separate sessions at the same time without them affecting each other!

On top of that, FastMail tries to store most “state” information (such as which folder you’re in, what message you’re viewing, etc) in each URL rather than on the server in the session. What this means is that in many places, you can happily right-click a link and select “Open in new tab” or “Open in new window”, and although the newly opened tab/window will share the same session with the original tab/window, they won’t interact with each other.

For instance, if you go to your Inbox and read a message, and then right-click on the “Trash” folder and select “Open in new tab”, you’ll end up with a new tab looking at messages in the Trash folder. You can then switch between the first tab and second tab, moving between folders, reading messages, and neither action will affect what happens in the other tab. (There are a few small situations where this isn’t the case, but these are rarer used functionality, and most people won’t see it)

Session oddities

This difference in approach does result in some things being different to most other websites

  1. If you use the “Long term” login option on the login screen, that
    doesn’t actually mean you get a long term session (well, you do get
    an 8 hour session instead of a 2 hour session, but the fact it logs
    you in automatically forever is separate). Instead a separate cookie
    is stored on your machine with your username and encrypted password,
    and each time you go to, it creates a new
    login and new session
  2. Because of browser limits with the number of cookies you can have
    per-site, if you create many logins and many sessions (eg. open many
    separate tabs and login separately with each one), then we will
    start to expire old sessions to avoid you running out of cookies and
    new session failing. This starts to happen if you have > 10
    simultaneous session cookies, we’ll start to expire the oldest ones.
    This can manifest itself as tabs where you’ve definitely been idle
    < 2 hours suddenly reporting your session as “expired” on the next
    link/button you click

Most of the time users don’t need to know about or worry about any of this, things should “just work”, but there are some edge cases where knowing the underlying cause of things can help explain some odd cases.