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.

beta.fastmail.fm now redirects to beta.fastmail.com

In preparation for our our move to fastmail.com, we’ll be doing some testing on beta.fastmail.fm. So if you use the beta server, expect some changes and potential issues over the next few days.

Currently that means if you go to beta.fastmail.fm, you’ll immediately be redirected to https://beta.fastmail.com. This is expected. Note that you can’t currently create @fastmail.com aliases or rename your account to @fastmail.com. This is expected. This will only be available from Thursday as described in the original blog post.

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.

SSL 3.0 disabled due to security vulnerability

This morning Google published news of a new vulnerability in SSL 3.0. You can read more about it in the original announcement and in CloudFlare’s analysis of the problem.

This is a serious issue that can leak user data. Unfortunately there’s no workaround – the only option we have is to disable SSL 3.0 on our servers entirely. We don’t like having to do this because we want our users to be able to use any client they choose to access their mail, but when there’s a security hole and no way to plug it we have no choice but to break things for some people in order to protect everyone.

Happily, this should not affect the majority of our users. The only significant browser to be affected is Internet Explorer 6 on Windows XP, which will now not be able to connect to www.fastmail.fm at all. Similar changes have been made to our IMAP, POP and other backend services, so you may also have connection issues with older mail clients.

If you are unable or unwilling to upgrade your client software at this time, you can use insecure.fastmail.fm (web) and insecure.messagingengine.com (IMAP/POP/SMTP), both of which support SSL 3.0. As always, we highly discourage the use of these service names because they leave your data open to attack, and we may remove them in the future.

Update 16 Oct 2014 01:00 UTC: We’ve heard of at least two mail clients (Airmail and Windows Phone) that can receive but not send mail. Changing the outgoing settings to use port 587 instead of 465 has resolved the problem for some users. If you’re seeing similar problems, give that a try.

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)

FastMail changelog update

The following changes have been rolled out to production:

  • When you use FastMail’s nameservers for your DNS, one of the default records we publish is an SPF
    record. Until now, we’ve published this as a TXT DNS record type and a SPF DNS record type type.
  • SPF DNS record types have been deprecated (http://tools.ietf.org/html/rfc7208#section-3.1) for a while, so we’ve now removed the SPF DNS record type and are only publishing TXT DNS records types.
  • This shouldn’t affect anyone, but we’ve put up this post as informational for anyone experiencing some
    issue with ancient software or systems.
Posted in Feature announcement. Comments Off

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
Follow

Get every new post delivered to your Inbox.

Join 5,554 other followers