[swartkrans]

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.

[brongondwana]

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.

[swartkrans]

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?

Thanks for all the hard work on fastmail!

[robn_fastmail]

> 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?

That's the intent, though we're not there yet.

[e12e]

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

[rakoo]

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 !

[0] https://github.com/rakoo/imaptrope

[e12e]

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

[robn_fastmail]

> Is the code on: http://jmap.io/server.html actual code?

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

You might like to sign up and lurk there. I'll be posting to it soon (maybe tonight) to get the ball rolling on a few things.

[e12e]

Thanks, and for those, like me, that want to sign up with a regular mail account (say, like a fastmail account;) -- one can do that via the web at:

https://groups.google.com/forum/#!forum/jmap-discuss/join (ie: group-url+/join), or by emailing <groupname, spaces replaced with dashes>[e-mail].

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 ;-).

[mwcampbell]

JMAP looks interesting. Is there an implementation yet for any open-source IMAP servers, like Dovecot or Cyrus?

[robn_fastmail]

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.

[eevilspock]

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.

[josteink]

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.

[Aldo_MX]

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.