FastMail app for iOS and Android now available
blog.fastmail.com
blog.fastmail.com
The government is scrambling to pass laws for mass surveillance [2] and controversial data retention laws. [3]
[1] https://www.fastmail.com/help/legal/privacy.html
[2] https://www.eff.org/deeplinks/2014/09/australian-government-...
[2] http://www.theguardian.com/australia-news/2014/oct/16/privac...
Especially given that most people are using Gmail, or Outlook / Office365, or Yahoo! Mail, all of them coming from companies that can be and have been coerced by the NSA, without the people finding out about it until those leaks. In fact, as a European citizen, I would be more comfortable with an Australian company, than with a US-based one, simply because the governmental agencies in non-US countries are less competent than the US is at mass surveillance.
But the fact of the matter is ... if you do not encrypt your email on the client-side, you can't expect privacy protections from a global enemy that has the resources for MITM attacks. All the protection you can hope for is against local enemies (organized crime syndicates, competition, etc.)
So here we have a smaller player that's competing against big companies such as Google, Microsoft and Yahoo and the first comment is about fear mongering about some laws that haven't even passed yet and targeting a company that has nothing to do with it. Don't take this the wrong way, but seeing this from a community of entrepreneurs is disappointing.
The changes in related laws in Australia are unprecedented [1] and are passing as we speak [2][3]
The comments on their own privacy page is about to become outdated or misleading -
Australia has strong privacy laws in relation to email, specified in the Telecommunications (Interception and Access) Act 1979. [4]
As an EU citizen you are offered more protection then many other regions of the world, at least from a regulatory perspective -
Under EU law, personal data can only be gathered legally under strict conditions, for a legitimate purpose. Furthermore, persons or organisations which collect and manage your personal information must protect it from misuse and must respect certain rights of the data owners which are guaranteed by EU law. [5]
Please watch the youtube like referenced below to get a feeling of the insanity -
[1] https://www.youtube.com/watch?v=srk9c4rOgZ4
[2] http://www.theaustralian.com.au/news/latest-news/australias-...
[3] http://www.news.com.au/technology/online/antiterror-laws-rob...
Besides, this is an internet forum. It has threads. This is how these things work.
http://www.dailymail.co.uk/news/article-2096768/Woody-Harrel...
By the way, I like the app. First load must be hitting the network, seems like that could come from a stored cached and refreshed asap.
Also, it would be really nice if you could archive or delete a message from the reading view. (a) there's plenty of room for 2 more icons and (b) I have to believe people are way more likely to archive a message than forward it, yet somehow forward gets the spot.
If you tap the message area when reading, a row of action buttons will appear. You can archive, delete, report spam, move to folder and mark from here.
Here's what I can tell you:
* while in theory the new laws allow law enforcement to request information from a broad set of computers instead of a single computer, that actually makes sense as a representation of reality. The information for a single user on our system is already spread over multiple machines - 3 separate IMAP servers in a replica set, 4 different database servers in a replica set, plus at least one backup server. Requiring law enforcement to get 8 separate warrants for "all the data about user X on those 8 machines" would be patently stupid.
* we haven't seen any change in the nature of requests coming from law enforcement, and we have no reason to expect them to change.
* our position of fully cooperating with the Australian authorities if they present a lawful warrant for the data on an individual user, having obtained due cause, has not changed. We do not place ourselves above the courts. We do not implement dragnets, but we have provided data on individual users in response to warrants, and will continue to do so. This is quite clearly spelled out in our privacy policy.
(edited: just formatting)
So if you plan to cooperate fully then that's fine. But you will likely lose a ton of customers.
So far there haven't been any new laws actually passed which change our operating environment. When/if there are, then we'll have to respond to them.
If the laws change such that we need to say anything different in our privacy policy, then we will definitely make a public statement about those changes.
For now, our privacy policy still accurately reflects our understanding of the legal framework we operate within.
There's an answer given by Fastmail's support. Sadly, I agree with an user there when he/she says that the folks there don't seem to be much interested in that kind of discussion..
Then it would be nice to have contact synchronization available via CardDAV.
The native AOSP email app, for example, doesn't even allow you to choose which email address to send from when replying (that, or it's so hidden that I was unable to find it.) Unfortunately, like most AOSP apps, it's been effectively deprecated in favor of the Google alternative (Gmail) so it's unlikely to get any better anytime soon.
I'm also so glad to see that they are releasing on both platforms simultaneously. Having used both an iPhone and an Android, I find it very frustrating when a product is released on one but not the other[0]
[0] Yes, I understand why startups choose to do this. We had to decide which platform to support first at my startup, so I understand the tradeoff involved. But as a user, it's still frustrating.
What it meant is that the other guy could make supporting UI tweaks as he needed, and I could make supporting backend tweaks as needed (eg push system integration), but we had to come together a lot to find the similarities and differences between the two platforms and do changes for each other.
It became a bit of a competition and we both were working very fast. We had something we could use every day in less than a month and we each learned a huge amount about the other person's area of speciality.
I'm fairly confident if we did just one app first we would have gone much slower and made some bad architectural decisions that would have hurt when we got onto the next platform. If we ever do a third platform client it'll be really easy.
What we are hoping to do (quite soon) is switch to pure JMAP for the app's communication to the server - http://jmap.io/
At that point, k9 will be able to get the same great push notification system and efficient updates by implementing a JMAP backend.
The actual IMAP server part I'm happy to host myself, but these other two parts take up too much time. Right now I use gmail to do these two things, but it's imperfect for a lot of reasons.
Would FastMail be a better choice for this? Or are there better ways to outsource these hard parts? I feel like there should be a reliable service that does just those bits, but I've never found one.
It's fine though, I really am happy to be paying for an email service instead of depending on Google. I am quite happy with everything else. Really easy to set up and integrate. Works well with Android's email app and Mail.app. The webmail isn't terrible but I just use it to report spam. Having an Android app now is super exciting.
We're also talking to many companies about a better API for everyone - the draft spec is at http://jmap.io/ - it's based on the API that our app already uses.
http://jmap.io/ seems pretty awesome, I guess I can use that to build my own fastmail app integration?
Thanks for all the hard work on fastmail!
Yep, its high on the todo list for a future update.
> http://jmap.io/ seems pretty awesome, I guess I can use that to build my own fastmail app integration?
That's the intent, though we're not there yet.
Is the code on: http://jmap.io/server.html actual code? If so what kind? Lua? It'd be great if you could publish some test cases, even if you don't have implementations to go (open source) with it at this time.
I'm sure fastmail can bring a lot of real-world testing and experience to the table when/if designing a new protocol for email -- and I'd be very surprised if we actually need more than one... (at least considering we already have smtp, lmtp, pop3, imap and maildirsync over ssh, along with rsync/unison -- that cover a lot of use-cases already).
No, just pseudo-code.
Right now we don't have a lot of real JMAP code. FastMail's implementation technically isn't JMAP. To write JMAP we took our current protocol and filed off a lot of the pointy edges. We're working to update our own implementation, and we're also working on open-source reference servers and clients.
There's a mailing list just starting here:
https://groups.google.com/forum/#!forum/jmap-discuss
https://groups.google.com/forum/#!forum/jmap-discuss/join (ie: group-url+/join), or by emailing <groupname, spaces replaced with dashes>+subscribe@googlegroups.com.
The [ed:first, doh!] I tried (make sure you log out of google's estates first) -- the second I haven't tried, but works according to: http://webapps.stackexchange.com/questions/13508/how-can-i-s...
Note, that if you send a subscribe email, you'll be subscribing the from-email in the mail you send (I usually subscribe with unique addresses to lists and accounts, so that I can more easily see which are harvested/given away for spam abuse. So far linked-in, and adobe are top (the latter presumably due to the big account leak) -- and that's a bit of a hassle as all email clients suck ;-).
So the current state is: heliotrope kind of works, the client a little less, we are now fully working on sup. If you want to hack on heliotrope though, feel free to ask -- but there will most likely be no code from me.
Sup, on the other hand, works like a charm ! Visit us at supmua.org !
So far, the back of my envelope contains clojure, or possibly something else[2] that is pleasant to code in and feasible to both get to run (well) on Android and in the console, possibly web and/or desktop (GUI, that is -- not a great priority for me, but "advanced" features such as displaying image attachments in-line could be nice -- and is a natural fit for Android anyway), and a sync (possibly push) solution.
It's in the sync part, that heliotrope and jmap come in -- mostly as an alternative to either making my own, or just trying to shoe-horn everything into couchdb/puchdb etc.
Personally I don't really need IMAP (as I control both the server and the client), and I'm unsure if it's worth the effort; maybe with some clever hacks like sticking some meta-data in "special" mail-folders...
Other than that, I suppose caldav/carddav can handle contacts (or perhaps make an embeddable ldap-thing... but like imap it sounds like overkill...) -- the only remaining problem is quick search, which means good full-text search, which means multi-lingual stemming etc... mostly I'm thinking the server should do the indexing, and the client should be able to sync both index and content. Tricky part is making it incremental, so I can keep X GB email with full-text search on the server, and not need a significant % of X GB space on the Android device to get off-line access to the last month (or whatever) worth of email along with good search over that subsection...
[1] http://lumail.org/ [2] So far my short-list has clojure (pleasant, start-up time and possibly resources seem to be a (real) issue on Android), kawa scheme (try to keep the interesting stuff in somewhat "standard" scheme, either use kawa scheme everywhere, or try to stradle two scheme implementations...) and kotlin (it's a better java, but not sure if I'd call it pleasant).
Another contender in the space (label- and search-centric) is mu and its ui, mu4e [1]. Something else to have in mind.
Now if you want something that works on desktop and mobile, something worth a look would be using SQLite and its built-in full-text search... see how far you can go with that. SQLite is available pretty much everywhere, Android even allows full-text search. Now what you have to do is synchronize SQLite dbs. It "shouldn't" be too hard to remove old emails from the db so you can keep X MB worth of it. You can even shoehorn it into couchbase-lite [3][4] so that sync is automagically taken care of.
JMAP looks cool (definitely more interesting to implement than IMAP) but it seems to be more a query API than a sync API, although there are facilities to "get changes since last time" (a HUGE improvement from IMAP as deployed everywhere). OTOH if you can shoehorn it into couchbase-lite, you can use a generic sync protocol that can be used for other things too (caldav/carddav).
Heck, you've piqued my curiosity, I see something doable here. I'd love to hear more. I might even hack something just for fun.
[0] https://bitbucket.org/wuzzeb/notmuch-web
[1] http://www.djcbsoftware.nl/code/mu/mu4e.html
> You must be aware that notmuch is only the search backend, and for a full MUA you need frontends.
Absolutely. I tried to imply that with my wry parenthesis; but it's absolutely worth pointing out clearly to unwary readers. In no way is it fair to either notmuch or sup to compare the two as equals.
I'd probably lean towards mutt-kz[mk] for an out-of-box "notmuch" mua (but... mutt. Meh ;-) There's also "alot"[a].
> Another contender in the space (label- and search-centric) is mu and its ui, mu4e [1]. Something else to have in mind.
Right. See also:
http://dev.gentoo.org/~tomka/mail.html
Recently discussed on hn:
https://news.ycombinator.com/item?id=8519643
> Now if you want something that works on desktop and mobile, something worth a look would be using SQLite and its built-in full-text search... see how far you can go with that. SQLite is available pretty much everywhere, Android even allows full-text search. Now what you have to do is synchronize SQLite dbs. It "shouldn't" be too hard to remove old emails from the db so you can keep X MB worth of it. You can even shoehorn it into couchbase-lite [3][4] so that sync is automagically taken care of.
I've considered sqlite for some of these reasons. But couchbase-lite != sqlite, right? (Or does it use sqlite in a meaningful way; ie: can/should one use sql to interface with the stored data?). Btw, looks like you're off-by-one, in your references ;-)
If using sqlite, there are a couple of schemas one might use for inspiration, such as dbmail:
http://dbmail.org/dokuwiki/lib/exe/fetch.php/dbmail-er-model...
Or archiveopteryx:
http://archiveopteryx.org/db/schema
The main sticking point, is do we really want(need) to re-index everything everywhere, how do we transparently do search local-first, while supporting hits from the server along with fetching hits/mails that are missing locally (what k9 calls "cloud search") - how do we consolidate/sync data (the two hard things in computer science is caching and naming things...).
I'm not entirely convinced sqlite+built-in full text search is the best approach (I envision a useful search across some gbs of mailing list threads -- not convinced about the ranking -- but I could very well be the victim of premature optimization. And I'm a little wary of abandoning maildir for storage (on the server) -- but that might be useful anyway.
> JMAP looks cool (definitely more interesting to implement than IMAP) but it seems to be more a query API than a sync API, although there are facilities to "get changes since last time" (a HUGE improvement from IMAP as deployed everywhere).
Yes, that's pretty much what I gathered from the heliotrope story, that syncing was a bit of a mess.
> OTOH if you can shoehorn it into couchbase-lite, you can use a generic sync protocol that can be used for other things too (caldav/carddav).
Exactly. All the hard work done! For free! But seriously, couchdb was born from the ashes of lotus notes, and at least in spirit it was made for this kind of stuff... so couchdb sync, and some kind of half-assed search might be the way to go (on the server, elastic-search would probably work fine... not sure about on something like Android).
> Heck, you've piqued my curiosity, I see something doable here. I'd love to hear more. I might even hack something just for fun.
Great :-) If you do, please feel free to drop me an email (see profile).
[mk] https://github.com/karelzak/mutt-kz [a] https://github.com/pazz/alot
My bank probably is dumb enough to send newsletters, promotions and other spam-like mails next to notifications, statements and other not-spam-like mails from the same sever, also, Spanish is like a third-class citizen over the Internet, so I got accustomed to the language barrier.
While I have no doubt a better ecosystem around would be appreciated by some, the ecosystem thing as a whole is a double-edged sword.
I personally fled the Google-sphere because I felt I was gradually getting locked into something non-standard, non-portable.
These days I'm very hesitant to using non-integrations which aren't strictly needed. For instance: I prefer to create a proper user-account over "just" signing in with Facebook or Google.
I properly own my own domain and email-address. My Google or Facebook-account not so much.
Edit: To be clear, the value-add for me is that fastmail isn't some non-replaceable thing tied to an ecosystem, but a standards-based service provider which I can mix and mash with other best of breed-services as I see fit.
I know FastMail is dedicated to delivering email/calendar only and that they are famous for an elegant service. But seriously, how fancy can email be?
When I compared the major e-mail providers at the time, FastMail won because it was the closest to running your own server in terms of configurability (but much easier), it provided a great web UI (not as important for me personally, but some people don't use native clients), it was somewhat open about its technical infrastructure and it was doing one thing and one thing only (i.e. providing e-mail/calendar/contacts services).
That said, using a good service (like fastmail) vs running your own will always be a trade-off -- and it's perfectly reasonable to not run your own email.
Add to that messing with cryptic configuration files while reading about the dangers of doing it wrong and the general impression is that you shouldn't be touching any of it unless you fully understand it all. As far as beginner friendliness goes, it's a bit like desktop Linux was ten years ago.
No, it's much worse.
10 years ago you could get a desktop Linux up and running, the experience wasn't that much different from today and even if you screwed up, you could always reinstall it from scratch, but with email screw-ups may mean getting your domain blacklisted and good luck fixing it afterwards.
https://packages.debian.org/wheezy/ssl-cert helps, but afaik, nothing automagically does the right thing, yet (install certifate under /etc/ssl and the private key under /etc/ssl/private and symlink under /etc/exim/cert.{key|der or whatever} and ditto for other daemons that share the same cert/key.
And then there is tuning to disable plain text for most of those services.
So, yeah, it's still too complex.
I really don't understand everyone that are panicked about getting your domain blacklisted -- yes, if you send spam you'll be blacklisted. Yes, if you set up an open relay, that's bad. But you really have to work pretty hard to set up an open relay these days.
It never happened to me but I think with Dreamhost mail hosting you run the risk of your email suffering from collateral damage if another customer using the same mail server is labeled a spammer (even if you pay extra for a static ip for your web hosting, I don't think it's used for your mail traffic).
What's good about Dreamhost for email is the "unlimitedness," not just mail storage but also domains, email accounts, email aliases, etc. I still use them for a bunch of per-site addresses that forward to a real mailbox so I can just delete the per-site address if it gets spammed.
Once we have CardDAV available, then we'll be recommending CardDAV-Sync.
(eg Aptoide or similar, or even just a link to the apk)
I have Fastmail and support for Android apps; but no Play store access...
(And if it was a concious decision not to, any particular reason? :-) )
If there's enough demand for something else then we'll be happy to revisit this.
It's no stress, as the web client is excellent - was just partly wondering whether it had been considered :-)
Maybe my memory is failing me. But what are Android apps that are published on Amazon's Appstore or on F-Droid doing for push notifications? Also, what about offline access? Is the Android app functional in offline mode?
I don't know how many people are using Androids without Google Play on it, but those of us that do use Android without Google Play would appreciate a version installable from somewhere else. If you've got the resources that is, no pressure :-)
And as a suggestion, given that this is just a packaged web interface, it would be awesome to see it published for Firefox Mobile / Firefox OS. They apparently do expose an API for push notifications for example - https://developer.mozilla.org/en-US/docs/Web/API/Simple_Push...
On Android platform notifications and push notifications are different things. Any app can drop a notification into the notification area, and that's what most mail clients do in response to IMAP traffic.
A push notification is a small chunk of data sent by a server to Google's push channel with a target device/app identifier, which Google then sends on to the device. The target application wakes up and receives the data, and can do whatever it likes in response (or nothing at all). The FastMail app responds to pushes by calling back to the FastMail servers to find out what changed and update the platform notification accordingly).
Without the push channel, there's nothing that can trigger this, so you don't get notifications. We could wake up and poll regularly, but that's going to be pretty horrible for your battery.
There are other push channels around (eg Amazon have one) but they have different interfaces and its not at all clear there's enough demand to make it worth the time and effort to develop, test and maintain.
Until then, the app without notification support is almost identical to the regular web app in Firefox or Chrome, so you might as well just use it that way.
> And as a suggestion, given that this is just a packaged web interface, it would be awesome to see it published for Firefox Mobile / Firefox OS.
I did look into it briefly, mostly to make sure we weren't making any architectural choices that would prevent it in the future. Right now though there's basically no demand for Firefox OS. If it becomes worth the time and effort to do it, we'll reconsider it.
I would have been much more excited to have good calendar and contacts synchronization with my phone. Please don't make those dependent on google services too.
So instead it would be great to have a direct, trustworthy download link with checksums / signature.
(p.s. Excited to try it out!)
Edit: I am using a custom domain (a few different business accounts) if that is relevant.
I love FastMail, and can't wait to see where they go with a 2.0 release.
The Android app has a lot more right now, mostly because the web app experience has been pretty terrible in the stock Android browser so there was a lot more work needed to get it up to scratch.
Of course we'll keep working on it; we've got loads more plans :)
Let me know if you need beta testers!
For example, one of the companies I work for uses purple in their logo. So I tag all emails from them with their company name, and add make it purple.
Tagging (for me) is more about ad-hoc grouping. As giving it a thought right now it's even hard for me to come up with a realistic use case.
The only humans I've ever talked to there was when they erroneously charged me 10-100x as much as they should for my adwords campaign.
Put enough money on the table and they are willing to talk, but that's about it.
Fastmail.fm provides bad support and that is a fact.. They themselves know it and say so. They're trying to get the time down to 24h but as it is right now, it's bad.
Any plans on open sourcing the app(s)?
No plans to open source it at the moment, but we might if there was sufficient demand.
Even still, as a green-fields iOS app, I'd expect to see a little more in the way of embracing features that are now native. We have notification actions, extensibility, file sharing, and a Pebble SDK too, y'know.
Still, keep up the good work! You'll have my dollars as long as you're not Gmail.
Apart from the Pebble SDK, most of those landed in iOS 8. We were already in testing at the time it came out and our lead developer was preparing to travel, so we decided it was better to release rather than wait a few more months.
Of course there will be updates. We want to do lots more with the app; this is just the beginning :)
Now that our app is released we're unlikely to pursue this further.
Even more a shame since their Web app is pretty good.
Let's hope it's as user friendly as their mobile website.
It's not Google.
For some people, that's not a good reason, but for me it is. The fact that it's super fast, very powerful, and are an Australian company (I live in Australia, so things are very fast) are merely bonuses :)
I'm pretty certain the Fastmail servers are in New York; so that's a bit of a funny reason ;-)
No. We'll look into it.
> 2. Can I move mails from spam to inbox and from inbox to Spam?
Yes, tap the message while open and use the "report spam" or "not spam" button (the shield icon).
(and ssh into the servers, bliss - even the VPN connected faster)