TFA was simply a look at webmail clients. Since, as you pointed out, the webmail client installed as part of iRedMail is Roundcube, there wasn't any point in explicitly highlighting iRedMail.
I've tried roundcube & squirrel mail, and wasn't able to maintain the switch. I support open source anything, but I need gmail level service for my e-mail.
Strangely enough, email is a outdated protocol left over from the 90s, with its lack of seamless encryption, no real API standard (JMAP tries), etc... Seems fitting that clients look appropriately outdated.
Some of them were. And, UI is a hard problem that rarely gets a lot of attention in Open Source. For many reasons, designers very rarely donate time and effort to helping out OSS projects, while coders much more often do...so, even if the technical side of an OSS project is solid and reasonably modern, the UI may trail many years behind.
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).
How do those affect the amount of spam you receive?
I thought they were just to make it less likely your outgoing mail would be marked as spam by someone else.
> I thought they were just to make it less likely your outgoing mail would be marked as spam by someone else.
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.
Google's spam filtering is currently useless, IMO. It's too aggressive, so you have to regularly check your spam box for messages. If I have to check the spam box regularly, why bother having one?
This is true of any spam filter. You either have it set as too aggressive or you don't. You either put up with spam that gets through or you check your spam box more often. Google's is better than most.
When it comes to spam, Gmail has an advantage of scale. For example, if the same message is sent to thousands of email accounts, Gmail can detect this and mark the message as spam (or increase a penalty).
I'm not sure how one could parallel this kind of behavior in a self-hosted mail solution.
The are not real comparisons with Gmail with is a web-based client, an email server and a managed service.
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.
Maybe have a look at mailinabox [1] on your own server, that would actually come close to a proper comparision? Have been running it under Docker for half a year or so and had no real problems so far. Setup is easy enough in comparision with a complete DIY server. Community is fairly active as well.
I've used Virtualmin and Horde for my personal email service. Virtualmin does a very good job configuring Dovecot, Spamassassin, Postfix, DNS, Apache/Nginx, etc and Horde is a very good web client for email, contacts, calaendar etc.
I'm happy Virtualmin is working well for you. We've been working quite a bit lately on making Usermin nicer as a mail client, as well (not to discourage use of Horde or others; we also provide easy installers for Roundcube, SquirrelMail, and a couple of other webmail clients...some are even free in the GPL version).
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).
Why does everyone make these with PHP? Serious question.
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.
The same goes for forum software, but what bothers me more than PHP is that these things usually only work with MySQL. Is this due to shared hosting providers usually only supporting MySQL and not PostgreSQL, or what is the reason? I honestly don't understand.
The Linux/Apache/MySQL/PHP stack was the hotness about a decade ago, so that's the kind of hosting that was most available. Shared hosting was much more popular (physical hosting was more expensive, VMs were expensive and new, and tooling was worse).
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.
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.
I agree. It's bad for performance, security, and maintenance. Any time I see PHP I'm thinking: is what they did worth the re-write effort? Despite that, people keep making good apps in it. Starting to wonder if it's worthwhile to do an automated porting tool along lines of Semantic Designs' DMS toolkit. Just to keep the apps, current and future.
> It's bad for performance, security, and maintenance.
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.
Python was my main point of comparison actually. Better across board aside from performance which I'd have to test more. While PHP was easily smashed, Coverity consistently reported a low defect rate for Python.
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.
While I share your skepticism for PHP the language, PHP is a very mature platform with well understood deployment modes.
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.
The target market for Roundcube at least (which I have made some very small contributions to) is small ISPs, and outside of HN and a few other developer enclaves, nobody in the ISP market cares about Python or Ruby or whatever else is sexy today.
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.
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).
Let's remember Gmail's primary business model is snooping and selling out customers. Best to not do business with such companies, esp if you have valuable data. Self-hosting was a great idea even before the Snowden leaks made it a better idea.
Google's business model is about data mining and targeted advertising, not about selling someone's private, identifiable data. That's a big difference.
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.
What's the experience like, is it worth investing time/energy in using this? I reckon that they are also suffering from the same problem, of people not being able to easily migrate from their long-standing email address(es).
If you don't need open-source, but instead just want to migrate away from advertising-supported email, I find that FastMail works pretty great and is cheap to boot.
I've found the mail app from Zoho to be very good (assuming you have your own domain). It's obviously not perfect, and there are always pros/cons when switching between apps.
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.
It's not an alternative if you are looking for a web based interface, but I wrote gpgmda[1] (which integrates the alot MUA) to move myself off gmail when the TOS changed a few years ago.
69 comments
[ 3.4 ms ] story [ 109 ms ] threadI've been running my own mailserver for ~10 years and pretty much never have problems with deliverability.
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
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.
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.
[1] https://mailinabox.email/
https://cloudfleet.io/
(currently in development - looking to launch around November)
Spam filtering techniques (and subsequent techniques for circumventing them) are constantly changing.
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).
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.
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).
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.
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.
[1] https://github.com/jakeogh/gpgmda