Beiträge von kk

    Hallo,


    bei Let's Encrypt ist vor einigen Tagen ein Fehler bei der Ausstellung von Zertifikaten (CAA Rechecking Bug) bekannt geworden. Vereinfacht gesagt wurde die Prüfung von CAA-Records in bestimmten Fällen nicht korrekt durchgeführt.
    Gemäß der Bedingungen des Browser-Forums müssen fälschlicherweise ausgestellte Zertifikate innerhalb eines sehr kurzen Zeitraums zurückgezogen (revoked) werden.


    Konkret ist das so, dass Let's Encrypt seit wenigen Stunden (!) E-Mails an die Accounts versendet, deren Zertifikate betroffen sind (natürlich nur wenn eine Mailadresse beim Let's-Encrypt-Account hinterlegt ist).
    Die Frist für den Zertifikatsablauf endet am 04.03.2020 um 00:00 UTC (also 01:00 MEZ).


    Wir haben die Liste der betroffenen Zertifikate heruntergeladen (3.048.289) und machen derzeit folgendes:

    • wir bereiten einen REST-Webservice unter http://www.liveconfig.com vor, dem eine Liste an Seriennummern übergeben werden kann und der dann eine Liste der davon betroffenen Seriennummern zurückgibt
    • wir bauen in LiveConfig eine Funktion ein, die beim Start von LC eine Liste aller Zertifikate des betroffenen Zeitraums zusammenstellt und über den o.g. Webservice abgleicht
    • zeitgleich wird es eine Funktion in LC geben, um eine Neuausstellung der betroffenen Zertifikate anzustoßen


    Wir arbeiten mit Hochdruck an der Sache. Über den Fortschritt werden wir in diesem Thread informieren.

    Der Upload-Scan ist über die suhosin-Erweiterung realisiert.


    Ich habe das eben mal unter Debian 10 mit PHP 5.6.40 getestet - eine Textdatei und einmal die Eicar-Testsignatur hochgeladen. Die Virus-Erkennung hatte geklappt, die andere Datei wurde fehlerfrei angenommen.


    - wie läuft PHP bei Ihnen? FPM oder FastCGI?
    - was passiert, wenn Sie als Web-User das uploadscan-Script ausführen?
    (also z.B. mit "su -s /bin/bash <Vertrag>" in einen User wechseln, dann uploadscan.sh mit einer Datei innerhalb des User-Webspaces ausführen)
    - klappt der File-Upload mit anderen PHP-Versionen?

    Mit LiveConfig v2.9.2 wird es auch möglich sein, Wildcard-Domains bei den Postfach-spezifischen Blacklists/Whitelists anzugeben - zum Beispiel *.example.org oder sogar *.tld.


    Viele Grüße


    -Klaus Keppler

    Als Workaround (wenn man den Stick nicht zur Hand hat): das Passwort + OTP zusammen eingeben (also den OTP-Code direkt ans Passwort dranhängen).


    Wir haben diesen Effekt mit neueren Browsern auch schon beobachtet und das auf die ToDo-Liste gesetzt.


    Viele Grüße


    -Klaus Keppler

    Die von LiveConfig erzeugte Mobileconfig verwendet als "PayloadIdentifier" den Namen des Mailservers.
    Das führt dann vermutlich zum Ersetzen.


    Wir werden das mit dem kommenden Update (v2.9.2) durch die E-Mail-Adresse ersetzen - damit sollte das eindeutig bleiben.


    Bis dahin müssten mehrfache Adressen auf dem selben Mailserver ggf. manuell auf dem iPhone angelegt werden.


    Viele Grüße


    -Klaus Keppler

    Ich beende die Diskussion an dieser Stelle.


    Die gewünschte Funktion wird es (um des Friedens willen) geben, aber natürlich optional und standardmäßig nicht aktiviert.


    Wir raten aus mehrfach genannten Gründen dringend vom automatischen Verschieben verdächtiger Mails in einen Spam-Ordner ab.


    Thread hiermit geschlossen.

    Es steht doch ganz klar das es einen ersten Ausblick (wenn alles Glatt geht) mit der kommenden 2.9.2 gibt?!


    Exakt.
    Um genau zu sein: der Backup-Service selbst (lcbackup) ist tatsächlich schon fertig und wird auch seit v2.9.0 schon installiert (aber noch nicht aktiviert). Wir arbeiten aktuell "nur" noch an der Konfiguration der Backups. Und das ist in der Tat wesentlich komplexer als "nur mal nen Cron-Job einzurichten"... ;)

    Vorab schon mal ein paar Worte zu unserem System:
    das Backup wird durch einen separaten Prozess durchgeführt (lcbackupd). Die einzelnen Backupjobs laufen in separaten Threads - die Anzahl der gleichzeitigen Threads ist konfigurierbar (kann man also dann je nach Serverleistung/-Last anpassen).
    Ebenso ist frei konfigurierbar, zu welchen Zeiten welche Backups erzeugt werden - so kann man z.B. einmal täglich ein Vollbackup erstellen, und alle vier Stunden die Datenbanken sichern usw.
    Damit Kunden den Server nicht "abschießen", ist ebenfalls konfigurierbar, ob Kunden ggf eine gewisse Zeit abwarten müssen bis sie ein neues Backup anstoßen können (um nicht alle zwei Minuten ein Backup zu erstellen ;)
    Last but noch least ist die Anzahl der vorgehaltenen Backups ebenfalls frei konfigurierbar - sowohl der vom System erstellten (automatischen) Backups, als auch der vom Kunden erzeugten.


    Wenn alles glatt geht gibt's einen ersten Ausblick bereits mit dem kommenden Update v2.9.2.


    Viele Grüße


    -Klaus Keppler

    Können wir dafür in der Mailverwaltung oder beim Account das Feature deaktivierbar haben?


    Und den Default auf "nicht verschieben", so dass der Nutzer/Kunde das explizit für jedes Postfach aktivieren muss?


    Ja, so ist das geplant. In den Mailservereinstellungen kann das dann grundsätzlich aktiviert/deaktiviert werden, zudem pro Postfach. Ich sehe das auch so, dass Kunden das ausdrücklich aktivieren sollen, dann ist zumindest klar wer daran schuld ist, wenn Mails "plötzlich" verschoben werden...

    Nun, man kann den Kunden alternativ auch erklären, warum ein "Spam-Ordner" eben keine gute Idee ist und man ihn deshalb bewusst nicht anbietet.


    Hinterfragt denn wirklich niemand den Sinn und Zweck von dem Ganzen?


    Nutzt denn niemand hier Google Mail? Kann ich mir gar nicht vorstellen...


    Fakt ist: E-Mails, die im Spam-Ordner landen, werden nur extrem selten angeschaut (wenn überhaupt). Das hat dann folgende Nebenwirkungen:

    • dieser Ordner wird von den meisten Kunden nie gelöscht werden (=> müllt zu)
    • fälschlicherweise dort einsortierte Mails werden übersehen
    • korrekterweise dort einsortierte Mails werden aufgehoben (=akzeptiert) statt diese direkt abzuweisen


    Bei Google Mail ist es ein zunehmendes Problem, dass Mails voreilig im Spam-Ordner landen und somit beim Empfänger faktisch nicht ankommen.


    Meiner Meinung nach sollte man sich darauf fokussieren, möglichst viel Spam direkt abzulehnen.
    Bayes-Filter werden dafür übrigens überbewertet. Wenn man ClamAV und SpamAssassin richtig tuned und regelmäßig pflegt, hat man letztendlich viel mehr davon. Mit einer guten Kombination aus DNS-Whitelist, Greylisting, DNS-Blacklists, ClamAV mit zusätzlichen Regeln (z.B. Sanesecurity) und SpamAssassin mit entsprechender Pflege (z.B. Scores für SPF/DKIM anpassen, ggf. selber DMARC einführen, usw.) erhält man fantastische Ergebnisse.


    Aber für "unbelehrbare" werden wir dieses Feature dann wohl mit einem der nächsten Updates einführen. Beim Setzen der Checkbox ("verdächtige Mails in Spam-Ordner verschieben") wird dann einfach eine entsprechende Sieve-Regel erzeugt.
    Aber noch mal: ich rate dringend davon ab - das gibt nur Ärger ("Hilfe meine E-Mails kommen beim Empfänger nicht an", "Hilfe ich erwarte eine Mail aber die kommt nicht", "Warum kommen über POP3 nur manche Mails bei mir an?", und so weiter...)


    Viele Grüße


    -Klaus Keppler

    Alternativ eine IP-Gruppe bearbeiten (z.B. Namen ändern).


    Die neuen Pfade für die Domainvalidierung wurden mit v2.9 eingeführt, wobei LiveConfig da während des Upgrades eigentlich alle vHosts hätte aktualisieren sollen.
    Auf welcher Distribution arbeiten Sie, und wissen Sie noch welche Version vor dem Upgrade auf 2.9.0 lief?

    Das Problem findet sich in dieser Meldung:

    Code
    /opt/php-7.3/lib/extensions/no-debug-non-zts-20180731/igbinary.so: undefined symbol: ps_globals


    Die "igbinary"-Extension benötigt zwingend die "sessions"-Extension.
    Auf welcher Distribution arbeiten Sie, und haben Sie das sessions-Modul eventuell deaktiviert?


    (das Laden der igbinary-Extension erfolgt über /opt/php-7.2/etc/conf.d/zz_18_igbinary.ini - und somit erst *nach* der session.ini)