Software-update: Roundcube Webmail 1.7.0

Versie 1.7.0 van Roundcube Webmail is uitgekomen. Roundcube Webmail biedt een webinterface om e-mail te kunnen lezen en verzenden. Het heeft onder andere ondersteuning voor gedeelde mappen en namespaces, internationalized domain names en SMTP-afleverstatusnotificaties. Daarnaast is de gebruikersinterface voor IMAP-mappen aangepast om zo meer ruimte te bieden voor extensies en plug-ins. De changelog voor versie 1.7.0 kan hieronder worden gevonden:

Roundcube 1.7.0 released

After almost four years of development we introduce a few breaking changes, some new features, and bring support for recent PHP versions. With automated code style and quality checks, removed code bloat and updated dependencies, we hope for even more codebase quality.

Some noteworthy changes are:

• Mandatory public_html/ entry-point for HTTP servers, protecting all installations better.
• Improved OAuth2/OIDC support (e.g. support for OIDC discovery, OIDC logout).
• Markdown mail rendering and composing.
• A quick actions mouse-over menu on the messages list.
• Advanced mail search syntax.

Breaking Changes:

• Dropped support for PHP < 8.1.
• Dropped support for Internet Explorer.
• Dropped support for MS SQL Server and Oracle.
• public_html/ entry-point made mandatory, all static resources are served via public_html/static.php.
• Removed apc cache driver (replaced by apcu cache driver).
• Changed smtp_log option default value to false.
• Removed contact_search_name option in favor of contactlist_name_template.
• Replaced session property changed by expires_at.
• Removed the (insecure) virtualmin password driver.

This release is considered stable and we encourage you to update your productive installations after carefully testing the upgrade scenario. With the release of Roundcube 1.7.0, the previous stable release branch 1.6.x changes into an LTS (low maintenance) mode which means it will only receive important security updates. The 1.5.x series is no longer supported and maintained.

See the full changelog in the release notes on the Github download page, but don’t forget about previous release canditate and beta releases.

Versienummer	1.7.0
Releasestatus	Final
Besturingssystemen	Scripttaal
Website	Roundcube Webmail
Download	https://roundcube.net/download/
Licentietype	GPL

Reacties (12)

[Hans van Eijsden]

Pas op met het zomaar updaten naar versie 1.7.0 wanneer je gelijktijdige gebruikers hebt. Niet alleen is de webroot gewijzigd, maar alle requests naar statische bestanden lopen nu via static.php in plaats van rechtstreeks via de webserver. Daardoor wordt voor elk statisch bestand (zoals afbeeldingen, scripts, CSS-bestanden en bijlagen) PHP uitgevoerd. Elke paginaweergave gebruikt hierdoor meerdere PHP-FPM-processen, wat extra belasting veroorzaakt. Dit is niet schaalbaar, niet voor PHP te cachen en bovendien geen best practice.

Voor productieomgevingen ben ik vanwege deze schaalbaarheidsproblemen teruggegaan naar versie 1.6.15.

[Oon]

Je kunt toch gewoon nginx vertellen dat die gecached moeten worden door de headers te overschrijven? Dan wordt het in ieder geval door de browser cache afgevangen

[Hans van Eijsden]

Client-side caching kan maar beperkt verschil maken. Wanneer op maandagochtend om kantoortijd 9.00 uur alle 800 gebruikers inloggen, is de impact aanzienlijk. Voorheen betekende dat maximaal 1.600 PHP-processen, ervan uitgaande dat iedereen exact om 9.00 uur via PHP een database-loginquery uitvoert. Nu gaat het om 800 gebruikers × gemiddeld 27 resources = 21.600 processen. Bovendien doven deze processen niet direct uit, maar blijven ze grotendeels in keep-alive actief.

Daarnaast blijft de serveromgeving niet langer even responsief; de prestaties worden veel variabeler, afhankelijk van de actuele belasting.

In mijn situatie praten we over een theoretisch maximum van 800 × 80 MB per proces = 64 GB RAM in versie 1.6 tegenover 21.600 × 80 MB = circa 1,7 TB RAM in versie 1.7, ervan uitgaande dat gebruikers niet op elkaar hoeven te wachten en allemaal gelijktijdig PHP kunnen aanspreken.

Voor mij is het verschil tussen versie 1.6 en 1.7 daarmee financieel te groot om het platform voldoende snel en responsief te houden.

[pietermx]

Er vanuit gaande dat correcte caching headers al aanwezig zijn vanuit roundcube, zet er Varnish of een andere caching proxy voor?

[Hans van Eijsden]

Een Varnish-cache, of nog directer een Nginx met een FastCGI-cache via Redis aan de front-end, kan inderdaad verschil maken (al gebruik ik die laatste met een lage TTL al decennia in productie). Zodra iemand echter is ingelogd, krijgt die gebruiker een unieke sessie-ID en/of specifieke cookiewaarden. Die zijn per definitie uniek en daardoor alleen per gebruikerssessie cachebaar. Horizontaal schalen via gedeelde caching levert in dat geval dus nauwelijks voordeel op, omdat de cache per gebruiker verschilt. Daarmee verdwijnt de schaalbaarheid grotendeels alsnog.

[pietermx]

Lijkt me niet dat static content wordt bepaald o.b.v. een cookie / sessie of andere privacy gevoelige data. Strip de headers, als die al ge-set worden, eruit. Negeer ze bij het genereren van een hash.

[smesjz]

Klopt, https://github.com/roundcube/roundcubemail/blob/master/public_html/static.php laat zien dat er geen enkele sessie / cookie wordt gebruikt.

Daarnaast slaat "Nginx met een FastCGI-cache via Redis aan de front-end" nergens op. FastCGI-cache gebeurt op disk. En Redis kan los van nginx/Varnish gebruikt worden binnen Roundcube voor wat zaken maar (uiteraard) niet met nginx, zijn gewoon hele andere technieken.

[RobertMe]

PHP-FPM maakt alleen niet ongelimiteerd processen aan. 1.600 processen, 21.600 processen, .... Allemaal totaal uit de lucht gegrepen. PHP-FPM spawnt maximaal het aantal processen dat in de PHP-FPM config staat onder pm.max_children. En die optie heeft geen default en moet je zelf configureren. Waarbij een substantieel hoger aantal max processen dan het aantal cores mij nu niet echt verstandig lijkt. Sure, 2 of 3 keer het aantal cores kan wellicht prima werken (afhankelijk van waar je limitaties zitten). Maar kleine kans dat je een server hebt met 2.000 cores en vervolgens PHP-FPM een 10-voud aan het aantal cores aan processen laat spawnen.

Kans die vele, vele, vele malen groter is is dat je aan het maximaal aantal processen zit en daardoor de requests op elkaar blijven wachten (dus 10 processen, daardoor max 10 requests, en request 11 moet wachten tot 1 van de vorige 10 klaar is voordat die kan starten).

[smesjz]

Ik vind de keuze om statische content via een script te laten lopen ook raar, ik ken geen andere applicatie die dat doet vanuit security. Maar static.php heeft geen externe dependencies/libraries en is dus redelijk simpel en zal om die reden geen 80MB gebruiken.

Voor je compleet onrealistisch scenario dat 800 man om 9:00u gaat inloggen, wat is nu je huidig geheugen gebruik met 1.6?

[simon]

Statische content via een script laten lopen is helemaal niet zo raar. Je kan het zo uit je CDN ophalen met een permissie laag ervoor. Zo heb je een vergelijkbare constructie zelfs nodig als je met presigned URLs werkt met S3.

Het gene wat 't met PHP tov andere programmeertalen wat meer overhead geeft dat elk request een volle load is, waar je dit met bijv. Node, Python, etc makkelijker kan ondervangen omdat het proces door blijft draaien na de page load.

[smesjz]

Dat snap ik. Maar zoiets gebruik je voor je dynamische content of iets vanuit een CMS komt.

Niet om je public_html CSS / images / javascript op te halen van een standalone webmail app.

[armageddon_2k1]

Het is 2026, hoe kunnen we nog steeds dit soort issues hebben met web-apps?