Open-source alternatives to GMail
opensource.com
opensource.com
Maybe it "just works" but all of these projects feel ancient to me because of their stack despite being brand new. Sure as a user it doesn't matter but as the maintainer/administrator I just don't want to deal with it. Modphp? Yuck.
We don't always need to use the new new thing all the time but I can't shake the feeling that the same person who runs this is also rocking an unpached PHPMyAdmin and PHPMySQL.
In 2025 someone might ask why $oldStack developers don't always do $newHotness. It's often the timing of popularity that tools grow together.
This is just apocrypha, but MySQL was popular during the rise of PHP because MySQL was more performant on small databases on developer workstations.
Plus, who can you trust nowadays?
Asking as a noob who started learning JS and Python :-)
It makes sense to go all JavaScript, especially since Node.js seems to offer some advantages over Python.
I commented in the first place because I was surprised that Kite uses JS+Python, a unique combination for an email client from what I've seen (which is not a lot).
I'm not interested, nor do I have the capabilities to make an email client (I can reskin RoundCube or use Gmail) or any app, for now.
But the reason I want to learn JavaScript, as well as Python, is because I want to get a feel of how both work, and not get binned in the "uses JavaScript for everything" category, which seems to be a bad thing :-).
It was hard to decide on a language to learn by myself, C and Java are recommended, but look hard to begin with. I don't want to get discouraged early on.
JavaScript is always needed (monetary opportunities) and rather easy, Python also seems easy to learn and very flexible. Ruby was my other choice, but I feel like I'm going to get overwhelmed studying them all at once.
Compared to what, exactly? Ruby? I'll give you Node for double performance and roughly equivalent (and annoying) maintenance, but PHP's security story, with or without the various popular frameworks, is at least as good. Any stack built on the JVM has its own set of tradeoffs -- I would rather maintain PHP than any standard JavaEE solution, but I would rather maintain anything built on Clojure's Ring than PHP. These days Python with Flask is my go-to solution for quick things where I might have used PHP in the past, but even then there are tradeoffs, near the top being you can't just deploy to any shared hosting service that's been around for over a decade.
Other alternatives included about any safe, systems or apps language of the time. Ada, Pascal, industrial BASIC, Smalltalk, Common LISP, Ocaml, Eiffel, and so on. Even subsets of C++ and Java using simpler frameworks were better for some although I didn't try that haha. REBOL might have had something then, too. Didn't get around go trying it, though.
It's very rare to find someone deploying with mod_php today. The security implications are too dire, and the performance/memory usage is problematic. There are a number of ways to run PHP under a reasonably modern app server model, and with the security of suexec. FPM being the most modern, but there are lots of mod_fcgid deployments out there, as well.
I'm not a fan of coding in PHP, but it's still a reasonable choice for developing applications that you want to be able to run everywhere. In fact, if your goal is to make something people will use very widely, PHP may still be the best choice for web apps. There are still lots of shared hosting accounts out there (I know, I can't believe it either, in a world with so many low cost virtualized options), and many can only reasonably run PHP apps.
As an example, I run one of the applications mentioned here for several customers in chrooted read-only no-exec environments without fuss. The platform gives me good tools for instrumentation and logging in order to work proactively withever operations issues that arise.
Even if your (or mine) favourite language had a community large enough to develop great webmail tools, very few has a deployment story to match.
Wordpress runs on PHP. Drupal runs on PHP. Joomla runs on PHP. Ergo, ISPs know how to build servers that run PHP. Ergo, if you're writing software that targets the ISP market, you write it in PHP.
On this list, I believe at only Zimbra provides all of these options, but the article really only looks at the client.
Having run my own email server for about 10 years (1996-2006), I eventually gave up due to the huge amount of work it took to stay secure, current with email server "policy" and deal with spam.
I have always either run my own server or paid for the service. I have never used Gmail beyond a use as a testing and backup email account.
(currently in development - looking to launch around November)
Spam filtering techniques (and subsequent techniques for circumventing them) are constantly changing.
Anyone with an email address older than 5 years is going to be buried in spam thus will need spam filtering with a super low false positive rate.
Setting it up can mean that you check these things on the receiving end. Big difference between self-hosting and accepting all e-mails and self-hosting and checking the sender's SPF and DKIM.
That said, it will reduce bounce-back from spam that forges your domain.
I'm not sure how one could parallel this kind of behavior in a self-hosted mail solution.
I've had my current domain for 10 years, don't run any spam filtering ( just fail2ban ) and I've had fewer pieces of spam than I have fingers.
So whatever you're doing... Stop doing it.
We're planning a major new release as soon as I finish the new website and we get some integration work done, that completely overhauls the UI in Virtualmin/Webmin and Usermin, which I think is the biggest issue with Usermin for webmail and one of the reasons I don't even use Usermin heavily for mail (I use Thunderbird on my laptop and GMail on my phone).
It has a nice mail interface plus calendaring and even provides mobile device integration via an Exchange compatible interface (so your mobile device calendar and email integrates using the Exchange connector).
I've never understood why it does not get more traction (or mention on HN).
I've been running my own mailserver for ~10 years and pretty much never have problems with deliverability.
I found it relatively quick to setup and get working. And compared to Google-apps for business, it is free for X amount of users per domain.
Not affiliated to them in any way, just thought I'd share what I've been using recently alongside my main gmail user account.
Actually I trust Google more than anyone else that they do everything they can to keep anyone's private data private. The problem is that that doesn't help when a government agency walks in with a secret court order, be it legitimate or illegitimate.
That's why european end users (and corporations w/ valuable IP) walk away from US based cloud providers or even want to go back to being all self hosted. You can't be 100% sure about your data safety with them and you'll be in deep trouble with your own customers if a data breach - be it lawful under US law, but not under european law - should happen.
It takes a few years to build a solid mail client with volunteer labor (or even with paid labor; Mailpile, while promising, is nowhere near ready for production use, for example), so none of the full-featured, stable, ones you'll find are newer than five+ years old, and many are much older, and often the designs were made as an afterthought by the developer rather than someone focused on design.
Open Source has always had a problem with UI quality. That's not new, or specific to webmail. I don't know the solution (the webmail I work on, Usermin, is getting its first UI overhaul in about a decade, as we speak, and only because a good UI person stepped up and started working on it on a volunteer basis, and then we started paying him).
[0] https://www.indiegogo.com/projects/roundcube-next--2#/story