https://en.wikipedia.org/wiki/SquirrelMail The Wikipedia page indicates that Squirrelmail is no longer maintained. I've had a problem reported with it after upgrading to PHP 7.3. Is there a good replacement for Squirrelmail? Something simple and lightweight that just gets the job done. Not Horde. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 29/5/20 9:29 am, Russell Coker wrote:
https://en.wikipedia.org/wiki/SquirrelMail
The Wikipedia page indicates that Squirrelmail is no longer maintained. I've had a problem reported with it after upgrading to PHP 7.3. Is there a good replacement for Squirrelmail? Something simple and lightweight that just gets the job done. Not Horde.
Roundcube, seems to be ok. Mike
On Fri, May 29, 2020 at 10:08:50AM +0930, Mike O'Connor via luv-main wrote:
Roundcube, seems to be ok.
Every instance of Squirrelmail I've seen has migrated to Roundcube. After a quick look through their documentation; the former doesn't appear to require a relational database, while the latter does. Let that be MySQL, PostgreSQL, or sqlite. I wouldn't trust any PHP or SQL stack but I don't have any better suggestions for webmail. Attached below, major security update just a month ago. If you install Roundcube, be careful with the versions. --- https://roundcube.net/news/2020/04/29/security-updates-1.4.4-1.3.11-and-1.2.... = Security updates 1.4.4, 1.3.11 and 1.2.10 released 29 April 2020 We just published service and security updates to the stable version 1.4 and the LTS versions 1.3 and 1.2 of Roundcube Webmail. They contain four fixes for recently reported security vulnerabilities as well a number of general improvements from our issue tracker. == Security fixes * CSRF attack can cause an authenticated user to be logged out * Cross-Site Scripting (XSS) via malicious HTML content (CVE-2020-12625)+ * Remote code execution via crafted config options (CVE-2020-12641)+ * Path traversal vulnerability allowing local file inclusion via crafted ‘plugins’ option (CVE-2020-12640)+ The latter two vulnerabilities are classified minor because they only affect Roundcube installations with public access to the Roundcube installer. That’s generally a high-risk situation and is expected to be rare or practically non-existent in productive Roundcube deployments. However, the fixes are done in core in order to also prevent from future and yet unknown attack vectors. See the full changelogs in the release notes on the Github download pages for the updated versions 1.4.4, 1.3.11 and 1.2.10. We strongly recommend to update all productive installations of Roundcube with this new versions. + Credits to the security researchers: Matei “Mal” Badanoiu and <Other_Guy/Girl>
On Friday, 29 May 2020 11:20:45 AM AEST James McGlashan via luv-main wrote:
On Fri, May 29, 2020 at 10:08:50AM +0930, Mike O'Connor via luv-main wrote:
Roundcube, seems to be ok.
Every instance of Squirrelmail I've seen has migrated to Roundcube.
I've just installed Roundcube. The problem I had was that one significant webmail user complained that Squirrelmail had started messing up the display of some messages, I suspect it was due to the transition of certain MUAs to sending base64 encoded Subject lines etc (but never got to the bottom of it - my email worked fine in Squirrelmail). Another significant webmail user then complained that Roundcube didn't render properly on the latest Galaxy Note phonem, he showed me screen shots of it only using half the screen width. So now I'm supporting 2 webmail systems.
After a quick look through their documentation; the former doesn't appear to require a relational database, while the latter does. Let that be MySQL, PostgreSQL, or sqlite.
You need to store webmail settings somewhere. Using a choice of sqlite or a database server allows running multiple web servers with a single database server backend. Using just flat files as Squirrelmail does means you probably need a distributed filesystem (or at least an NFS server) if you want to have multiple web frontends.
I wouldn't trust any PHP or SQL stack but I don't have any better suggestions for webmail.
A SQL server is a lot easier to get right than a distributed filesystem. Even an NFS server can make things more difficult.
Attached below, major security update just a month ago. If you install Roundcube, be careful with the versions.
I'll trust the Debian developers to package the security updates fast enough. Thanks for the suggestions. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Hi Russell On 9 June 2020 10:35:14 am AEST, Russell Coker via luv-main <luv-main@luv.asn.au> wrote:
On Friday, 29 May 2020 11:20:45 AM AEST James McGlashan via luv-main wrote:
On Fri, May 29, 2020 at 10:08:50AM +0930, Mike O'Connor via luv-main wrote:
Roundcube, seems to be ok.
Every instance of Squirrelmail I've seen has migrated to Roundcube.
I've just installed Roundcube. The problem I had was that one significant webmail user complained that Squirrelmail had started messing up the display of some messages, I suspect it was due to the transition of certain MUAs to sending base64 encoded Subject lines etc (but never got to the bottom of it - my email worked fine in Squirrelmail).
Another significant webmail user then complained that Roundcube didn't render properly on the latest Galaxy Note phonem, he showed me screen shots of it only using half the screen width.
There is a plugin for roundcube that might help It is elastic4mobile https://packagist.org/packages/roundcube/elastic4mobile Cheers Niv
So now I'm supporting 2 webmail systems.
After a quick look through their documentation; the former doesn't appear to require a relational database, while the latter does. Let that be MySQL, PostgreSQL, or sqlite.
You need to store webmail settings somewhere. Using a choice of sqlite or a database server allows running multiple web servers with a single database server backend. Using just flat files as Squirrelmail does means you probably need a distributed filesystem (or at least an NFS server) if you want to have multiple web frontends.
I wouldn't trust any PHP or SQL stack but I don't have any better suggestions for webmail.
A SQL server is a lot easier to get right than a distributed filesystem. Even an NFS server can make things more difficult.
Attached below, major security update just a month ago. If you install Roundcube, be careful with the versions.
I'll trust the Debian developers to package the security updates fast enough.
Thanks for the suggestions.
-- Sent from my mobile device Please excuse autocorrect.
On Tuesday, 9 June 2020 11:55:35 AM AEST Nic Baxter via luv-main wrote:
There is a plugin for roundcube that might help It is elastic4mobile
Thanks for that, I might try it out. When looking through the Roundcube settings under Mailbox View there's an option for a "list" layout (widescreen is the default). I'll point that out and hopefully the user in question will be happy. I'm not trying to make something that's good for everyone, just good for the few people who use it so I can move on to something else. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Tue, Jun 09, 2020 at 10:35:14AM +1000, Russell Coker via luv-main wrote:
On Friday, 29 May 2020 11:20:45 AM AEST James McGlashan via luv-main wrote:
After a quick look through their documentation; the former doesn't appear to require a relational database, while the latter does. Let that be MySQL, PostgreSQL, or sqlite.
You need to store webmail settings somewhere. Using a choice of sqlite or a database server allows running multiple web servers with a single database server backend. Using just flat files as Squirrelmail does means you probably need a distributed filesystem (or at least an NFS server) if you want to have multiple web frontends.
I advise against sharing a sensitive service (database) among unrelated services (email and websites). Isolation is simple; confused deputies are not. Just as it is dangerous for a webapp to be able to change or add to its own code dynamically, much worse if it can touch the code for other webapps. It is dangerous for a webapp to connect to and share a database server used by other applications. It is common for email servers to accept unauthenticated clients from 127.0.0.1 and allow them to send email as any other user. Webmail clients tend to inherit this undesired power, which enables a user to impersonate another. Similarly, a web application which isn't email shouldn't have the ability to send email. Either by interacting with the local SMTP service which can do DKIM signatures or by connecting to external SMTP servers. If you need consistency between replicas; you likely don't need synchronous global consistency. Eventual consistency is generally sufficient and promotes locality which doesn't result in downtime under network partitions between the replicas. SQL is too complicated and provides stronger properties which forbid this optimization. To be clear; I'm thinking architecturally as if I were to implement this; to determine the properties to look for in an ideal solution hopefully already written by another. This does not appear to be the case.
I wouldn't trust any PHP or SQL stack but I don't have any better suggestions for webmail.
A SQL server is a lot easier to get right than a distributed filesystem. Even an NFS server can make things more difficult.
By trust I'm referring to all the PHP code vulnerable to XSS, SQLi, CSRF, et al issues not present with safer languages and libraries. PHP makes it too easy to express XSS and its legacy database interfaces make it too easy to express SQLi. Last I checked PHP's defaults were tuned for developers privately debugging their applications, which broadcasts sensitive information (including database credentials) when errors occur. I advise against complex stacks littered with poor design decisions. PHP and SQL are two hot examples. If you're writing an application which doesn't need relational data, a key-value store (such as [Anna]) is likely sufficient. If you need relational data, then [DataLog] is much more expressive with a fraction of the syntax of SQL. Unlike SQL, DataLog scales with complex graph queries. Relational data is useful for a webmail client when a user wants to perform a filter over a large mailbox. Relational data is overkill for simple preferences and contact lists. I have found some webmail clients written in safer languages but none are sufficiently feature complete or maintained or unbundled from other bloat or otherwise suitable for production use. [Anna]: https://blog.acolyer.org/2018/03/27/anna-a-kvs-for-any-scale/ [DataLog]: https://en.wikipedia.org/wiki/Datalog
participants (4)
-
James McGlashan -
Mike O'Connor -
Nic Baxter -
Russell Coker