FastMail is not required to implement the Australian metadata retention laws

Summary: We have reviewed the recently passed Telecommunications (Interception and Access) Amendment (Data Retention) Bill 2015 and have received additional legal advice confirming that the new metadata retention regime will not apply to FastMail. This means that FastMail is not obligated to retain metadata relating to email sent/received by our users, nor are we required to provide Australian law enforcement agencies with access to such metadata without a warrant. As such, there are no changes to our privacy policy.

For those interested, there are significantly more details below.


Some users have asked us what the recently passed metadata retention laws mean for FastMail, and in particular the privacy of their data. We’ve now reviewed the new laws as passed in the Telecommunications (Interception and Access) Amendment (Data Retention) Bill 2015 and worked with a lawyer to get a confirmed interpretation.

The most important provision in the Bill for our purposes is the new section 187A(3) which defines who the laws actually apply to. There are 3 separate parts that must all apply for an entity to be subject to the metadata retention requirements. Quoting the actual bill:

(3) This Part applies to a service if:

   (a) it is a service for carrying communications, or enabling communications to be carried, by means of guided or unguided electromagnetic energy or both; and

   (b) it is a service:

      (i) operated by a carrier; or

      (ii) operated by an internet service provider (within the meaning of Schedule 5 to the Broadcasting Services Act 1992); or

      (iii) of a kind for which a declaration under subsection (3A) is in force; and

   (c) the person operating the service owns or operates, in Australia, infrastructure that enables the provision of any of its relevant services;

but does not apply to a broadcasting service (within the meaning of the Broadcasting Services Act 1992).

We do meet the requirements for (a), however none of (b) nor (c) apply to us, so the laws as a whole to not apply to us.

Digging into these into more detail:

Section 187(3)(a)

As an email service, FastMail clearly enables "communications" to be "carried" (as those two terms are defined in the Telecommunications (Interception and Access) Act 1979 ("TIAA").

Section 187(3)(b)

(i) FastMail is not a "carrier" as defined in section 5 the TIAA because:

  • we are not the holder of a "carrier licence" as defined in section 7 of the Telecommunications Act 1997 ("TA"); and
  • we are not a "carriage service provider" as defined in section 87 of the TA because:
    • the definitions in sections 87(1), (2), (4) and (5) require a carriage service provider to be a person supplying a "listed carriage service", which is defined in section 16 of the TA to mean a "carriage service" between two or more points where at least one point is in Australia – as none of FastMail’s servers are physically in Australia, we only ever connect our servers to a network outside of Australia, and therefore only ever carry communications between non-Australian locations;
    • the definition in section 87(3) applies to carriage services that are supplied as a secondary purpose for a network whose principal use is by a defence organisation, transport or electricity providers, or similar – none of these uses are relevant to FastMail’s services;

(ii) FastMail is not an "internet service provider" within the meaning of Schedule 5 to the Broadcasting Services Act 1992, because we do not supply an "internet carriage service" (meaning a listed carriage service (as defined in the TA) that enables end-users to access the internet) to the public; and

(iii) no declarations made under subsection (3A) are in force.

Although the argument regarding FastMail only ever carrying communications between non-Australian networks is quite technical, we’ve not been able to find any cases or commentary which support nor contradict that argument. However, having reviewed the rest of the wording in section 87 (including the definitions of "network unit", "line link", "line" and "designated radiocommunications facility", none of which FastMail seem to have in Australia), it seems unlikely that FastMail could be defined at a "carriage service provider".

In any event, an analysis of part (c) as discussed below, it’s of little consequence whether 3(b) applies or not.

Section 187(3)(c)

The biggest question here is what "infrastructure" means. Section 5 of the TIAA (see page 29 of the Bill) includes a definition as follows:

infrastructure means any line or equipment used to facilitate communications across a telecommunications network

We don’t have any lines or equipment (servers) in Australia, and therefore do not have "infrastructure" in Australia.

As an additional confirmation, the explanatory memorandum for the Bill makes this point even clearer:

Definition of ‘infrastructure’

417.           This item inserts a definition for the term infrastructure into subsection 5(1) of the TIA Act. It defines infrastructure, as it is used in paragraph 187A(3)(c), to mean any line or equipment used to facilitate communications across a telecommunications network.

418.           The term infrastructure is used as part of the three limb test in paragraphs 187A(3)(a), (b) and (c) which defines a relevant service. ‘Equipment’ is defined in section 5 of the Act, which states equipment means any apparatus or equipment used, or intended for use, in or in connection with a telecommunications network, and includes a telecommunications device but does not include a line. Section 5 of the Act, defines ‘line’ by reference to the definition in the Telecommunications Act. Section 7 of the Telecommunications Act states a line is a wire, cable, optical fibre, tube, conduit, waveguide or other physical medium used, or for use, as a continuous artificial guide for or in connection with carrying communications by means of guided electromagnetic energy.

419.           Servers used to operate an ‘over the top’ service such as VoIP would fall within the definition of infrastructure. However, ‘infrastructure’ is not intended to include business premises. For example the headquarters of a company, taken in isolation, would not satisfy the definition of ‘infrastructure.’

420.           Importantly, a piece of equipment or line meeting the definition of infrastructure does not automatically satisfy paragraph 187(3)(c). For instance, a computer used by an employee in a company’s headquarters or marketing office is not directly involved in the provision of a relevant service and therefore does not satisfy paragraph 187(3)(c).

421.           This item implements recommendation 11 of the 2015 PJCIS Report by defining the term ‘infrastructure’ in greater detail for the purposes of paragraph 187A(3)(c).

Therefore, it’s clear that part (c) does not apply to FastMail, as the only equipment in Australia is employees and their work computers, there are no servers running any FastMail services or storing any email in Australia.

Therefore section 187A(3), which imposes the metadata retention obligations, does not apply to FastMail.

We had some additional queries regarding the wording of “owns or operates, in Australia”. Since that’s two separate parts, if you take the "own in Australia" part, does that mean "the infrastructure is physically in Australia" or does it mean "the infrastructure is legally owned by an entity in Australia"? It has been made clear to us that the wording of part (c) of section 287(3) applies to the location of the infrastructure, rather than whether the person or entity that owns the infrastructure is Australian. If this wasn’t the case, part (c) would need to phrased so that the reference was to an "Australian person" or "Australian entity" owning infrastructure (or there’d be a definition to bring in this connection). By using the words "in Australia", the reference can only be to the physical location of the lines and equipment

As an aside from actually determining if the law applies to us, we regard the actual need for this law as poorly thought out. There’s no evidence that large scale metadata retention will actually lead to improved policing, and in an insane situation, you actually have the communications minister for the government that’s passing this law recommending ways to work around the law! All this bill does is impose excessive additional regulations and burdens on Australian businesses. It actively discourages us from investing in servers and infrastructure in Australia and encourages us to put them elsewhere in the world to ensure that the law continues to not apply to us. Forcing an Australian company to reduce IT infrastructure investment in Australia and creating an inferior experience for Australian customers, while providing no proven law enforcement benefit for anyone feels like a massive mistake to us.

Posted in News. Comments Off on FastMail is not required to implement the Australian metadata retention laws

Know how to identify genuine email from FastMail

Recently, we’ve seen an upswing in the number of attempts by criminals to steal FastMail accounts. We’re working hard to maintain our high security and keep them at bay, but we’ve also got three simple tips you can follow to keep your account secure.

1. Know how to identify genuine email from FastMail

All genuine email from FastMail is displayed with a white tick in a green circle next to the sender’s name in both the mailbox list and on the message itself. It looks exactly like this in the mailbox:

Green tick next to sender name in mailbox list

And like this on the message:

Green tick next to sender name in message view

If the email doesn’t have the green tick, it’s not from us.

Please note, we can only do this in our web interface and apps; it will not appear in other email clients. It will also not appear in our classic interface; we recommend users upgrade to our current interface for increased security.

Always look for the green tick before trusting emails supposedly from FastMail.

2. Look for the green badge before logging in

When logging into our webmail, always look for a green badge in the address bar of your browser with the text “FastMail Pty Ltd”. Phishing sites (scam websites that try to steal your login details) can easily clone the look and feel of our website, however they can’t clone the green badge.

The badge looks like this in Google Chrome:

Green EV SSL badge reads FastMail Pty Ltd

And like this in Mozilla Firefox:

Green EV SSL badge reads FastMail Pty Ltd

And like this in Safari:

Green EV SSL badge reads FastMail Pty Ltd

And like this in Internet Explorer:

Green EV SSL badge reads FastMail Pty Ltd

And like this in Opera:

Green EV SSL badge reads FastMail Pty Ltd

If you don’t see the badge, you’re not at the genuine FastMail website.

3. Never reuse your FastMail password at another service

Your email is the key to your digital life. Almost every web service you use, such as Amazon, Facebook or Twitter, allows you to reset their password by sending a link to your email address. It’s vitally important to keep your email password secure, as it provides access to everything else!

When you reuse your FastMail password at other sites, you’re making it much easier for attackers to potentially break in to your account. Other sites often don’t have the same high security measures as FastMail (such as compulsory HTTPS, locked-down servers, etc.), which makes them much easier for criminals to break in to. If they hold your email address and the same password that you use for FastMail, the attacker can then access your email account and get into everything else you use online.

Always use a unique password for FastMail that you don’t use elsewhere.

Follow these three simple tips, and you’ll be protected against the vast majority of attacks we see.

Posted in News. Comments Off on Know how to identify genuine email from FastMail

Dec 22: CardDAV beta release

This blog post is part of the FastMail 2014 Advent Calendar.

The previous post on 21st December was about our file storage system. The following post on 23rd December promotes our standard for better email.

Technical level: medium

After more than a year of anticipation we’re very happy to announce today that we’re releasing CardDAV support into public beta test.

CardDAV is a protocol for reading, writing and synchronising contact data. It’s built into iOS devices and available on Android with an inexpensive third-party application. If you’ve ever wanted to have your FastMail contacts available on your mobile device (and vice-versa), then this is exactly what you want.

Obviously, since this is a beta, there are still a few pointy edges and non-working bits. The most notable thing is that the beta is currently only available to personal accounts, not to business or family accounts. This is because support for shared contacts is not ready yet and there’s some potential for data loss and inconsistent behaviour if you try to use shared contacts without proper support. We’re working hard on finishing shared contact support and hope to make the beta available to business and family accounts within the next couple of months.

CardDAV is only available to Full account levels and higher. Member, Guest and Lite accounts will need to upgrade to be able to use CardDAV.

So now all the disclaimers are out of the way, you can sign up for the CardDAV beta here: https://www.fastmail.com/go/carddavbeta. Instructions for connecting your client are still under development here: https://beta.fastmail.com/help/clients/applist.html.

The contacts story

An address book is a fundamental component of any mail system and FastMail has had one almost since the beginning. It’s always been stored in the MySQL database and available through the web client. For much of its history it’s been confined to the web client. A few years back we did add a read-only LDAP interface, which is useful for desktop mail clients that could support LDAP address books. It works fine, but being read-only severely limits its usefulness. Some time later mobile devices happened, and it became clear that something else was needed.

In 2011 the CardDAV protocol was published, largely developed at Apple to allow device contacts to be synchronised with a server. The protocol is very similar to the earlier CalDAV protocol (which we also use for our calendar) which is good as it allows us to share a lot of code between our calendar and contacts system.

Towards the end of 2012 we started to seriously appreciate the need for both an integrated calendar and device contacts syncing. We weren’t the only ones, as the Cyrus project had started to add support for CalDAV and CardDAV to the Cyrus mail server. We looked at a few options for calendar and contacts and decided that we would implement both on top of the support being baked into Cyrus, and work began in earnest. We decided that calendar was more important because we already had a contacts system and while it wasn’t perfect we preferred to focus our engineering effort on a clear gap in our product lineup. That work took the best part of a year, and we finally released the calendar to production in June 2014. At this point we were able to focus on CardDAV-based contacts.

The actual CardDAV part of this work is actually fairly simple. Unlike CalDAV, the backend server (Cyrus) doesn’t really need much special knowledge. It mostly just saves and loads contact cards as required. Calendar entries are more complicated; the server needs to know about timezones, recurring events, alarms, etc. CardDAV is much easier and if all we had to do was ship CardDAV support, we probably could have done so months ago.

The thing that made it more difficult came from the fact that we already had a contacts system and plenty of code fairly tightly integrated with it. It’s more than just the two user interfaces. The mail delivery pipeline also makes use of user contacts for spam whitelists and distribution lists, so we needed to teach these systems about a whole new storage system for contacts. Up until this time they had simply hit the database for this information. To make matters worse, we always knew that we’d need to roll out CardDAV to users gradually which meant that both the UI and the delivery code needed to be able to work with either. In short, we needed to abstract away the implementation details of the contacts storage, which took a few months to build, test and deploy. We ended up with a nice abstraction based on the JMAP getContacts/setContacts model, with a database provider behind it.

The next step was to write a CardDAV provider for our contacts abstraction. That was actually pretty easy because most of the code needed to access DAV resources was already available from our CalDAV work.

The last piece of the puzzle was the actual data conversion layer. The existing contacts system has a data model that doesn’t match up perfectly with the vCard format used by CardDAV, so we had to develop a mapping. Most of the fields have a 1:1 mapping (addresses, email addresses and phone numbers). What we call “online” fields, however, do not. Our “online” field group includes URLs, Twitter handles and chat IDs. vCard doesn’t group those the same way but more annoyingly, it doesn’t have a standard set of fields for representing these. It took a long time to develop and test a mapping that works most of the time. It’s going to need improvement as we go but it’s not bad for now.

What’s next

The next few months will include a lot more testing, polishing and responding to user feedback and obviously completing the business and family support. That will bring us to a full release where everyone will be quietly and transparently migrated to the CardDAV backend. We can then start to clean up a lot of old code, always a nice thing to do.

If you’re trying the CardDAV beta test, we’d love to hear what you think. Let us know on twitter or by emailing carddavbeta@fastmail.com.

Posted in Advent 2014, News. Comments Off on Dec 22: CardDAV beta release

SSL certificates updated to SHA-256, RC4 disabled

Today we’re rolling out SHA-256 certificates. We announced this last month, and you can read that post for more information about why this is necessary.

At the same time, we’ve disabled the RC4 cipher suite. RC4 has long been considered broken and the browser security community recently started actively discouraging its use. The SSL Labs test penalises it, and Chrome has started presenting a low-priority warning.

All this means that we’re now get an A+ grade on the SSL Labs test, which is a good indicator that when it comes to our SSL/TLS configuration we’re pretty much in step with current industry best-practice.

If, like most of our users, you use the web client in a modern web browser, you won’t notice any difference. In older browsers and some IMAP/POP3/DAV/LDAP clients, you may start seeing disconnection problems if they don’t know how to handle SHA-256 certificates or rely on RC4. In these cases you’re encouraged to upgrade your clients and if necessary, contact your the author of your client for an update. In the meantime, you can use insecure.fastmail.com (web) and insecure.messagingengine.com (IMAP/POP/SMTP), both of support RC4 and have a SHA-1 certificate. 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.

Posted in News. Comments Off on SSL certificates updated to SHA-256, RC4 disabled

FastMail Advent 2014

Welcome to the inaugural FastMail Advent Blog. One post per day for the next 24 days.

The idea came from a reponse I made to a question on reddit about physical locations of servers and their impact on security.

I wrote that up in more detail, with links to blog posts about what FastMail does to address various categories of security risk, and suddenly found myself with something much too long for a single blog post. I wanted to split it up into separate posts, and then started thinking about frequency – and meanwhile my daughters were asking about advent calendars for the year, and it clicked.

We’ve been promising to blog more about some of our technology, and also about some of the less-well-known features – here was a perfect opportunity. You won’t just be hearing from me, I’m going to try to get everyone to write up something about their areas of expertise.

There’s a fine internet tradition in what we’re doing here, check out the perl advent calendar for example. They’ve been doing it for years.

All the days are now complete. Here are links to the individual posts:

  1. Email Search System
  2. Security – Confidentiality, Integrity and Availability
  3. Push it real good
  4. Standalone Mail Servers
  5. Security – Integrity
  6. User authentication
  7. Automated installation
  8. Squire: FastMail’s rich text editor
  9. Email Authentication
  10. Security – Availability
  11. FastMail Support
  12. FastMail’s MySQL Replication: Multi-Master, Fault Tollerance, Performance. Pick Any Three
  13. FastMail DNS hosting
  14. On Duty!
  15. Putting the fast in FastMail: Loading your mailbox quickly
  16. Security – Confidentiality
  17. Testing
  18. Billing and Payments — a potted history
  19. Mailr
  20. Open-sourcing OvertureJS – the JS lib that powers FastMail
  21. File Storage
  22. CardDAV Beta Release
  23. JMAP — A better way to email
  24. Working at FastMail
Posted in Advent 2014, News. Comments Off on FastMail Advent 2014

FastMail app for iOS and Android now available

Today we’re proud to announce the release of the FastMail app for your iPhone, iPad, iPod and Android devices. You can get it right now from the App Store (iOS) or the Play Store (Android).

 Download on the App StoreGet it on Google Play

Our apps have been designed to combine our lightning-fast mobile web app with device features normally only available to native apps, most notably push notifications.

iOS notificationAndroid notification

On Android, you’ll even find support for your smartwatch!

Android Wear notificationPebble notification

More information about the FastMail app is available in our help.

Posted in News. Comments Off on FastMail app for iOS and Android now available

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.

Posted in News. Comments Off on FastMail has moved to fastmail.com, @fastmail.com email addresses now available
Follow

Get every new post delivered to your Inbox.

Join 6,860 other followers

%d bloggers like this: