Beiträge von kk

Sehr merkwürdig. So sieht es aus, wenn eine Mail abgelehnt wird:

Aug  2 18:34:51 mx postfix/smtpd[13493]: Anonymous TLS connection established from mail.keppler-it.de[88.198.223.3]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug  2 18:34:51 mx postfix/smtpd[13493]: 6F4A01802115D: client=mail.keppler-it.de[88.198.223.3]
Aug  2 18:34:51 mx postfix/cleanup[13496]: 6F4A01802115D: message-id=<b2015a26-4dbb-c642-10f4-9fdf2b15c064@keppler-it.de>
Aug  2 18:34:51 mx spamd[1079]: spamd: got connection over /var/run/spamd.sock
Aug  2 18:34:51 mx spamd[1079]: spamd: using default config for web345_7: /var/lib/spamassassin/web345_7/user_prefs
Aug  2 18:34:51 mx spamd[1079]: spamd: checking message <b2015a26-4dbb-c642-10f4-9fdf2b15c064@keppler-it.de> for web345_7:999
Aug  2 18:34:59 mx spamd[1079]: spamd: identified spam (99.3/5.0) for web345_7:999 in 8.1 seconds, 3129 bytes.
Aug  2 18:34:59 mx spamd[1079]: spamd: result: Y 99 - RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,URIBL_BLOCKED,USER_IN_BLACKLIST scantime=8.1,size=3129,user=web345_7,uid=999,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=/var/run/spamd.sock,mid=<b2015a26-4dbb-c642-10f4-9fdf2b15c064@keppler-it.de>,autolearn=no autolearn_force=no
Aug  2 18:34:59 mx postfix/cleanup[13496]: 6F4A01802115D: milter-reject: END-OF-MESSAGE from mail.keppler-it.de[88.198.223.3]: 5.7.1 Your message was rejected because it appears to be spam; from=<kk@keppler-it.de> to=<test@dnssec-demo.de> proto=ESMTP helo=<mail.keppler-it.de>
Aug  2 18:34:59 mx postfix/smtpd[13493]: disconnect from mail.keppler-it.de[88.198.223.3]

Welche Distribution genau nutzen Sie?
Wem gehört die Datei /var/lib/spamassassin/<Vertrag>_<Postfach>/user_prefs ? (sollte spamd:root gehören und mode=0640 haben)

Viele Grüße

-Klaus Keppler

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.21 und 7.3.8 aktualisiert.
Zudem enthalten diese Pakete nun die "argon2"-Bibliothek und unterstützen somit Argon2-Hashes (Typo3-Kennern wird das was sagen...

Außerdem haben wir ab sofort PHP 7.4.0 (Beta 1) im Sortiment. Von einem produktiven Einsatz wird noch abgeraten, aber erste Tests kann man damit schon mal machen.

Viele Grüße

-Klaus Keppler

Was wird denn exakt in /var/log/mail.log protokolliert, während eine E-Mail empfangen wird die eigentlich abgelehnt werden sollte?

Und: der Absender ist aber schon extern, oder? Intern zugestellte Mails laufen üblicherweise nicht durch den Spamfilter.

Zitat von bravesurfer

Ich habe heute mal die aktuelle Preview auf einem Testsystem (Debian GNU/Linux 9.9 (stretch) installiert. Die Blacklist-Funktion für Kunden scheint hierbei jedoch ohne Funktion. Jedenfalls werden bei mir Mails vonin der Blacklist eingetragenen Absendern trotzdem zugestellt. Kann das jemand bestätigen?

Ich kann das nicht bestätigen - sollte eigentlich klappen.
Suchen Sie bitte mal mit "grep postfach@example.org /etc/dovecot/passwd" nach dem betroffenen Postfach (Mailadresse dabei natürlich anpassen). Die Zeile enthält so was wie "userdb_mail=maildir:/var/mail/web4191/1/" - daraus lässt sich der Name für das SpamAssassin-Verzeichnis ableiten - nämlich /var/lib/spamassassin/web4191_1/
Prüfen Sie ob dieses Verzeichnis existiert und ob darin eine Datei namens "user_prefs" mit den gewünschten Blacklist-Einstellungen existiert.

Wenn ja, dann deutet das darauf hin, dass SpamAssassin und/oder lcsam nicht laufen.

Prinzipiell könnten Sie den schon ersetzen, allerdings müssten Sie danach noch mal alle FTP-Passwörter neu setzen (damit die jeweiligen Konfigurationsdateien für vsftpd geschrieben werden).

Gibt es einen speziellen Grund, warum Sie von ProFTPD auf vsftpd wechseln möchten?

Viele Grüße

-Klaus Keppler

Das Problem ist, dass Mailaccounts nicht einfach zwischen Servern verschoben werden können - schließlich müssen ja alle Postfachdaten (/var/mail/<Vertrag>/<Postfach>/) und alle Passwörter (/etc/dovecot/passwd) mit übernommen werden.

Um einen "manuellen" Umzug zu besprechen, wenden Sie sich bitte an support@liveconfig.com - am besten mit der Info um wie viele Verträge und Postfächer es ungefähr geht.

Viele Grüße

-Klaus Keppler

Ich verstehe das Problem nicht.
Separate Zertifkate sind sicherer uind flexibler als ein Wildcard-Zertifikate. Die Ausstellung und Verlängerung erfolgt vollautomatisch - also wo liegt der Vorteil?

LiveConfig v2.8 enthält ein komplett neues Let's-Encrypt-Modul und nutzt damit die ACMEv2-API, womit prinzipiell auch Wildcard-Zertifikate möglich wären. Allerdings ist für die Domain-Validierung bei Wildcards ein DNS-Eintrag erfordertlich, was bedeutet dass die Domain dann auch durch LiveConfig im DNS verwaltet werden muss. Bis das soweit ist wird es noch etwas dauern.

Zitat von alex007

Wann wird der Plan den umgesetzt, habe nämlich auch das gleiche Problem??

Ab LiveConfig v2.8 (derzeit als Preview verfügbar) können Sie eine Konfigurationsdatei namens /var/www/<Vertrag>/conf/fpm.conf anlegen und damit die Werte "überschreiben", die letztendlich in der FPM-Pool-Konfiguration landen. Die Syntax für die fpm.conf ist quasi identisch mit der php.ini-Syntax (also "key = value").

/etc/init.d/lcsam start

Ein schlampig oder gar nicht konfiguriertes Init-System wird aber garantiert noch viel "Freude" bereiten...

Hat nichts mit LiveConfig zu tun, sondern mit dem Server insgesamt. Führen Sie "systemctl status apache2" aus - vermutlich bringt das die selbe Fehlermeldung.
Anhand der spärlichen Fehlermeldungen kann man unmöglich sagen, was die Ursache ist. Eventuell läuft schlicht systemd nicht (z.B. wenn Upstart eingesetzt wird).

Da uns einige Anfragen hierzu erreicht haben: in ProFTPD steckt offenbar eine Sicherheitslücke (CVE-2019-12815) im Modul mod_copy.

LiveConfig ändert nichts an der Modul-Konfiguration von ProFTPD. Wir haben die Konfiguration unter Debian 8/9/10 getestet - dort ist mod_copy standardmäßig nicht aktiviert. Sie können mit folgendem Befehl testen, welche Module geladen werden:

proftpd -d 7 -t 2>&1 | grep loading

Sollten Sie mod_copy aktiviert haben, können Sie die entsprechende LoadModule-Anweisung einfach aus der ProFTPD-Konfigurations auskommentieren und ProFTPD neu starten.

Weitere Distributionen testen wir bei Gelegenheit auch noch durch.

Viele Grüße

-Klaus Keppler

Für PHP 7.2 haben wir das inzwischen in unser Buildsystem aufgenommen, PHP 7.3 folgt nächste Woche.
Beim nächsten PHP-Update wird Argon2 dann unterstützt (voraussichtlich in ca. 2-3 Wochen).

Auch unter Debian 8 und Ubuntu 16 (die keine libargon2 mitbringen) wird PHP Argon2 unterstützen (da haben wir die notwendige Bibliothek statisch in die Argon2-Extension gelinkt).

AutoDiscover/AutoConfigure hat mit SSL relativ wenig zu tun. Um genau zu sein, muss sogar zwingend ausdrücklich kein SSL auf der Autodiscover-Domain laufen (sprich: HTTPS/Port443 darf dort nicht geöffnet sein).
Das grobe Vorgehen für AutoDiscover ist im Wiki beschrieben: https://www.liveconfig.com/wiki/de/autodiscover
Das ganze ist aber aufgrund der Eigenheiten (insbesondere der Microsoft-Produkte) ziemlich anspruchsvoll und lohnt sich für einzelne Domains nicht wirklich.
Zwingende Voraussetzung für AutoDiscover ist ohnehin, dass Sie eine separate IP-Adresse zur Verfügung haben, auf der nur Port 80 geöffnet ist (für die Autodiscover-Weiterleitung).

Zitat von antondollmaier

8.000 SSL-Zertifikate unter der selben Subdomain funktionieren nicht - da greifen die Rate-Limits von Let's Encrypt.

... außer man ist Sponsor bei Let's Encrypt.

Zitat von lebenszeit

Wenn sich stable wegen Backup und ein paar "Kleinigkeiten" in GUI verzögert bitte ich um Release gefolgt von baldigem Update.

Wir haben aktuell das Problem, dass ein Kunde (wohl unbeabsichtigt) eine sehr frühe Preview-Version produktiv eingespielt hat und dem nun tausende Let's-Encrypt-Zertifikate um die Ohren geflogen sind.
(eine gefährliche Mischung aus "selber in die Datenbank eingegriffen" und "nö, ich sehe im Log nichts auffälliges").
(der Eingriff in die Datenbank hatte >50.000 SSL-Aufträge generiert, der Account ist in's Rate-Limit gerasselt, und wir arbeiten mit dem Kunden derzeit an einer Lösung)

Ja, das war ganz klar die Schuld des betroffenen Kunden, aber wir möchten den nunmal auch nicht im Regen stehen lassen. Zudem "nutzen" wir diese recht extremen SSL-Probleme nun dafür, LiveConfig in solchen Fällen etwas robuster zu machen (Beispiel: wenn DNS-TTL auf 1sec steht, wiederholt LiveConfig tatsächlich alle 1sec den DNS-Check vor einem SSL-Auftrag - das wurde nun aus konkretem Anlass auf eine Mindestwartezeit von 5min geändert).

Lange Rede, kurzer Sinn: wir feilen aktuell noch am letzten SSL-Dialog (SSL für bestehende Subdomains aktivieren), dann gibt's ein Update der Preview welches wir dann auf "unseren" ersten Produktivservern einspielen um in den Praxistest zu gehen. Backup-Integration läuft parallel dazu weiter, ist aber kein Showstopper mehr.

Zitat von Maxx

Fehler: failure while executing tar

Diese Meldung kann eigentlich nur auftreten, wenn die Datei in irgendeiner Form vorhanden ist... prüfen Sie bitte noch mal ob die auch wirklich in /var/cache/liveconfig/downloads/ gelöscht ist.

Ja, bei Änderungen an den Vertragseinstellungen wird die Konfiguration neu geschrieben, aber es werden auch die FastCGI-Instanzen neu gestartet.

Wenn eine PHP-Anwendung hängt und z.B. noch Dateien geöffnet hat, dann könnte das zu Problemen beim Upload führen. Falls das Problem mal wieder auftritt, mal mit "lsof" prüfen ob noch Dateien des betroffenen Benutzers geöffnet sind ("lsof also entsprechend mit z.B. "grep" filtern).

FileZilla ist im Zusammenspiel mit FTPS ohnehin problematisch; am besten im LiveConfig die Checkbox "SSL Session Reuse" bei den FTP-Server-Einstellungen deaktivieren.

Welchem Benutzer gehört denn das entsprechende Verzeichnis, und ist das Erstellen von Dateien darin erlaubt? (also Owner & Mode mal prüfen)

Wenn der Webspace evtl. mal auf mod_php konfiguriert war, könnte es sein dass einige Dateien/Verzeichnisse dem Webserver-User (www-data) gehören.

Am naheliegendsten: Webspace voll? (Quota)

Ansonsten schreibt vsftpd doch sicher irgendwas in's Log...

Viele Grüße

-Klaus Keppler

Zitat von Maxx

Funktioniert auch unter dem User liveconfig.

Kann es sein, dass die Auflösung der DL-URL nicht funktioniert? Also sprich, dass der Weg auf Amazons Server nicht gefunden wird?

Das ist äußerst merkwürdig.
Löschen Sie bitte die Dateien /var/cache/liveconfig/downloads/roundcubemail* und stoßen anschließend noch mal die RoundCube-Installation über den AppInstaller an. Ist die Datei wieder nur 0 Bytes groß?

Der AppInstaller führt als Benutzer "liveconfig" folgenden Befehl aus:

wget --no-check-certificate -O roundcubemail-1.3.9-complete.tar.gz https://github.com/roundcube/roundcubemail/releases/download/1.3.9/roundcubemail-1.3.9-complete.tar.gz 1>&2

Der Fehlerkanal (stderr) wird derzeit nicht protokolliert, das ist aber nur eine kleine Änderung die wir in v2.8 noch mit aufnehmen.