robn_fastmail

Hi, FastMail employee here.

Just to clarify ahead of time, what's happening is literally all the blog post says - we're getting off of Opera hardware and networks and on to our own.

For end-users, nothing changes. There will continue to be a secondary DNS and MX service in Iceland. We're continuing to hold a live emergency replica of all our data there. And that's all. No new services, no precursor to non-US hosting, nothing.

As the blog post says, the _only_ reason it might be of interest is if you've hard-coded the old IPs somewhere. If not, then there's nothing to see here. Sorry to disappoint you ;)

For historical reasons we still run DJabberd at FastMail so I had to add support for this myself. You might try this patch:

https://github.com/fastmail/DJabberd/commit/144c4431f36e5ea3...

Its been running for a few hours now without any obvious problem. I might have made some stupid error that makes the crypto entirely useless but considering yesterday it was all in cleartext anyway I think I can live with it ;)

Actually exactly half an hour between when I got woken up and when I sent my report email.

> "needing ... supporting IdPs (email providers)"

Over at FastMail we seriously looked into implementing Persona across the board. We're one of the bigger "small" email providers and we figured that it would be a good thing to get in on the ground floor if it succeeded, and have a(nother) feature to differentiate us from our competition, and to be able to give feedback on the system from the iDp perspective.

The hard requirement for HTTPS or DNSSEC is what raised the bar too high for us in the end (see https://github.com/mozilla/persona/issues/1523 for more info). Basically, the domain owner needs to securely delegate to the identity provider. Since we provide DNS and basic web hosting for most user domains, that means we have to provide HTTPS certificates for every domain we manage (and at least one IP per domain) or be able to serve proper DNSSEC records for every domain we manage (difficult when many registries we use still don't support it).

DNSSEC is something we're working towards, and I'd really like to have full support available this year. HTTPS without needing one IP per domain and multiple certificates is still not yet feasible, though there are specs gradually coming down the pipeline for it (DANE, DNA, POSH, etc). Without all this tech in place, Persona seems to be a non-starter for a IdP that wants to manage lots of domains.

I don't blame the Persona guys for this. I know they tried and they got a lot of it right, and should be applauded for that. Maybe the next round of federated authentication will work. I have no idea, but I know we'd still like to be involved, and we'll be watching the space with interest.

Persistent connections are tough on patchy mobile networks.

Parsing latency isn't really an issue; all this stuff is IO bound anyway. CPU cycles are cheap.

IMAP works, but not particularly well for a lot of modern tasks. Its highly stateful, requires a fair amount of knowledge on the part of the client to make things work correctly, and too many extensions are optional, requiring a lot of fallbacks for when functions are missing. Implementing a client or a server well is difficult.

JMAP isn't the be-all and end-all of mail protocols, but it goes some way to address some of the problems in IMAP. We're using it in production right now at FastMail so we already know its pretty good as a low-latency, stateless protocol.

As for the IETF (and standards bodies in general), they're useful in their place, but they're also a slow-moving beast and thev're published a great many "standards" that have either never been implemented or are just rubbish.

But there's nobody forcing you to implement it. Its there, its documented, and we're encouraging others to get involved to make it work. If others get on board then we'll see improvements everywhere. If not, then FastMail will continue to use it and get the advantages that come from it.

Yeah, this one is well known, see https://tidbits.com/article/14219.

We actually have some evidence to suggest that we've picked up a few customers leaving Gmail because of this problem. Which is nice, but now we have to deal with a different bug. Nobody is safe from Mail.app! ;)

A very naive estimate based on one day of logs from one server says over 75% of our incoming port 25 connections are encrypted. Although that says nothing about the quality of the cipher in use and the type of messages that come through, its still significantly higher than I would have expected.

I can see I'll be spending some time on this in the next few days!

> If they force you to disclose your customers' data in secret tomorrow, or face jail time, I have no doubts what your choice will be.

We have no doubts either. The privacy policy clearly states we will give your data to the Australian authorities if supplied with the proper supporting documentation.

I didn't just find out about the ACC, though I wasn't aware of the details. But I'm not a lawyer, just a sysadmin, so I don't need to be. The "its not clear" bit is simply that there are two laws that appear to be in contradiction with each other. Its never been tested in court. And thus, its not clear. But we have confidence that what our position is legally supportable or we wouldn't be here.

I'm afraid that if get fit and stuff I won't want them anymore! :'(

If you want to just send timtams, that would be fine too. We seem to have run out of them in the office...

There's a solution for this. Its called DANE. See http://tools.ietf.org/html/draft-ietf-dane-smtp

We're currently investigating it.

Because its our advice. It was developed for us, taking our concerns into account. You need to get your own legal advice relevant to your own situation.

Or put another way, I don't think "Your Honour, FastMail's lawyer said it was ok" is valid defense for anyone except us.

We currently have a complete copy of all user data in a secondary (non-US) data centre. In the event of a loss of our US-based servers, we would get this secondary copy up and running as quick as possible (likely in a reduced capacity) while sourcing new equipment and getting a new primary centre up as quickly as possible.

This would be a catastrophic event, no doubt about it, and there would be significant disruption for our users. But it wouldn't mean the end of FastMail.

We have been contacted by US authorities in the past, and have referred them to the appropriate Australian authorities.

We have been contacted by Australian authorities in the past, and have worked with them in accordance with Australian law and our privacy policy, which you can read here: https://www.fastmail.fm/help/overview_privacy.html

I just checked upstairs. The advice we have is roughly:

- ACC has judicial oversight

- its unclear how this interacts with the Telecommunications (Intercept and Access) Act

With my boss throwing in:

- law is a giant mess

- until you have two extremely well-funded parties disagreeing vehemently about the interpretation, you'll never get a final answer

We're still happy with our publicly-stated position. You might disagree, and I'm not really in a position to argue with you. Its my corporate masters with their necks on the line, and they seem relaxed about it. That's good enough for me :)

Actually we did clearly mention it:

  "Our colocation providers could be compelled to give physical access to our servers."

But in the very next paragraph:

    "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."

Its not hard for a skilled sysadmin to take an image of a running server. Its extremely difficult to do it without administrative access to the machine AND to do it without anyone noticing.

I would argue that section 29 is very narrow in its scope, and allows for disclosure once an investigation is completed, and allows for disclosure to an attorney, whereas my understanding of an NSL is that it can order pretty much anything it wants without limitation. That seems quite different to me.

But then, I'm not lawyer. You're probably not either. Which is why I keep telling people to get their own legal advice if they're concerned about it.

> Has the headline on HN been updated? Because both you and brongondwana talk about it being sensationalist, where I see it as just being a summary of the most salient part of what you have to say.

To my mind it was one of the least interesting parts of what we had to say. "Non-US company not bound by US law" - its hardly earth-shattering news. Would "Non-Senegalese company not bound by Senegal law" be as interesting?

EDIT: Sorry, it just occurred to me that it was changed already and you might have posted this afterwards. The original post headline was "FastMail claims they do not have to comply with National Security Letters". That's what we were referring to when we said it was "sensationalist".

> Do you have Australian legal advice to back up your conclusions? (I agree with them, but would like to make sure we're talking more than the "gist" of the law)

We've made our position public, and we're satisfied that its an accurate reflection of our position and our understanding of Australian law. You must not rely on it as a legal basis for anything though - get your own legal advice that applies specifically to your own circumstances!

If I was an evil-doer/dissident I wouldn't be trusting my life to the collective wisdom of the internet ;)

Because most of our customers are in the US. If your goal is to provide the fastest service around, it helps to put your servers near your users.

Hi, FastMail employee and author of (most of) that blog post here.

Just so we're clear, the point of this post was not that we don't think the rules don't apply to us. Instead we're trying to make it clear where position on these things are. The topic of this thread is a sensationalist sound-bite, nothing more.

I'm not going to go over the points again here because I'm pretty sure we said it all in the post (but ask questions if you like, I'll be here all week!).

The most important point to take away from this post is that your privacy is your responsibility. We're trying to provide you with as much information as we can to help you determine your own exposure, and to let you know what we will work to protect and where we can't help. Its up to you to determine if our service is right for you. No tricks, and no hard feelings if you'd rather take your business somewhere else!