SquirrelMail voegt line feed karakter toe

[SPT]

Het viel me zojuist op dat SquirrelMail bij het downloaden van bijlagen een line feed karakter toevoegt aan bestanden. Bij het verzenden van bijlagen gebeurt dat niet. De bijlagen staan wel goed op de server: in bijvoorbeeld OSX Mail en iOS Mail zijn de bijlagen wel goed. Het probleem is browser-onafhankelijk (getest op verschillende OSX en Windows webbrowsers). Het probleem is tevens onafhankelijk van het type bijlage. Omdat ik mijn webmail niet vaak gebruik heb ik geen idee wanneer het probleem is ontstaan; ik denk ergens in de eerste helft van dit jaar.

Software: Debian 11, Dovecot 2.3.13, php 7.4, SquirrelMail 1.4.23 SVN.

Mijn vermoeden is dat het probleem te maken heeft met incompatibiliteit tussen SquirrelMail en de recentere versies van php.

Benieuwd of iemand een idee heeft. It's driving me nuts .

[Hero of Time]

Gezien het laatste nieuws op hun site uit 2021 komt en spreekt over versie 1.4.23 en als download is 1.4.22 te krijgen, is het eerder aan te raden om een andere webmail client te gebruiken, zoals RoundCube. Iig eentje die nog wel onderhouden wordt. Squirrelmail beschouw ik door het lange gebrek aan news/releases als dood. Dit wil je echt niet meer draaien.

[SPT]

Ja, ik vrees het ook.

[silverball]

SPT schreef op zaterdag 24 augustus 2024 @ 18:16:


Mijn vermoeden is dat het probleem te maken heeft met incompatibiliteit tussen SquirrelMail en de recentere versies van php.

PHP 7.4 moet het echt doen i.c.m. SquirrelMail, aangezien men ook nog php 8 ondersteuning heeft gerealiseerd. De mailinglist zijn nog actief, je zou je vraag daar eens kunnen droppen.

[SPT]

Het probleem was dat aan het begin van mijn config.php script op de één of andere manier een 0x0a karakter vóór <?php terecht was gekomen. Bij php-scripten kunnen dat soort dingen soms veel problemen opleveren.

[syl765]

Ik zou toch eens overwegen om te kijken naar een meer onderhouden stukje software. Snappymail vind ik persoonlijk een fijne client. Maar ook roundcube of rainloop zijn fijne clients.

Php7.4 is ook eigenlijk niet meer iets dat je zou willen draaien.

[SPT]

syl765 schreef op woensdag 28 augustus 2024 @ 21:50:
Ik zou toch eens overwegen om te kijken naar een meer onderhouden stukje software. Snappymail vind ik persoonlijk een fijne client. Maar ook roundcube of rainloop zijn fijne clients.

Php7.4 is ook eigenlijk niet meer iets dat je zou willen draaien.

Ik draai altijd de LTS-versie van Debian (dat is nu 11). LTS-releases worden doorgaans juist beschouwd als het meest veilig en stabiel, omdat ze niet meer van nieuwe features worden voorzien, maar nog wel gepatcht worden met alle veiligheidsupdates. Dus de bestaande leks worden nog wel gedicht, terwijl er minder kans is dat nieuwe leks worden geïntroduceerd. Dat is dus ideaal voor een serveromgeving. Php-7.4 is de versie die bij Debian 11 in de repositories zit en deze wordt gepatcht door het Debian-LTS team.

Het updaten van de webmail-omgeving is een optie, hoewel ik waag te betwijfelen of het voor de veiligheid veel uitmaakt. Er is nog steeds een klein team dat squirrelmail onderhoudt (de sporadische en kleine updates worden meestal niet op de website aangekondigd, maar wel verwerkt in de daily snapshots). Er zijn al jaren geen grote veiligheidslekken meer in ontdekt, en het is natuurlijk ook een betrekkelijk simpel stukje software. In het verleden vereisten de lekken vaak een ingelogde gebruiker, of (bij hacks met geprepareerde mails) gebruikmaking van de (standaard uitgeschakelde) html modus. Ik denk ook niet dat vanuit de hacking-community nog heel veel aandacht uitgaat naar squirrelmail. Juist roundcube werd de afgelopen jaren getroffen door een aantal in het oog springende leks...

[Anoniem: 80910]

de andere versies worden ook beheerd door het debian team, alleen zitten ze in een aparte repository. daardoor gebruik ik nu de laatste versie (8.3) op debian met alle support van het debian team.
zolang niet upgraden is af te raden, omdat je dan meerdere sub/versies in een keer moet doen.

https://deb.sury.org/

[Hero of Time]

Anoniem: 80910 schreef op zondag 15 september 2024 @ 00:02:
de andere versies worden ook beheerd door het debian team, alleen zitten ze in een aparte repository. daardoor gebruik ik nu de laatste versie (8.3) op debian met alle support van het debian team.
zolang niet upgraden is af te raden, omdat je dan meerdere sub/versies in een keer moet doen.

https://deb.sury.org/

Die repo is dus NIET van het Debian Team en wordt ook niet door Debian beheerd! De enige relatie tussen die repo en Debian is dat Ondřej Surý de package maintainer van PHP is bij Debian en buiten de Debian package policy zelf ook het een en ander aanbiedt.

Het is nog steeds een 3rd party repo met alle disclaimers e.d. die er bij horen.

[Anoniem: 80910]

citaat van de website:

I am a Debian Developer since year 2000, and I have been packaging PHP for Debian since PHP 5. That means the official packages in Debian and Ubuntu are either my work or they are based on my work. The PHP packages in my Ubuntu PPA and Debian DPA matches the official packages in Debian. Basically I am saying that you can’t get any closer than that.

[Hero of Time]

Dat zeg ik ook. Die repo is niet van het Debian Team, want dat zijn veel meer mensen. Het is van 1 package maintainer die buiten de officiële Debian repo's zelf iets aanbied. Verandert het feit niet dat je met een 3rd party repo te maken hebt en alle consequenties daarvan moet accepteren.


Overigens, het gebruiken van een andere php versie zal voor de TS niks oplossen als het probleem in de webmail client zelf zit. Iets wat al is bevestigd, Apple Mail doet het wel goed. Het probleem zit echt in Squirrelmail.

[ Voor 28% gewijzigd door Hero of Time op 15-09-2024 11:17 ]

[mrmrmr]

Als je third party repositories gebruikt, met name deze voor PHP, dat krijg je vroeg of laat een probleem met packages die niet goed worden bijgehouden of weduwe/wees worden en onbeheerd achterblijven. Officiele packages hebben dat probleem niet (althans, dat hoort niet). Debian was vrij laat met de ondersteuning van PHP v7.4 en v8, dus ik snap wel waarom mensen de sury.org PHP repository gingen gebruiken. Maar dat komt dus niet zonder risico. Volledig opruimen van zo'n third party installatie me dependencies is niet makkelijk.