Interesting concept, especially with the recent changes Google has made to GMail/Apps. The biggest benefit/downside that jumps out at me is the complexity required to run an email system this way - Cassandra clusters, LDAP, external MTAs, and web severs all need to be managed. Obviously every email system requires these components to run, but most full-blown systems handle the relationships between components on their own.
TL;DR - Looks great for large businesses or maybe as a platform for a startup, but not as a hobbyist project.
I was thinking the exact same thing, I'd love to test it out, but for the moment (it might change in the future, I'm being hopeful) it's a tad too complex to setup for even a test ... I will keep an eye on the project though!
This really does appeal to me, but I wish it didn't rely on Cassandra. That's a heavy dependency if you would otherwise have no java in your stack which many mail servers probably wouldn't. It's certainly an interesting departure from flat files or standard databases though.
hmm. email is one of the things that scales extremely good (see dovecot's directors for a sophisticated but simple way). i don't know why you will need such a big hammer.
Well yes, but they usually rely on traditional storage methods (on disk or via something like NFS shares). Normally they use sharding based on the mailbox name and spread it across multiple storage backends.
The only mailserver before this that stepped away from this methodology as far as I can remember was DBMail, but it suffered from many other issues instead.
Using Blob-store like S3 (with some kind of encryption) combined with a db with metadata makes a lot of sense to me for this application. Alternatively, storing it all in something like MongoDB's ReplicaSet would also be interesting.
Now, if ElasticInbox is the best tool for this is a separate discussion, but this type of architecture sure is compelling.
TL;DR - Looks great for large businesses or maybe as a platform for a startup, but not as a hobbyist project.