Beiträge von kk

Zitat von antondollmaier

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

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.27, 7.3.14 und 7.4.2 aktualisiert.
Ebenso wurde die igbinary-Extension auf die Version 3.1.2 aktualisiert.

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?

Danke für den Hinweis - wir haben den Fehler eben reproduzieren können.

Wir werden die Sache nun analysieren und kurzfristig beheben (mit v2.9.2).

Viele Grüße

-Klaus Keppler

Das Problem findet sich in dieser Meldung:

/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)

Das passiert ja sicher nicht plötzlich, sondern nach irgendeinem Ereignis.
Ich tippe mal darauf, dass Debian aktualisiert wurde?
In dem Fall unter "Serververwaltung" -> "Mail" die Dovecot-Konfiguration neu schreiben lassen.

Viele Grüße

-Klaus Keppler

Starten Sie bitte LiveConfig mal neu und versuchen die Installation nach ca. 60 Sekunden noch mal (LC aktualisiert kurz nach dem Start das AppInstaller-Repository).

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.26, 7.3.13 und 7.4.1 aktualisiert.
Zudem wurde im PHP 7.4-Paket ein Fehler mit der XML-Extension behoben.

Viele Grüße

-Klaus Keppler

PHP 7.4 wurde eben aktualisiert (PHP 7.4.1) - damit sollte auch die XML-Extension korrekt funktionieren.

Viele Grüße

-Klaus Keppler

Zitat von leonex

Hallo,

aus den 7.4 Paketen funktioniert pecl/pear gar nicht:

root@referenz:/opt# /opt/php-7.4/bin/pear install xdebug
[...]
XML Extension not found

Das Problem ist bekannt (da gibt's gerade einen anderen Thread zu dem Thema). Offenbar enthält unser PHP 7.4-Paket zwar die XML-Bibliothek, aber nicht so wie manch andere Extensions das brauchen.

In diesem Moment wird aber gerade PHP 7.4.1 compiliert und paketiert - das dürfte in ca. einer Stunde fertig sein. Da ist XML dann korrekt eingebunden.

Also am besten gegen 13:00/14:00 PHP auf 7.4.1 aktualisieren und dann noch mal testen.

Viele Grüße

-Klaus Keppler

Die Frage war an tfi gerichtet... Was auf irgendwelchen anderen Systemen herauskommt spielt überhaupt keine Rolle.

Mit der nächsten Version (2.9.2) gibt es die Möglichkeit, pro IP-Gruppe TLS1.0/1.1 abzuschalten (analog der SSL-Chiffren-Auswahl und der HTTP/2-Option).
Die Änderung wurde eben committed, wir müssen nun noch testen ob die generierte Konfiguration auf allen Plattformen wie erwartet funktioniert.

Welche Distribution genau nutzen Sie?

Und was liefert folgende Ausgabe:

/opt/php-7.4/bin/php -i | grep -i xml

Wenn's doch nur immer solche kleinen Wünsche wären...

Der CSV-Export ist letztendlich nur eine Sache von ca. 30 Minuten (der technische Unterbau dafür ist ja komplett vorhanden, wir müssen nur die Datenaggregierung ein wenig dafür anpassen).
Ist also vermutlich im nächsten Update (v2.9.2) bereits vorhanden.

Let's Encrypt via API ist in Arbeit, könnte mit v2.9.2 fertig sein (Mitte Januar).

Das mit der Expertenansicht bei neuen Domains haben wir aufgenommen, wird auch kurzfristig korrigiert.

Hallo,

ab sofort steht LiveConfig v2.9.1 zum Download bereit.

Dieses Update beinhaltet ausschließlich Bugfixes und kleinere Verbesserungen - die vollständige Liste finden Sie wie immer im Changelog.

Viele Grüße

-Klaus Keppler

Danke, ist bereits bekannt und wird gerade korrigiert (ist eine "Nebenwirkung" von Arbeiten an der Berechtigungsprüfung in der Domainverwaltung)

Das gibt es eigentlich schon, habe eben gesehen dass das aber nur in unserem Debian-Test-Repo enthalten ist. Wir übernehmen es gleich auch ins "normale" Repo.

Interessant. Ich habe mir den betroffenen Code angesehen: lcsam reicht die eintreffende E-Mail komplett (also inkl. aller Header) an spamd weiter. Allerdings enthält die Mail vom Postfix zu diesem Zeitpunkt offenbar noch keinen "Return-Path:"-Header (mit dem Envelope-From).

Wir haben lcsam nun so angepasst, dass er den Envelope-From selber als Return-Path: an den spamd übergibt. In unseren Tests hat der SPF-Check somit geklappt.

Die Änderung ist bei GitHub bereits eingecheckt, in der kommenden Version 2.9.1 ist das dann auch berücksichtigt.

Viele Grüße

-Klaus Keppler