Beiträge von kk

    Lässt sich das auch per Default für alle externen Weiterleitungen aktivieren? Der gemeine Anwender kann mit dieser Funktion i.d.R. nichts anfangen. Er ist es aber gewohnt, dass Weiterleitungen bei den großen Anbietern einfach funktionieren und da muss nichts extra aktiviert werden. Die wenden einfach SRS an, der Nutzer bekommt davon ja nichts mit.

    Wir wollten bewusst erst einmal mit einer "Opt-In"-Variante starten, um eventuelle Probleme frühzeitig zu erkennen.

    Die Architektur von Postfix - so flexibel diese sein mag - ist gerade bei SRS leider eher etwas nachteilig, weil anzupassende E-Mails da sehr speziell nach dem Umschreiben erneut in die Queue gesteckt werden müssen. Hier möchten/müssen wir vermeiden, dass bei diesem erneuten Queueing auch wieder Spamfilter, DKIM usw. nochmal angewendet werden, SPF keinen Ärger macht, usw...

    Wenn sich die SRS-Integration als soweit stabil "at scale" erweist, werden wir auch eine Möglichkeit bereitstellen, SRS als Default zu aktivieren und ggf. ein "SRS-Opt-Out" pro Postfach anzubieten.

    Hab gerade auch mal in meine main.cf geschaut. Da stehen zwei Zeilen drin:

    Code
    smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
    smtpd_tls_dh512_param_file = /etc/postfix/dh512.pem

    Ab Postfix 3.6 wird die untere Zeile stillschweigend ignoriert. Sollte LC die dann nicht auch rausnehmen, wenn sie in Bestandsinstallationen noch vorhanden ist?

    Danke, das werden wir prüfen! Die DH512-Parameter machen in dem Zusammenhang wirklich keinen Sinn mehr. Wird also voraussichtlich mit dem nächsten Update ebenfalls entfernt.

    Hallo,


    ab sofort stehen die gestern veröffentlichten PHP-Updates für die Versionen 8.1-8.4 sowie eine gepatchte Version 8.0 (backport) in unseren Repositories bereit (Debian 11/12, Ubuntu 20/22/24).

    Es handelt sich um ein Sicherheits-Update, eine zeitnahe Aktualisierung wird also empfohlen.


    Viele Grüße


    -Klaus Keppler

    Oh je.

    Also... der Support für Outlook 2010 wurde von Microsoft bereits am 13.10.2020 eingestellt. Die Verwendung von 1024bit-DH-Parametern gilt inzwischen nicht mehr als sicher (wenn man das als Provider dennoch anbietet, dann kann das ein Risiko darstellen - NIS2 etc lassen grüßen).

    Ich sehe hier prinzipiell zwei Lösungsansätze:

    1. über eine Konfigurations-Anpassung erlauben Sie serverseitig weiterhin 1024 Bit DH-Parameter (s.u.), oder
    2. der Kunde richtet einen TLS-Tunnel ein (z.B. mit stunnel), der auf Kundenseite "schwache" Verschlüsselung erlaubt und seinerseits eine sichere Verbindung zum Mailserver aufbaut

    Vorträge über die (Un)sicherheit solcher alter Software können wir uns ja vermutlich sparen...


    Variante (1) ließe sich einrichten, indem Sie eine Datei namens /etc/liveconfig/lua.d/postfix.lua anlegen, mit folgendem Inhalt:

    Prüfen Sie ggf. ob in Ihrer /etc/postfix/master.cf noch andere Optionen für den "submission"-Service gesetzt sind und nehmen diese hier ggf. mit auf. Wichtig ist eben die Option smtpd_tls_dh1024_param_file, um die alten DH-Parameter auch zu unterstützen.

    (eventuell muss noch die Option -o cleanup_service_name=cleanupfilter aufgenommen werden, wenn die IP-Adresse bei Submission aus den Received-Headern entfernt werden soll)

    Anschließend LiveConfig neu starten und die Postfix-Konfiguration neu schreiben lassen.

    Danke für den Hinweis!

    Wir werden das Paket in Kürze aktualisieren und ein AppArmor-Profil mit aufnehmen, um Problemen vorzubeugen.

    Die meisten Mail-Clients rendern spezielle Auszeichnungen von reinen Text-Mails wie folgt:


    • Sternchen: Fett gedruckt. *hallo* -> hallo
    • Unterstrich: Kursiv. _hallo_ -> hallo

    Ich habe einen Feature Request angelegt, in LiveConfig 3 einen HTML-Editor für den Autoresponder zu integrieren.

    Hallo,


    ab sofort steht LiveConfig v2.17.0 zum Download bereit. Neben kleineren Bugfixes und Detailverbesserungen bringt diese Version nun Unterstützung von SRS (Sender Rewriting Scheme). Die detaillierte Liste aller Änderungen findet sich wie immer im Änderungsverlauf.


    Für SRS muss die Software PostSRSD in der Version 2.x verwendet werden. Für Debian/Ubuntu stellen wir hierfür ein entsprechendes Paket bereit ("lc-postsrsd"), da die Distributionen derzeit noch Version 1.x mit ausliefern. LiveConfig ermöglicht dann ein "Opt-In" für SRS - das Verfahren kann einzeln pro Postfach aktiviert/deaktiviert werden.


    Viele Grüße


    -Klaus Keppler

    Haben Sie im LiveConfig in den FTP-Server-Einstellungen die Option "SSL session reuse erforderlich" aktiviert?

    Schalten Sie diese ggf. mal um und beobachten, ob der Fehler weiterhin auftritt.


    LiveConfig kann da ansonsten ohnehin nicht viel machen, da der eigentliche Fehler ja ganz offensichtlich im ProFTPD steckt...

    Identische Frage, identisches Thema:


    Möglicherweise Bug https://github.com/proftpd/proftpd/issues/1706

    Ohne Info zur ProFTPD- und Debian-Version kann ich nicht mehr sagen.

    Aus dem KB-Artikel haben wir die Blocklist nun auch entfernt.


    Die Ablehnung von Mails am Freitag Vormittag wird mancherorts nun als "temporärer Konfigurationsfehler" kommuniziert, seitens des ehemaligen Betreibers gab es leider keine Stellungnahme dazu (was ich in einem gewissem Umfang auch verstehen kann, da das ja nun nur noch Kosten verursacht und ohnehine ein "pro-bono"-Service war).

    Nichts desto trotz sollte die Liste aus allen aktiven Konfigurationen entfernt werden. Wir prüfen auch, ob wir das evtl im Rahmen der anstehenden v2.17 zuverlässig automatisch machen können.

    Guten Morgen,


    die DNS-Blocklist ix.dnsbl.manitu.net wurde zum Anfang dieses Jahres leider eingestellt. So wie es aussieht, beantwortet diese Blocklist ab sofort alle Anfragen positiv, d.h. alle geprüften E-Mail-Adressen werden somit als Spam-Absender abgewiesen!


    Falls Sie also diese DNS-Blocklist verwenden, entfernen Sie diese schnellstmöglich aus Ihrer Mailserver-Konfiguration!

    (Serververwaltung -> E-Mail -> Postfix-Einstellungen)


    Viele Grüße


    -Klaus Keppler

    Wir stecken derzeit unsere gesamten Ressourcen in die Fertigstellung von LiveConfig 3. Aktuell bearbeiten wir pro Woche bis zu 30 Issues (das sind alles Sachen, die man hier im Forum leider nicht sieht).


    Eben haben wir den ersten "Release Candidate" (RC1) in das Test-Repository gestellt. Aktuell haben wir nur noch vier "Showstopper" offen, teilweise aber etwas kompliziert (u.a. Migration der DNSSEC-Konfiguration im BIND).

    Anfang nächster Woche wird LiveConfig 2.17 freigegeben, und in dem Rahmen dann auch die Website bzgl LC3 aktualisiert.

    Für LiveConfig 3 führen wir zusätzlich einen öffentlichen Issue-Tracker - damit es da eben mehr Transparenz gibt (und zwar objektiv/konkret, und nicht allgemein).


    Viele Grüße


    -Klaus Keppler

    Hallo,


    vor etwas über einer Stunde hat eine Phishing-Attacke begonnen, deren Ziel Zugangsdaten zum LiveConfig-Lizenzportal sind. Diese E-Mail enthält etwa folgende Daten:

    Zitat

    Absender: "LiveConfig GmbH" <info@i[...]e.it>

    Betreff: Wichtige Nachricht – Bitte überprüfen Sie Ihr Dashboard

    Text: Sehr geehrte/r <E-Mail-Adresse>,
    wir hoffen, dass es Ihnen gut geht. Wir haben eine wichtige Nachricht für Sie in Ihrem Dashboard hinterlegt. Bitte loggen Sie sich so bald wie möglich ein, um diese einzusehen.
    [...]

    Der in der E-Mail enthaltene Link wird zwar mit https://www.liveconfig.com/... angezeigt, verweist aber auf eine Phishing-(Sub)domain die auf ein CDN geroutet ist.


    Uns liegen bereits mehrere dieser Mails vor. Wir haben die Adressen analysiert, und derzeit deutet nichts darauf hin, dass diese aus unseren internen Systemen stammen. Dennoch sind wir natürlich brennend daran interessiert, woher dieser Angriff und die verwendeten Adressen stammen. Wer eine solche Mail erhalten hat, möge diese bitte gerne an support@liveconfig.com weiterleiten.


    Sollte jemand den Link angeklickt oder gar irgendwelche Zugangsdaten eingegeben haben, wenden Sie sich bitte auch an uns, damit wir Ihren Account entsprechend prüfen können.


    Wer uns kennt, weiß ohnehin, dass eine solche E-Mail überhaupt nicht typisch für uns ist. ;)

    Sobald wir mehr wissen, werde ich hier darüber informieren.


    Viele Grüße


    -Klaus Keppler

    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.