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.
I appreciated the heads-ups about this in this thread. I have been a Fastmail customer for years, and didn't realize they were subject to Australian law. It's very relevant to me, and even though the laws haven't passed yet, major privacy organizations seem concerned enough. It's not easy to change e-mail providers, most people pay a year or more in advance, so it's good to be aware of these important issues. It also could give the company a chance to reassure customers, but I must say that "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" is not the reassurance I was looking for. I have come to expect good tech companies to vehementely oppose laws like this, actively fight against them, organize protests or at least publicly support the opposition (as in the anti SOPA/PIPA efforts in the US), etc. Not just say "We will update our privacy policy if necessary".
I had hoped for no bias in my comment - just to increase awareness.
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 -
Well done! I love FastMail, and am very glad that I switch from GMail. However, one of the best parts of FastMail is that it's just proper IMAP at the end of the day, so while I'm sure some people are going to love this app, I personally don't have much of a use for it.
Fair enough, we love IMAP too, and there's no way its going anywhere. We've always cared about standards compliance and client choice, so use what you like and be happy! :)
Interesting enough, there's no actual generic mail client (for imap/pop3/smtp) for chrome/chromeos ... would be nice to have an option for mail in chromebooks outside of several webmail clients open at once.
There are no new laws (yet). But lets not get into this discussion here. Contact privacy@fastmail.com with your questions and we'll be happy to respond to them.
My point was more that this is a thread about the new apps, not about our privacy policies. If you want to start a new thread somewhere I'd be happy to comment on it.
Fastmail customer here. This is a perfect place to answer the question: it's visible, it's the right audience, and it's relevant. Talking about whether we should be using Fastmail at all is, to me at least, related to the question of whether I should install the app.
Besides, this is an internet forum. It has threads. This is how these things work.
At this point, there are no new laws. Its still being debated in Parliament and submissions are still being reviewed, so its not clear what the final act is going to look like, assuming it passes. So we can't really comment on its impact until we know what's actually in it. We just don't know yet how this is going to play out.
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.
The application gets cached but the data does not. We're looking at ways to improve the initial load time.
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.
I am not a parent, but from UX perspective I think you just got a feedback which says the action is either too hidden or not useful enough. :) (it's a single complaint, though)
Yeah, I've answered that questions a few times in the last couple of days. It was also asked a bit when first release the mobile web app a while back. It's on my list to bring it up with the UI team soon :)
I agree with this as well, though it will be buried deep in an individual thread. We don't like making knee-jerk responses to the political posturing by our politicians, because they don't influence what we see.
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.
I think that's not really the issue. It's moreso will you allow authorities to plant data on your servers to frame users. That seems to be what's being talked about.
So if you plan to cooperate fully then that's fine. But you will likely lose a ton of customers.
Us too. We don't want to blog every time our government postures about something, but we agree that there are problems with the way policy and laws are being made in Australia.
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..
I've been no waiting for this for so long! I have been using K9, and I love using a FOSS email client, but having native Fastmail support is just so much better.
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.
It was actually a really interesting development process. We already had the web app, and our main UI developer is an Apple guy, so he took on the iOS version. Meanwhile I'm primarily a Linux guy and work on FastMail's backend services, but also an Android user, so I did the Android version.
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.
So, hosting email has two hard parts:
- Spam filtering incoming mail.
- Sending mail in a way that the other end will accept.
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.
I have been using fastmail for a month now after switching from gmail. I quite like it, but the two drawbacks are that it's just a little bit more likely to let spam in than gmail, even with aggressive spam options enabled, and with fastmail I'm missing out on the growing gmail ecosystem (Streak, Dropbox mailbox app, others).
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 talking to Dropbox about mailbox app - hopefully it will support us soon, as with everything it's a matter of engineering resources.
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.
That's great to hear. Regarding the Android app having just checked it out, my first request, if you're taking them, is multiple account support. I can only log into one fastmail.com account at a time with what is here now. The reason I have two accounts is because I have two domains that get emails. Otherwise seems like a solid app. I'll probably start using this as my calendar app. :)
http://jmap.io/ seems pretty awesome, I guess I can use that to build my own fastmail app integration?
> That's great to hear. Regarding the Android app having just checked it out, my first request, if you're taking them, is multiple account support. I can only log into one fastmail.com account at a time with what is here now. The reason I have two accounts is because I have two domains that get emails.
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?
JMAP does indeed look very interesting. In my (very, very slow) path towards writing my own email client, I've also come to expect that a new, simpler protocol is probably a better bet than imap. Partly this belief is bolstered by the fact that the creator of sup went on to make heliotrope: https://github.com/sup-heliotrope/heliotrope
[ed: I suppose the canonical repo is https://github.com/wmorgan/heliotrope -- but afaik they are the same (and both appear dead)]
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).
Regarding heliotrope: wmorgan has left the field a long time ago to our great despair. He did start heliotrope, which I hacked a bit because it looked cool. I even started a heliotrope-to-imap bridge [0]. After a while the community decided to create a common repository to host them, at which time I abandoned heliotrope because its client was still too buggy and sup was already working very well, and I needed a working MUA.
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 !
I think I'd probably gravitate more towards notmuch and friends, if I were to use a (in notmuch's case, almost) "ready to go" mua. However, I've yet to find a mua that's simple enough, and also does what I want (Steve Kemp's lumail is another interesting project[1]).
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).
You must be aware that notmuch is only the search backend, and for a full MUA you need frontends. I believe the official one is the Emacs one, so it should be fairly usable. There's also a web one [0] you should be able to play with.
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.
Hm, we're too deep it seems. So replying to myself.
> 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.
> 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:
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).
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.
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 ;-).
Not yet. We're working on a small server and client to act as a reference implementation, and there are longer-term plans to build it directly into Cyrus. We're also planning to do a proxy that you can put in front of any IMAP server to make it talk JMAP.
Mailbox App gets access to and copies your Gmail server-side. In addition Dropbox has Condileeza Rice on its board. So for people switching to Fastmail out of privacy concerns, don't bother. It would be better if we users would ditch Dropbox and Mailbox App (which I love, so not easy for me to say) in the same spirit we want to ditch Gmail.
with fastmail I'm missing out on the growing gmail ecosystem (Streak, Dropbox mailbox app, others).
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 have the opposite complaint, Fastmail marks my bank receipts as Spam, but I don't mind at all.
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.
FastMail looks tempting. But, excusez-moi, it seems quite expensive for what (you seem to) get. I have an email archive that's around 20GB on server. That would cost me $120 a year.
Right now I'm paying for a Dreamhost account. For around $100 a year I get "unlimited" storage, IMAP access, Roundcube access and support for domains. And this is only besides all the shared hosting features has never let me down so far.
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?
Dreamhost is not a great mail host. Before moving my email to Google Apps for Domains I found Dreamhost's IMAP and SMTP notably slower and not super-relable (not constant failures but enough to notice). Do they even have any meaningful spam filtering?
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.
I'm not sure what Dreamhost's e-mail offering is like, but I chose FastMail over running my own e-mail server because I'm not enough of a sysadmin to be confident in setting up and maintaining my own e-mail server without opening it up to abuse (there are enough involuntary spam relays already).
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).
Actually, with any reasonable smtp server, the defaults these days are pretty good -- so email abuse/open relay isn't the problem it once was. The hurdle (if any) these days is making sure email you send isn't flagged as spam, and to a lesser extent to avoid receiving spam (I say lesser, but then I've been running greylisting from day one, which is a minor nuisance, in and off itself).
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.
Sure, but it can still be quite daunting if you're not much of a sysadmin. I'm a web developer primarily and though I feel confident setting up a basic web server and SSH, I'm not even entirely sure what software I need or should use (when there are multiple alternatives) to set up a fully working e-mail server.
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.
There is a bit of a documentation vacuum. We (Linux users, admins and developers) could learn a lot from freebsd and openbsd here. Something like https://packages.debian.org/wheezy/task-mail-server gets you on your way (maybe too far, actually -- you probably don't want/need all that for an initial setup) -- but certificate requests, and certificates is still too hard.
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.
> 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.
Speaking as a recent convert to Fastmail from Gmail and Dreamhosts roundcube offering I have to say Fastmail is a hell of a lot better experience, it's quick, uncomplicated, and slick with great keyboard shortcuts. Roundcube on Dreamhost is fine for what it is but couldn't be compared with Gmail in terms of usability, Fastmail can. Don't get me wrong I'm not sure its as good as Gmail (spam protection for example is not as good), but you're getting a vastly better webmail experience than Roundcube.
Is there any way to sync my contacts/calendar such that they are available outside of the Fastmail app? For me that is the only reason I haven't completely switched over to Fastmail. There doesn't appear to exist a nice solution on Android to do that.
The main feature of the Android app is push notifications, which requires Google Play Services. A version of the app without push notifications is pretty much identical to just using the regular web app in Chrome Android, so there didn't seem to be a lot of point doing distribution via other means (with the extra maintenance overhead that brings).
If there's enough demand for something else then we'll be happy to revisit this.
That's odd. I remember the K9 email client working on a phone with CyanogenMod and without Google Play or the other Google services and I was getting notifications on new emails.
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...
> That's odd. I remember the K9 email client working on a phone with CyanogenMod and without Google Play or the other Google services and I was getting notifications on new emails.
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 am on fastmail and use android without Google Play Services (and would think that a significant proportion of your customers have moved to you from gmail because they care about things that might lead them to avoid google play services). Having said that, I'm happy enough using an IMAP mail client.
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.
I concur with this request. There are many new devices that don't ship with Play services and to facilitate them your apk will eventually be ripped and hosted on sites with little guarantee of authenticity.
So instead it would be great to have a direct, trustworthy download link with checksums / signature.
On Android I keep getting "Sorry, legacy Guest/Member accounts are not supported. Please upgrade your account to use the FastMail app". I only signed up a few months ago, and can't find any options for an upgrade. Help?
(p.s. Excited to try it out!)
Edit: I am using a custom domain (a few different business accounts) if that is relevant.
It seems to only be a slick wrapper around the website. No options, no unread message count on the icon, no ability to easily switch between mail and calendar...
I love FastMail, and can't wait to see where they go with a 2.0 release.
It _should_ have an unread message count on the icon. But yes, the iOS version's only significant feature over the regular web app is the addition of realtime push notifications.
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 :)
I would love FastMail to add tags or labels. That is the one primary feature making me still forward my FastMail email to Gmail. I love having email in my inbox already labeled (or tagged) so I can have context.
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.
In FastMail you could already search based on some of the email headers, like from:thatpurplecompany.com (or has:attachment, https://www.fastmail.fm/help/receive/search.html) and then you could save the search.. It's visually not that rich, but it solves your problem.
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.
Why are you comparing it to google? It's pretty obvious Google offers no support.
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.
actually, nevermind. I see (at least on android) that all this bacially is a webview of the default mobile interface. (which works quite nicely by the way...)
There's more in there than just the webview: all the push channel and notification stuff, a JMAP client, a Gravatar client and cache, sharing stuff, smartwatch hooks, etc. That said, none of it is particularly interesting or difficult.
No plans to open source it at the moment, but we might if there was sufficient demand.
Thrilled to see FastMail tastefully and respectfully grow their ecosystem. I can see that, at least for the iOS app, it's pretty much a web view wrapper; I'm willing to give it a pass for the most part because FastMail's webapp is one of the best I've used… ever.
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.
> We have notification actions, extensibility, file sharing, and a Pebble SDK too, y'know.
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 :)
There are free and open source implementations of Exchange ActiveSync that would allow native push support on iOS. Any particular reason you haven't pursued this?
> What is the one good reason for me to opt fastmail?
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 :)
Haha. Yeah, they're in New York. Our offices are in Australia though, so its in our best interests to make sure things go fast! I can only imagine what it must be like for people actually in the US :)
It won't be this year. We hadn't even considered this feature before so it needs to be investigated and then if we want to do it, designed, implemented and tested. That doesn't have to take a lot of time, but we have other priorities first.
Really really glad to see this. Lack of push notifications on iOS has long been a sore point for me with FastMail. Still don't understand the technical or legal issues behind not offering Exchange compatibility as many of their competitors do though. That would allow push notifications with the native Mail app.
I'm bummed that this is a brand new iOS app with no legacy history but it still doesn't add a button to use extensions at the login page. I use 1Password to store my login information, and it's a much better first-run experience if I can trigger the 1Password extension to login.
Sure, Australian government will soon spy on you if you use Fastmail. But every other mail provider is spied on by US government at least. And Australia is an enlightened first world country so unless you're doing something illegal, you might as well consider it better than being spied on by US government.
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...