FastMail has moved to fastmail.com, @fastmail.com email addresses now available

As discussed in a blog post earlier this week, we’ve now moved FastMail to fastmail.com. This means when you go to https://www.fastmail.fm, you’ll immediately be redirected to https://www.fastmail.com.

Does this affect my existing address or aliases?

Not at all, they will continue to function exactly as before. The only difference is the web address you’ll see in your browser when you log in to our website. This applies to all domains we host, not just @fastmail.fm.

How can I get an @fastmail.com email address?

With the exception of legacy guest and member accounts, you can add an alias (additional address) to your account, or you can rename your account to a new username @fastmail.com right now. Just go to https://www.fastmail.com, login to your account and go to Advanced -> Aliases to add an alias, or Advanced -> Rename account to rename your account.

All addresses are available on a first come, first served basis. We decided on this approach because we already offer many domains, so there might be joeblogs@fastmail.fm, joeblogs@fastmail.us, joeblogs@fastmail.net, joeblogs@myfastmail.com, joeblogs@eml.cc, etc. and we don’t think any particular user and any particular domain should get priority over another.

In the interests of fairness, we are only allowing each account to register one alias @fastmail.com. New users will be able to sign up an address @fastmail.com as well.

Email client users (e.g. Thunderbird, Apple Mail, Outlook, etc)

If you access your email through an email client, there’s no change. Everything will continue to work exactly as before.

FastMail is moving to fastmail.com

On Thursday, 23rd October 2014, we are moving the main FastMail website from fastmail.fm to fastmail.com. We intend to make the transition as seamless as possible, but we wanted to give you advance warning. Below are some more details for users regarding this change:

Email client users (e.g. Thunderbird, Apple Mail, Outlook, etc)

If you access your email through an email client, there’s no change. Everything will continue to work exactly as before.

Web interface users

If you use our web interface, from Thursday when you go to fastmail.fm you will be redirected automatically to fastmail.com. Any existing sessions will be transferred across, so if you were logged in at fastmail.fm, you’ll be logged in at fastmail.com. The only difference you should see is in the address bar in your browser.

Password manager users

If your password is normally filled in automatically for you by your browser or password manager, you’ll need to make sure you know what it is. For security reasons most password managers will only fill in your password on the domain where it was first used, and since we’re moving domains from fastmail.fm to fastmail.com, they’ll fail to work automatically. If you don’t know what your password is, we’ve got instructions on how to find it in all major browsers. Your password manager should prompt to save it again the first time you log in at fastmail.com, so don’t worry, you still won’t have to memorise it!

Does this affect my @fastmail.fm email address?

Not at all, this will continue to function exactly as before. The only difference is the web address you’ll see in your browser when you log in to our website.

How can I get an @fastmail.com email address?

With the exception of legacy guest and member accounts, you will be able to add an alias (additional address) to your account, or you will be able to rename your account to a new username @fastmail.com.

In the interests of fairness, we are only allowing each account to register one alias @fastmail.com. New users will be able to sign up an address @fastmail.com as well. All addresses will be available on a first come, first served basis, starting as soon as the transition to fastmail.com occurs.

When exactly will @fastmail.com email addresses become available?

An exact time on Thursday hasn’t been decided yet. Please keep an eye on this blog for further details.

New anti-phishing feature, all official FastMail emails have green tick mark

We’ve just rolled out a new feature that should help users identify official FastMail emails and avoid fake phishing emails.

All future official FastMail emails should now have a green tick next to them in the mailbox listing and when viewing the email/conversation. They look like this:

Screen Shot 2014-10-14 at 10.14.37 pm

Screen Shot 2014-10-14 at 10.17.52 pm

Users should be careful of any future emails that claim to be from FastMail that don’t have the green tick. These are almost certainly phishing emails that aim to steal your login details. Just report them as spam.

Note that the tick will only appear on future official FastMail emails, not existing ones. Also it only appears in the current web interface, not the classic web interface and not in external email clients (e.g. Outlook, Thunderbird, Mac Mail, etc)

Better security and privacy through image proxying

Today we rolled out a feature that enhances your privacy and security when you use FastMail: all off-site images embedded in emails are now proxied through our servers. Instead of your web browser going out to the wider internet to fetch an image in an email, it will request it securely from our servers and we’ll fetch the image on your behalf. (The original email is never modified, so if you forward it or view it in an IMAP client, it will appear exactly as we received it.)

When your browser requests an image (or any other page) it sends all sorts of information to the web server, including your internet address (which reveals your rough location), the type and version of browser you’re using, and sometimes even tracking cookies and other information that can help identify you. While these things are a fundamental part of how the web works and are difficult to avoid, we know that many of our users don’t like this information to be sent without their knowledge. That’s why we’ve always had protection against this by requiring you to explicitly request that images be loaded for an email.

Now though, we’ve gone one step further. When an image is loaded, the request goes only to our servers, which then go and request the original image. The request comes from the server’s address, with a generic browser type and version and no information at all that identifies the original email or the user requesting it. The image server remains in the dark about where the request came from. That’s a big plus for your privacy.

The other advantage of our new approach is that it removes the possibility of mixed-content warnings appearing in your browser while reading your email. Every web user has had it drilled into them for years that they should look for the padlock icon to know if the site they’re looking at is secure:

happy-proxy

But when you view an email with an image served from an insecure site (as most image hosting sites are), the browser changes the padlock icon to look like this:

sad-proxy

Since all images now come via our secure servers, the padlock will now always remain intact, giving you the confidence that no one is intercepting your data.

Edit: Clarified that the image server cannot see where the request came from. It may still be able to determine who the request came (ie email address validation) if the image URL has some kind of tracking data in it. Its still a marked improvement on not proxying at all, as it can’t be directly correlated with an internet address or other tracking data.

Posted in Feature announcement, News. Comments Off

Announcing the FastMail Calendar

After 9 months of intense work, we’re very proud to announce a major new addition to FastMail. We’ve taken all the great things about FastMail’s email hosting and applied them to build an awesome new calendar. You get the same incredibly speedy and elegant web interface. The same robust, fully-redundant backend (with live off-shore replicas). The same power behind an easy-to-use interface.

Our new calendar is packed full of the features you need to stay organised:

  • Continuous scrolling, because life isn’t broken into months.
  • Two-way sync with your existing Google or iCloud calendars.
  • A great experience on mobile browsers – just like with email.
  • Real-time updates, so changes are displayed immediately on all devices.
  • Multiple time zone support.
  • Powerful sharing options for easy collaboration.

We could go on, but really you should just try it for yourself. Head over to https://www.fastmail.fm and log in to your account, or if you don’t yet have one you can sign up for a free 60-day trial. Alternatively, find out more about what our new calendar can do by exploring our documentation.

A major addition like this would often be added as a separate service, but we’re delighted to announce that the new calendar will be available at no extra cost for all our paying subscribers. Most accounts also get CalDAV access included as well for syncing with your favourite mobile calendar app. More information about which accounts have CalDAV access
is available on our new pricing pages.

With contact synchronisation coming very soon now, we’re looking forward to meeting all your communication needs in one place.

We hope you enjoy using our new calendar as much we’ve enjoyed building it. As always, we’d love to hear what you think! Please let us know via support, twitter, etc.

The FastMail Team

Posted in News. Comments Off

Increased spam getting through for the last few days

Due to an undetected compatibility issue between some software modules we use for detecting spam emails, for the last few days a number of the tests we use to detect spam haven’t been working properly. This means that for the last few days, considerably more spam may have been getting through our filters and into users Inboxes.

We’ve now fixed this issue and have added additional tests to ensure this doesn’t happen again.

For those interested in the technical details: We upgraded to a newer version of Net::DNS and the version of SpamAssassin we use was using some internals from Net::DNS that had changed with the new version. This caused all RBL lookups to fail. Failing RBL lookups wouldn’t cause any email delivery to fail, just all RBL scoring to be ignored.

Posted in News, Technical. Comments Off

Making FastMail even more secure

We have a great responsibility at FastMail to keep your email secure. As part of our continual process to maintain and improve security, we recently made a number of changes. This blog post summarises what we’ve done and why it makes your email even more secure. It’s also a useful checklist of security measures to think about if you run your own web application.

This is a technical post for information only. You do not need to make any changes to your FastMail account or your email software.

Preventing cross-site logins

Cross-site request forgery is a common security problem on the internet. Briefly, if you are browsing a malicious website A, that page can make a GET or POST request to any other website B, which includes any authentication cookies you have for website B. The page making the request from website A can’t see the response, but if the request changes state on the server it could compromise the account, for example by forwarding all of your mail to the attacker’s account.

FastMail has long had robust CSRF protection throughout our application. However, one thing we didn’t protect from CSRF was the ability to log in to an account. At first glance, an attacker being able to log someone into the attacker’s own account doesn’t seem like much of a security problem. However, there are two issues that can arise from this:

  1. An attacker could manage to confuse the target into sending an email from the wrong account. This is easy to do if you’re not expecting yourself to be logged in elsewhere. The email could then be read by the attacker.

  2. Any stored XSS vulnerabilities that only affect the user’s account suddenly become much more exploitable. For example, suppose a user’s folder name was not properly escaped somewhere: it could be used to inject a script into the page. Since only the user can modify the folder name, and the pages that show that folder are only accessible when logged in as that user, this does not help an attacker target anyone but himself. However, if the attacker can log someone else into his account and force the script to run, then he could potentially access any other accounts that the target is currently logged in to.

Given these risks, we’ve now taken steps to prevent logging in to a FastMail account from anywhere other than our own login form. Since on the homepage we don’t yet have a session (at least not one that lives longer than a couple of minutes), we’re doing strict referrer checking instead of using a CSRF token. The “Referer” header in the POST request must be present and must match the protocol and host (normally https://www.fastmail.fm), otherwise the login is rejected. (And yes, the referrer header really was standardised with an incorrect spelling.)

Whilst there are several ways of stripping a referrer header, as far as we are aware there is no way to fake one without using a browser extension or the like (at which point the extension could do anything it likes to the page, and no amount of CSRF tokens is going to save you).

Moving all user websites on to user.fm

FastMail has long had a feature where you could host some files or a small website via your FastMail account. For the account joebloggs@fastmail.fm, for example, we offered the ability to host files at joebloggs.fastmail.fm.

Unfortunately, this provides another way to log a user into your own account, because cookies are not subject to the same security restrictions as other web features. A user webpage cannot read any of our session cookies (on the http://www.fastmail.fm subdomain), so it cannot steal a session, however it can write its own cookies to the fastmail.fm domain. There’s no way for our server to tell that these were not created by us on the http://www.fastmail.fm domain. If you log into your account on your computer, you could then take the cookie and write it to someone else’s computer via your website, effectively logging them into your own account.

To resolve this, we’ve moved all user content on to a new domain, user.fm, and set up redirects so existing URLs will continue to work. For example, joebloggs.fastmail.fm will now redirect to joebloggs.fastmail.fm.user.fm.

Please note: this does not apply if you have your own domain. That will continue to work just as before. The move is only for content at one of our domains.

Content security policy

Cross-site scripting (more commonly known as XSS) is by far the most common type of security vulnerability to occur in web applications. An XSS vulnerability allows an attacker to inject a script into a web page on the target site, allowing them to access any data the user is currently authorised to access.

Arguably one of the biggest steps towards improving the security of web applications in recent years is the introduction of the Content-Security-Policy (CSP) header. You can use this to control what resources a modern browser will allow the webpage to load and run. We’ve been testing this on our beta server for some time, and we’ve now rolled it out to production. The CSP we are using for most of our webmail pages is the following:

default-src 'self'; script-src 'self' 'unsafe-eval' https://api.pin.net.au;
style-src 'self' 'unsafe-inline'; font-src data:; img-src *;
media-src 'none'; object-src 'none'; report-uri /log/csp

The most import thing about this policy is that it does not allow inline scripts to run, or for scripts to load from domains other than our own (with a specific exception for our payment provider). This means that should a future XSS bug be discovered, an attacker cannot exploit it against you if you are using a modern browser: the only scripts that can run are those hosted on our own domain (which are all written by us and known to be safe).

The other big change we’re going to be making next week is to move most user content off the fastmail.fm domain. When you open an attachment it will load in the fastmailusercontent.com domain instead. This is an isolation measure to provide an extra layer of security via the browser cross-origin restrictions. At the moment, we use a Content-Disposition: attachment header to force the browser to download rather than open any potentially dangerous files (all files except for a few specific safe MIME types such as JPEG images). Because each attachment will be isolated on a different domain (with a per-message authorisation key), we will also be able to allow more types to be opened in the browser, as each attachment is effectively sandboxed and cannot access sensitive data.

Bug bounty

Like many other internet companies, we recently introduced a security bug bounty program as a way of encouraging responsible disclosure and rewarding security researchers for their hard work.

We’d like to say a public thanks to the first two recipients of our bounty: Prasant Sharma for disclosing a stored XSS vulnerability in our support ticket system, for which we awarded $1000, and V. Harish Kumar for finding two minor self-XSS vulnerabilities, for which we awarded $200.

We welcome all whitehat security researchers who wish to help us maintain our high security. Full details of the rules and how to submit a vulnerability are available on the security issue reporting guidelines help page.

Other measures already in place

The following additional security measures have been in place for some time, but we’ve not blogged about them before.

Secure, HTTP-only cookies

All session cookies are marked “Secure” and “HTTPOnly”. This means the browser will not send them over an unencrypted connection, and they can not be read using JavaScript. This means that should an XSS attack occur, the attacker can only steal data whilst the page is still open on the victim’s computer: he cannot steal the cookie to transfer the session to another computer.

HTTP Strict Transport Security

We send the following header back with all of our responses:

Strict-Transport-Security: max-age=31536000

This tells all modern browsers to, from that point on, only connect to us over HTTPS, even if the user types in a non-HTTPS URL. This reduces the chance of a man-in-the-middle attack intercepting an insecure connection and proxying the user, instead of redirecting them to the secure site.

Frame protection

With basic support even in browsers as old as Internet Explorer 8, the X-Frame-Options header is the easiest and best way to prevent click-jacking and other attacks based on embedding your web app inside a malicious site. By setting the header X-Frame-Options: SAMEORIGIN, we only allow our pages to be framed by other pages on our domain.

Disabling content type sniffing

Content type sniffing is where browsers ignore the MIME type sent by the server and interpret the content as something else. This can be dangerous, as something that the server thought was safe (such as an image) could be interpreted by the browser as an HTML page, opening you up to XSS attacks. We disable this behaviour by setting the X-Content-Type-Options: nosniff header.

Working towards a secure web

We strongly believe in making the internet more secure, and one of the ways we feel we can help make this happen is to publicly document more of the security measures we have in place. This serves to both help educate and inform other sites, and to allow public scrutiny to improve our processes.

Thanks for reading, and as ever, thanks for using FastMail.

Posted in News. Comments Off
Follow

Get every new post delivered to your Inbox.

Join 5,554 other followers