Beiträge von kk

Die PHP-Pakete für Debian 10 und Ubuntu 18 wurden eben aktualisiert, da dort die php.ini-Einstellung "sendmail_path" fehlerhaft war. Weitere Änderungen gab es nicht.

Viele Grüße

-Klaus Keppler

Zitat von BMK-Media

Das war mit dem Admin Account, beim Login Sprache auf Standard (also Deutsch)

Welche LiveConfig-Version genau nutzen Sie denn?
Handelte es sich um ein Postfach eines eigenen Vertrags ("Mein Hosting") oder eines Kunden?

Zitat

OK, wollte eigentlich auch SpamAssassin pro Postfach lernen lassen, aber das geht dann ja nicht, weil es dort die Datenbank nicht gibt.

Der Bayes-Filter wird (bei heutigem Spam) massiv überbewertet - den Aufwand kann man sich eigentlich komplett sparen. Lieber die bestehenden Filter tunen, und SpamAssassin bzw. ClamAV mit weiteren Regelwerken erweitern.

Zitat

Noch eine Frage, ist es möglich wieder die Benutzerdefinierte Header reinzusetzen, wie bei SpamAssassin, denn diese werden nicht angenommen.

Code

add_header all maximal_Score _REQD_
add_header all Score _SCORE_
add_header all Report _REPORT

Nein, das geht nicht ohne weiteres, da SpamAssassin in diesem Setup die E-Mail nicht modifizieren kann. Wenn lcsam mit der Option "-r" gestartet wird, fügt er den "X-Spam-Report:"-Header hinzu.
Um das mit systemd einzurichten, einfach den Befehl "systemctl edit lcsam.service" ausführen und folgenden Override anlegen:

[Service]
ExecStart=
ExecStart=/usr/lib/liveconfig/lcsam -g spamd -U postfix -r

Danach lcsam neu starten (systemctl restart lcsam.service).

Ich glaube das sind die mit dem 5 Buchstaben.
Wir haben das SNI-Thema für Postfix durchaus im Auge.
Aus rein technischer Sicht sehe ich keinen Mehrwert dadurch (aus dem selben Grund wurde dieses Feature ja auch jahrelang nicht implementiert...). Ich bin immer an Use-Cases interessiert, aber "Leute die es nicht schaffen ihre Postfächer richtig einzurichten" schaffen das dann mit einem eigenen Mail-Domainnamen auch nicht besser (die Energie für solche Kunden sollte man lieber in AutoConfigure/AutoDiscover investieren). Zudem unterstützen auch noch nicht alle Mail-Clients SNI entsprechend, was also letztendlich zu noch mehr Problemen führen kann (z.B. bei alten Outlook- oder Android-Versionen).

Aber zurück zum Thema: Debian 10 kommt mit Postfix 3.4 und würde das prinzipiell unterstützen.
Das größte Problem sehe ich in den SSL-Zertifikaten selbst. Da die meisten Anwender vermutlich gerne kostenfreie Zertifikate dafür nutzen möchten, müssen die Domains ("mail.example.org") automatisiert validiert werden. In Multiserver-Konfigurationen mit separatem Mailserver wird das durchaus kompliziert, da dort nicht zwangweise ein Webserver (für HTTP-Validierung) läuft.
Eine Idee hier ist, dass SNI angeboten wird, wenn alle Bedingungen für eine "einfache" HTTP-Validierung erfüllt sind (also u.a. dass auf dem Mailserver irgendein von LiveConfig gemanagter Webserver läuft).

Den Vorteil, dass der Kunde dann verschlüsselt mit "mail.<kundendomain>" arbeiten kann, erkauft man aber mit dem Nachteil, dass noch mehr SSL-Zertifikate verwaltet (validiert/aktualisiert) werden müssen - die Gesamtkomplexität und somit die Wahrscheinlichkeit für Probleme wird also meiner Einschätzung nach eher größer als kleiner.
Auch DANE/TLSA lässt sich mit einer "zentralen" Mail-Subdomain wesentlich einfacher handhaben...

Zitat von BMK-Media

geändert, da stand nur:

Code

SPAMDOPTIONS="-d -c -m5 --socketpath=/var/run/spamd.sock"

ist nun aber geändert und funktioniert.

Dann wurde diese Datei vermutlich nachträglich noch mal neu geschrieben (z.B. durch Neuinstallation von SpamAssassin)

Zitat

In /var/log/maillog steht nun folgendes

Code

Jul  8 13:51:08 server spamd[29231]: spamd: using default config for web1_1: /var/lib/spamassassin/web1_1//user_prefs

doch im Ordner /var/lib/spamassassin/ existieren nur diese Ordner, wahrscheinlich weil es vorher nicht lief?

Code

51265073 drwxr-xr-x 5 root root 4096  8. Jul 05:48 3.004000
1812258963 drwxr-xr-x 3 root root   18  8. Jul 06:41 compiled
1795184831 drwx------ 2 root root   79 28. Jun 01:04 sa-update-keys

Das passt schon so. Die user_prefs-Verzeichnisse werden erst ab v2.8 erzeugt, falls ein Postfach individuelle Blacklist/Whitelist-Einträge hat. Ansonsten werden keine user_prefs benötigt.

Zitat

Und mir ist noch etwas aufgefallen, in der /etc/postfix/spamassassin stand vorher z.B. immer

Code

NAME@DOMAIN.de      1 3 5 1 web1_1 ***SPAM-Verdacht***

bei den geänderten steht nun aber

Code

ANDERER@DOMAIN.de    1 3 5 1 web1_1 ***Suspected SPAM***

Der Text für den Header ("*** SPAM-Verdacht ***") wird mit der Sprache lokalisiert, die für den Benutzer eingestellt ist, der das Postfach bearbeitet.
Prüfen Sie daher bitte, mit welchem Account Sie das Postfach bearbeitet hatten und welche Sprache ggf. für diesen Benutzer eingestellt ist.

Zitat

get_spamd_fd: can't connect to '/var/run/spamd.sock': No such file or directory

Normalerweise sollte diese Datei aber existieren wenn SpamAssassin läuft (eben unter CentOS 7 getestet).
Haben Sie SpamAssassin evtl. aus einem anderen Repository installiert?

In /etc/sysconfig/spamassassin sollte Folgendes stehen:

SPAMDOPTIONS="-d -m 5 -H --socketpath=/var/run/spamd.sock --socketowner=root --socketgroup=spamd --socketmode=0660 -x --virtual-config-dir=/var/lib/spamassassin/%u/ -u spamd"

Wenn z.B. SpamAssassin nach der Aktivierung im LiveConfig nochmal komplett entfernt (erased/gepurged) wurde und dann wieder installiert, dann könnten da wieder die "falschen" Standardwerte drin stehen.

Zum anderen Problem (Postfachnamen stehen nicht in /etc/postfix/spamassassin): wenn Sie SpamAssassin für das betroffene Postfach mal deaktivieren, sollte der Eintrag wieder entfernt werden, wenn Sie es wieder aktivieren, sollte er wieder hinzugefügt werden.
Falls das nicht passiert, prüfen Sie bitte was in /var/log/liveconfig/liveconfig.log protokolliert wird, während die Postfacheinstellungen gespeichert werden.

Zitat

syslog: lcsam_lookup(empfänger@interne_domain.de): not found

Taucht die E-Mail-Adresse des Empfängers denn in der Datei /etc/postfix/spamassassin auf?

Die jeweilige Postfachadresse sollte da eingetragen werden, sobald man im LiveConfig in den Postfach-Einstellungen den Spamfilter aktiviert.

Danke für die Info. Nein, das war nicht beabsichtigt - das liegt am besch*****en PHP-Build-System. Wir werden das in den nächsten 1-2 Tagen korrigieren.
Als Workaround können Sie den sendmail_path vorübergehend in einer globalen php.ini festlegen (z.B. /opt/php-7.2/etc/conf.d/sendmail.ini)

Viele Grüße

-Klaus Keppler

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.20 und 7.3.7 aktualisiert.
Außerdem stehen die PHP-Pakete in den Version 5.6, 7.0, 7.1, 7.2 und 7.3 ab sofort auch für Debian 10 ("Buster") bereit.

Viele Grüße

-Klaus Keppler

In unserem Test-Repository sind ab sofort die PHP-Version 5.6, 7.0, 7.1, 7.2 und 7.3 für Debian Buster enthalten (inklusive der üblichen Extensions wie bislang auch für Debian Stretch etc).

Derzeit planen wir nicht, auch noch ältere PHP-Versionen bereitzustellen (PHP 5.6 und 7.0 sind ja auch schon End-of-Life). Der Aufwand um PHP 5.6 unter Debian 10 zu compilieren war schon groß genug...

Zitat von aci

Ich habe weiterhin ein Problem, dass einige Zertifikate nicht verlängert werden können.

Fehlermeldung:

obrigado.de 2019-07-05 15:17:45 http-01 invalid
Invalid response from https://www.xxxx.de/login [xx.xx.xx.xx]: "<!DOCTYPE html>\n<html class="ng-csp" data-placeholder-focus="false" lang="en" >\n\t<head data-requesttoken="CAUnIUMdHhk5emMDeiMwAF"

Betrifft das wirklich mehrere Zertifikate oder nur dieses eine? Wann exakt wurde dieser Fehler protokolliert? (/var/log/liveconfig/liveconfig.log)

Vom Timing her könnte es sein, dass das LiveConfig-Update die Verlängerung der SSL/TLS-Zertifikate angestoßen hatte *bevor* die vHosts im Apache dafür passend konfiguriert waren (also vor dem Apache-Reload). Kann ich mir zwar nur schwer vorstellen, aber das wäre eine Erklärung. Ggf schicken Sie uns einfach die /var/log/liveconfig/liveconfig.log an support@liveconfig.com und wir schauen uns das mal an.

Zitat von Mercator1972

Bei der Erstellung eines LE-Zertifikates für eine Domain, die durch externe Nameserver verwaltet wird, wird gegen alle IPs der IP-Gruppe geprüft. Dies führt hier zu folgender Fehlermeldung
DNS error: IP(s) missing in DNS: 1.2.3.4,2.3.4.5,usw (Die Domain zeigt nur auf eine einzige IP aus der Gruppe). Die Ausstellung des LE-Zertifikates wird dann scheinbar nicht angestossen, sondern hängt mit pending.

Danke für den Hinweis, das haben wir nun in r5503 korrigiert. Technisch betrachtet ist es in Ordnung, wenn der DNS weniger IPs für eine Domain meldet als in der IP-Gruppe konfiguriert sind (kann z.B. für Failover- oder Loadbalancer-Konfigurationen wichtig sein).

Das Update steht spätestens morgen im Test-Repository bereit.

Die Preview wurde eben auf v2.8.0-r5501 aktualisiert - damit sollten alle o.g. Fehler behoben sein.

Danke für den Hinweis, die Fehler wurden eben behoben.
Eine aktualisierte Preview-Version ist dann in ca. 30 Minuten im Repository.

Sie können die Daten vorübergehend direkt in der LiveConfig-Datenbank anpassen (Tabelle EXTNAMESERVERS, Spalte ENS_AUTH_IPS). In der Oberfläche war das bislang auf 200 Zeichen begrenzt, ab v2.8.0-r5495 sind nun bis zu 1024 Zeichen möglich.

Viele Grüße

-Klaus Keppler

Löschen Sie die Datei /var/cache/liveconfig/downloads/roundcubemail-1.3.9-complete.tar.gz bitte und versuchen danach erneut eine Installation.
Ansonsten:
- ist auf der Festplatte genügend freier Platz vorhanden? (auch Webspace-Quota ausreichend?)
- funktioniert die Installation anderer Anwendungen? (z.B. WordPress)

Viele Grüße

-Klaus Keppler

Die Preview von v2.8.0 wurde eben auf r5493 aktualisiert.
Fast alle Fehler im Zusammenhang mit der neuen SSL-Verwaltung sind damit behoben, auch die automatische Verlängerung von Zertifikaten läuft damit wieder.

Das nächste Update ist für kommenden Dienstag (02.07.) geplant - da fokussieren wir uns auf die noch ausstehenden Änderungen in der Oberfläche.

Viele Grüße

-Klaus Keppler

Ich verstehe die Frage(n) nicht wirklich.

Die DNS-Blacklist im Postfix greift (wie schon von bfal beschrieben) unabhängig von allen Empfängeradressen. Postfix schaut ob die IP-Adresse des einliefernden Mailservers geblacklistet ist und lehnt die Verbindung dann (aus guten Gründen) möglichst früh ab.

"Auslagern von Postfix" usw. verstehe ich nicht - es ist aber immer problematisch, wenn eine Mail erst mal angenommen und dann erst später abgelehnt wird (erzeugt Bounces -> neues Problem...).

Wie Sie das auf Ihrem Server umsetzen ist also Ihre Sache. Im einfachsten Fall deaktivieren die DNS-Blacklists im LiveConfig und konfigurieren die Blacklist-Bepunktung durch SpamAssassin etwas höher.

Die DNS-Blacklist greift bereits beim Connect an den Postfix; theoretisch kennt er zu dem Zeitpunkt noch nicht einmal den Empfänger.

Es gibt zwei Möglichkeiten:

• die DNS-Blacklist im LiveConfig deaktivieren; SpamAssassin selbst nutzt auch DNS-Blacklists - ggf. muss man hierfür die Punktzahlen aber etwas anpassen.
• eine DNS-Whitelist nutzen (die hat Vorrang gegenüber den DNS-Blacklists), z.B. dnswl.org (die ist aber kostenpflichtig, die freie Nutzung ist daher gerade aus großen Colo-Netzen heraus nicht direkt möglich)

Natürlich wird es für lcbackup auch eine Dokumentation geben... eine man-Page und einen Abschnitt im Handbuch.

Zitat von Mogwais

Wie arbeiten diese Einträge nun? Wird das am Greylisting/Spamassassin und Co vorbei entschieden oder würde eine Whitelist Email trotzdem abgewiesen werden wenn sie nen zu hohen Score hat?

LiveConfig schreibt die angegebenen Adressen in entsprechende whitelist_from bzw. blacklist_from-Anweisungen einer postfachspezifischen SpamAssassin-Konfiguration. Auf das Greylisting hat das also leider keinen Einfluss (das ist mit Postgrey auch nicht ganz trivial). Ein Whitelist-Absender wird unabhängig vom eventuellen Score aber vom SpamAssassin durchgelassen.

Aufgrund der vielen Anfragen werden wir uns demnächst mit rspamd beschäftigen - damit sollten noch flexiblere Regeln möglich sein.