FastMail’s servers are in the US: what this means for you

As you may be aware, there have been many reports recently of secret data mining programs conducted by the US government. These reports have included mention of secret network interception and “backdoor” access to private email accounts. While we have no position on the veracity of these claims, we have had many queries about what, if anything, this might mean for us and for our customers, given that our primary servers are located in the US. This is our response to those questions.

As noted in our recently updated privacy policy, we are an Australian company subject to Australian law. We are required to disclose information about specific individual accounts to properly authorised Australian law enforcement with the appropriate supporting documentation, which means a warrant signed by an Australian judge. We do not co-operate with any kind of blanket surveillance, monitoring or “fishing expeditions”, and we do not give out user information to anyone outside Australia.

There are some rare cases of overseas entities applying to Australian authorities for information under a Mutual Assistance treaty. In that case proper Australian documentation must be issued before we will do anything. These cases are particularly rare because the burden of proof required is very high, and the chain of events is very long (ultimately, each case currently requires sign off from the Australian Attorney General). The Mutual Assistance treaties also have (amongst other things) a test of whether the putative offense would be illegal in Australia, not just in their country of origin.

Australia does not have any equivalent to the US National Security Letter, so we cannot be forced to do something without being allowed to disclose it.

It has been pointed out to us that since we have our servers in the US, we are under US jurisdiction. We do not believe this to be the case. We do not have a legal presence in the US, no company incorporated in the US, no staff in the US, and no one in the US with login access to any servers located in the US. Even if a US court were to serve us with a court order, subpoena or other instruction to hand over user data, Australian communications and privacy law explicitly forbids us from doing so.

It might be possible for the US government to lean on the Australian government or other international legal body to compel us to hand over data but this likely to be an expensive, time-consuming and highly visible process. In our opinion those barriers make it extremely unlikely to happen.

There are of course other avenues available to obtain your data. Our colocation providers could be compelled to give physical access to our servers. Network capturing devices could be installed. And in the worst case an attacker could simply force their way into the datacentre and physically remove our servers.

These are not things we can protect against directly but again, we can make it extremely difficult for these things to occur by using strong encryption and careful systems monitoring. Were anything like this ever to happen we would be talking about it very publically. Such an action would not remain secret for long.

Ultimately though, our opinion is that these kinds of attacks are no different to any other hacking attempt. We can and will do everything in our power to make getting unauthorised access to your data as difficult and expensive as possible, but no online service provider can guarantee that it will never happen.

As a customer, you need to weigh the benefits of keeping your data with us against the risks of that data being disclosed. You may wish to obtain private legal advice to help you assess that risk. And if you come to the conclusion that keeping your data with us is too risky, then we respect that (though please do tell us why!)

If you have any further privacy concerns we haven’t addressed, please email privacy@fastmail.fm.

Posted in Uncategorized. Comments Off

Google Authenticator now supported for two-factor authentication

FastMail has long supported various methods of two-factor authentication for additional account security, from generated one-time-passwords, to SMS, to Yubikey. Today we’ve added another method to our stable – the Google Authenticator method, otherwise known as Time-based One Time Passwords (RFC 6238). With this you can use your iOS, Android or almost any other mobile device as your second factor when authenticating, increasing the security on your account without requiring you to carry an additional object around with you.

A Google Authenticator alternative login can be configured in the Alternate Logins section of your account settings screen. If you’re using the official Google clients, then you can use its support for QR codes to make setup super-easy. You can however choose to use any number of other clients that support this authentication mechanism; all will work with our implementation.

Please refer to our Google Authenticator help page for more details.

Posted in Uncategorized. Comments Off

Changes to webmail login

TL;DR: We’re now making all connections to the Fastmail web interface immediately redirect to a secure (https) connection.

As part of our commitment to making all connections between users computers and our servers secure and encrypted, we’ve just made some changes to our webmail login page. In most cases, users won’t notice any change because we made Secure Login the default almost a year ago. The new changes will only affect the small number of users that have special login requirements.

The main change we’re making is that where previously we would redirect from an insecure (http) to secure (https) connection during login, or on returning to Fastmail on a computer you’d logged in via before, we will now redirect to the secure login screen immediately when you connect to Fastmail. That is, as soon as you go to http://www.fastmail.fm (insecure) or http://www.sent.com (insecure), we’ll always redirect to https://www.fastmail.fm (secure).

Going to other https:// domains that aren’t supported (e.g. https://www.sent.com, a secure connection, but will report a certificate error) will redirect to https://www.fastmail.fm as well.

This will also be the case for businesses and families that use their own domain for logging in (e.g. http://mail.digitalintegrity.com), they’ll also be redirected to https://www.fastmail.fm, but we will continue to correctly show the family/business login screen.

There are a couple of additional exceptions to this.

The mobile UI domains that start with the http://m. prefix like http://m.fastmail.fm (insecure) and http://m.sent.com (insecure) will redirect to https://m.fastmail.fm (secure). This will always show the mobile login screen and mobile interface when you login.

The special "sticky ssl" domains that start with the https://ssl. prefix like https://ssl.fastmail.fm (secure) and https://ssl.sent.com (secure, but certificate warning) will "stick" to that domain. This may be useful as a work around for some proxies that block hostnames with the word "mail" in them.

If for some reason you need to use an insecure login (which we highly recommend you do not do), you will explicitly need to go to the URL http://insecure.fastmail.fm. If you use this to login, data sent between your computer and our server will travel unencrypted over the Internet. This service is only provided for dire circumstances, is highly discouraged, and may be removed in the future.

For the curious, here’s a list of all the transitions that should happen. The "(W)" means you’ll see a certificate warning about mismatched hostnames.

https://www.fastmail.fm               -> stays at https://www.fastmail.fm
http://fastmail.fm                    -> https://www.fastmail.fm
http://sent.com                       -> https://www.fastmail.fm/?domain=sent.com
http://www.fastmail.fm                -> https://www.fastmail.fm
http://www.sent.com                   -> https://www.fastmail.fm/?domain=sent.com
https://fastmail.fm                   -> https://www.fastmail.fm
https://sent.com (W)                  -> https://www.fastmail.fm/?domain=sent.com

http://mail.digitalintegrity.com      -> https://www.fastmail.fm/?domain=digitalintegrity.com
https://mail.digitalintegrity.com (W) -> https://www.fastmail.fm/?domain=digitalintegrity.com

http://m.fastmail.fm                  -> https://m.fastmail.fm
http://m.sent.com                     -> https://m.fastmail.fm/?domain=sent.com
https://m.fastmail.fm                 -> stays at https://m.fastmail.fm
https://m.sent.com (W)                -> https://m.fastmail.fm/?domain=sent.com

http://ssl.fastmail.fm                -> https://ssl.fastmail.fm
http://ssl.sent.com                   -> https://ssl.sent.com/ (W)
https://ssl.fastmail.fm               -> stays at https://ssl.fastmail.fm
https://ssl.sent.com (W)              -> stays at https://ssl.sent.com/ (W)

http://insecure.fastmail.fm           -> stays at http://insecure.fastmail.fm
http://insecure.sent.com              -> stays at http://insecure.sent.com
Posted in News, Uncategorized. Comments Off

Proxy servers for alternate IMAP port (may be useful for Blackberry BIS users)

I recently posted about our new IMAP alternate namespace port that may be helpful for some users.

Some blackberry BIS users reported that their service provider wouldn’t let them change the IMAP port number, which meant that couldn’t use the alternate namespace port. To deal with this, I’ve setup a “proxy” server for the IMAP alternate namespace port.

Our “proxy” servers are special hostnames that listen on every port and respond with a particular service. Our current proxy servers are:

  • imap.proxy.messagingengine.com – IMAP
  • imaps.proxy.messagingengine.com – IMAP SSL
  • pop.proxy.messagingengine.com – POP
  • pops.proxy.messagingengine.com – POP SSL
  • smtp.proxy.messagingengine.com – SMTP
  • smtps.proxy.messagingengine.com – SMTP SSL
  • ldap.proxy.messagingengine.com – LDAP
  • ldaps.proxy.messagingengine.com – LDAP SSL
  • imapalt.proxy.messagingengine.com – IMAP (alternate namespace)
  • imapalts.proxy.messagingengine.com – IMAP (alternate namespace) SSL

So for BIS users, what you would do is:

  1. Login to the BIS website your provider gave you details for
  2. Setup an external email account
  3. When it asks for the username and password, just enter the username and leave the password blank
  4. It should then take you to a page with more advanced configuration options. There you can say to use IMAP + SSL, and when it asks for the servername, use “imapalts.proxy.messagingengine.com”
Posted in Uncategorized. Comments Off
Follow

Get every new post delivered to your Inbox.

Join 5,590 other followers