Ein "Downgrade" ist problemlos möglich, sofern eben keine Ressourcen (E-Mail, Webspace) auf externen Servern verwaltet werden - die wären danach nicht mehr verwaltbar.
Wie taenzerme schon beschrieben hat: Lizenzkey löschen, neue Lizenz aktivieren, LiveConfig neu starten - fertig.
Ist das zufällig ein Ubuntu 24? 
Da heißen Benutzer+Gruppe bei neuen Setups inzwischen "debian-spamd" statt "spamd".
Bearbeiten Sie testweise also mal die Datei /lib/systemd/system/lcsam.service und ersetzen -g spamd durch -g debian-spamd
Anschließend systemctl daemon-reload und dann systemctl start lcsam ausführen.
Interessant. Haben Sie den Server zufällig mal migriert gehabt? Der Dienst "lcsam" ist im LiveConfig-Paket enthalten und wird automatisch eingerichtet, wenn SpamAssassin in der Postfix-Verwaltung aktiviert wird. Er sollte also eigentlich gar nicht verloren gehen...
Mit folgenden Befehlen können Sie den lcsam-Service wieder einrichten:
cp -av /usr/lib/liveconfig/lcsam.service /lib/systemd/system
systemctl enable lcsam.service
systemctl daemon-reload
Was gibt denn "systemctl status lcsam" ?
Ggf. mit "systemctl start lcsam" starten.
Die Fehlermeldung sagt nicht, dass der Dienst nicht existiert, sondern dass der Unix-Socket vom lcsam nicht existiert - kann also sein dass der Dienst lediglich nicht läuft.
Kurze Antwort: ja, ist bereits in der Pipeline. 
Lange Antwort: ist leider nicht gaaanz so einfach.
smtpd_sender_login_maps prüft nur, ob der Envelope-From für den einliefernden SMTP-Benutzer "erlaubt" ist. OpenDKIM signiert aber fröhlich alles was er im "From:"-Header sieht (das ist tatsächlich im DKIM-Standard so vorgeschrieben), und das kann durchaus etwas anderes sein als im Envelope-From. Hierfür gibt's natürlich auch eine Lösung: den MilterFrom. Der steht leider nicht als fertiges Paket für die einzelnen Distributionen bereit, da müssen wir uns als auch noch drum kümmern (so wie kürzlich übrigens im PostSRSd 2.x, aber dazu bald mehr an anderer Stelle).
Zudem gibt es noch die Herausforderung, dass bei einigen Setups mit Absenderadressen versendet wird, die nicht zu einem einzelnen Postfach bzw. Alias gehören, sondern "nur" als Weiterleitung/Verteiler genutzt werden (z.B. Newsletter, Shop-Bestätigungen, etc.). Für solche Fälle muss es also eine Möglichkeit geben, die erlaubten From:-Adressen für Kunden verwaltbar zu machen (natürlich nur für "eigene" Domains).
Nach unseren bisherigen Tests sieht es zudem so aus, als ob diese "strenge" Absenderprüfung nur global für ein gesamtes System aktiviert werden kann, und nicht z.B. erstmal nur pro Domain. Hier steht die Idee im Raum, den MilterFrom so zu erweitern, dass er auf die selbe Map wie smtpd_sender_login_maps zugreift.
Wir gehen davon aus, etwa Mitte/Ende Januar ein erstes Ergebnis präsentieren zu können.
Und weil die Frage woanders auch schon aufkam: ja, dieses Feature wird auch für LiveConfig 2.x verfügbar sein, nicht nur für v3.
Wurde eben in die Repositories mit aufgenommen.
(wir bauen inzwischen 11 verschiedene PHP-Versionen auf 6 Distributionen und teils 2 Architekturen, da ist das leider "durchgerutscht")
Ja, das hängt mit den Berechtigungen zusammen; derzeit muss zwingend Webspace zugewiesen sein, um Domains auch für E-Mail konfigurieren zu können.
Sie können den Apache-Service auf dem Server aber deaktivieren (systemctl disable apache2).
Erhalte self signed Zertifikatsfehler für demo-v3.
Ja, hier haben wir in der Demo noch kein LE-Zertifikat eingerichtet. Wie bereits angekündigt kann LC3 künftig "direkt" mit einem automatisierten Zertifikat (z.B. Let's Encrypt) betrieben werden, sofern lokal ein Webserver aktiviert ist über den die Domainvalidierung erfolgen kann. Die API hierfür ist schon fertig, nur die Maske noch nicht ganz - kommt aber auch noch in den nächsten Tagen.
Aus welchem Grund denn?
LiveConfig 3 ist im "Feinschliff", und wird inzwischen so paketiert, dass es ein "drop-in replacement" zu LiveConfig 2.x darstellt.
Im Idealfall* kann man also zwischen dem Paket "liveconfig" und "liveconfig3" umherschalten.
Debian erlaubt es nicht, dass mehrere Pakete die selbe Datei (z.B. /etc/liveconfig/liveconfig.conf) verwalten - hierfür Workarounds zu entwickeln wäre zwar technisch machbar, würde auf Dauer aber keinen Sinn ergeben (daher sparen wir uns das gleich uns nutzen die Zeit für wichtigere Dinge).
(*) zum "Idealfall": die Datenbanken von v2.x und 3.x sind und bleiben zueinander kompatibel, so dass es - wie versprochen - keine "Migration" geben wird. Einfach das neuere Paket installieren, fertig. Notfalls auf das ältere Paket downgraden, auch kein Problem.
Aaaaber: wir haben derzeit noch ein Problem mit der DNSSEC-Konfiguration: bei BIND haben sich diesbezüglich einige Sachen geändert. Wir versuchen derzeit noch, diese Anpassungen in v2.x zu "backporten", so dass auch hier ein "Downgrade" jederzeit nochmal möglich wäre.
Die Pakete sind aktualisiert (betraf PHP 8.3, 8.2, 8.1 und 7.2 unter Ubuntu 24).
Keine Sorge - die URL hat sich nur geändert, da LC3 nicht mehr neben LC2 auf dem selben Server betrieben werden kann:
PHP 8.4 enthält Sodium. Bei allen anderen Paketen holen wir das nach, Update erfolgt voraussichtlich morgen.
Ab Version 2.17 gibt es eine neue Funktion in diesem Kontext, Details in Kürze.
Es ist derzeit nicht geplant, pro Postfach, Account oder Kunde die Liste der Weiterleitungs-Sperrliste bearbeitbar zu machen.
Es wird dafür eine andere Funktion im Zusammenhang mit Weiterleitungen geben (auch in 2.17 noch). Details in Kürze...
Wir haben uns übrigens kürzlich - "aus Gründen" - erneut mit dem Thema SRS beschäftigt. Fazit: das ist noch kaputter als je zuvor. Zudem gibt es keine gebrauchsfertige SRS-Software, welche wirklich alle Aspekte bei der Weiterleitung von E-Mails berücksichtigt.
Das eine oder andere Panel setzt auf PostSRS. An sich eine ordentliche Software (auch wenn die .deb-Pakete derzeit keinen Maintainer haben), aber da wird für den Rewrite leider der Hostname (!) verwendet und nicht der Name der jeweiligen Kundendomain. Für's Hosting also ein absolutes No-Go. Zudem werden in der Standardkonfiguration alle Mails umgeschrieben, also auch lokal zugestellte Mails.
Und als SRS entwickelt wurde, spielte DMARC noch keine Rolle. DMARC und SRS schießen sich leider gegenseitig ins Knie. Für ein sauberes SRS müssten idealderweise abhängig vom DMARC-Record des Absenders (!) und des DKIM-Signaturumfangs die DKIM-Header vollständig entfernt werden, und dann durch ggf eine eigene DKIM-Signatur ersetzt werden. Und weil das alles noch nicht kaputt genug ist, wurde ARC als Krücken-Krücke dazu gebaut.
Fazit: Weiterleitungen sind immer problematisch.
Meine Glaskugel sagt mir dazu nicht viel. Das kann September 2024 heißen, aber auch Dezember 2025.
Konkret kann man sich das so vorstellen: wir möchten keine Software releasen, bei der wissentlich noch große (wichtige) Funktionen fehlen. Das sorgt nur für Frust bei den Anwendern und erhöht den Druck, den Funktionsumfang in kürzester Zeit abzuschließen (was Software oftmals nicht gut tut).
Wir befinden uns aber nun durchaus im Endspurt. Die Online-Demo wurde eben wieder aktualisiert, und in der API-Doku wurde ein Fehler behoben so dass man diese nun auch vom Browser aus direkt testen kann.
Aktuell werden die Arbeiten am File-Browser abgeschlossen, zudem stehen noch letzte Anpassungen am Mail-Limit (lcpolicy) sowie im Restore von Backups an. Wir beabsichtigen, noch im September (2024 die LC3-Pakete "öffentlich" bereitzustellen, womit dann jeder der möchte schonmal testen kann.
Für die einzelnen Dienste (SMTP, IMAP, FTP) können schon immer auch Let's-Encrypt-Zertifikate "ohne Bastelarbeiten" verwendet werden.
Neu ist, dass auch die LiveConfig-Oberfläche direkt mit einem solchen Zertifikat versehen werden kann (unter bestimmten Bedingungen, u.a. natürlich dass die Domainvalidierung möglich ist)
Wir haben vorhin die v3-Demo auf den aktuellen Stand gebracht, sowie die Info-Seite aktualisiert.
Der HTTP-Stack ist nun abgehärtet, zudem wurden etliche Funktionen abgeschlossen.
Aktuell werden noch wichtige GUI-Features abgeschlossen (u.a. Restore/Verwaltung von Backups, Verwaltung von TLS-Zertifikaten). Alle "low-level"-Funktionen sind soweit fertig. Geht also gut voran!
Mit LiveConfig hat das nichts zu tun, daher kann LiveConfig da auch nichts machen.
Das Löschen von Mails vom Server ist eine rein clientseitige Sache - sowohl bei POP3 als auch bei IMAP.
Die erste Frage wäre also, ob der Kunde POP3 oder IMAP für den Zugriff nutzt. Bei IMAP werden Mails normalerweise nicht vom Server gelöscht (würde nur dann Sinn machen, wenn man die clientseitig in einen anderen - lokalen! - Ordner verschiebt). Bei POP3 lässt sich das Lösch-Verhalten in den meisten Clients einstellen. Auch da ist das Löschen aber immer ein expliziter Befehl des Clients, also nichts was man serverseitig beeinflussen könnte.
Guten Morgen,
der aktuelle Stand ist, dass wir lediglich noch nicht alle PHP-Erweiterungen fertig für Ubuntu 24 angepasst haben.
Das dauert etwas länger als sonst, weil wir die Build-Umgebung sukzessive von Jenkins auf Gitlab CI umstellen, und dabei ab sofort alle Pakete auch gleichzeitig für ARM64 bauen.
Anders gesagt: für Ubuntu 24 steht (auch auf ARM64) bereits PHP 5.6 (ja, wirklich ) bis 8.3 fertig bereit, ImageMagick etc. sollte in den nächsten Tagen schrittweise dazu kommen. AVIF müsste da übrigens überall unterstützt sein (sofern die jeweilige PHP-Version das unterstützt).
LiveConfig an sich sollte auf Ubuntu 24 komplett laufen - unsere manuellen Tests waren erfolgreich, in den automatischen Testlauf wird das ab Version 2.17 aufgenommen.
Viele Grüße
-Klaus Keppler
