Beiträge von weltmeister

Ja... manchmal steht man eben auf dem Schlauch. Es wurde mit unbound gelöst. Aber trotzdem Danke für die Aufmerksamkeit

Ich weiß, das hat nichts mit LiveConfig zu tun. In den letzten Tagen habe ich das Gefühl, die Spamfilter spinnen. Die manuelle prüfung von Maildateien per z.B. spamassassin -t < test.eml ergeben unterschiedliche Ergebnisse. Siehe Bilder 1 und 2. Das hat auswirkungen auf die Zustellung der Mails. Hat jemand ähnliche Erfahrungen und was könnte die Ursache dafür sein?

Zitat von kk

Im LiveConfig selbst kann man in den Postfix-Einstellungen die Checkbox "IP-Adresse des SMTP-Absenders unterdrücken" setzen (ist auch aus Datenschutz-Gründen zu empfehlen).

Das haben wir aktiv. Aber viele andere Provider leider eben nicht. Die senden im Quelltext weiterhin die private IP der Kunden mit. Danke für den Tipp.

Hat jemand Erfahrungen mit dem Zusatz für die local.cf?

Viele Kunden beschweren sich über Mails die nicht durch die Spamfilter kommen. In den meisten Fällen ist nicht die IP des Absender-Servers das Problem, sondern die private IP-Adresse des Absenders, die im Queltext der Mails ersichtlich ist. Aktuelles Beispiel:

header Received: from PC (dslb-002-207-058-155.002.207.pools.vodafone-ip.de [2.207.58.155])

Diese private Einwahl-IP steht auf mehreren Blacklisten, die Server-IP des Providers jedoch nicht. Wie kann man verhindern, dass die private IP in die Spamprüfung einbezogen wird?

Das mit der URL ist auch eine sehr gute Idee. Kann man das bereits jetzt manuell irgendwo ergänzen oder ist das für eines der kommenden Updates geplant?

Das wäre eine große Hilfe und würde derzeit wirklich sehr viele Anfragen ersparen. Ich stelle mir das so vor:

Zitat

Ihre IP Ihres Providers X.X.X.X steht auf folgender DNS-Spam-Blacklist: xxxxxx

Wenn Sie Fragen zu einem Blacklisting Ihrer IP-Adresse oder nicht zustellbaren E-Mails haben, wenden Sie sich bitte ausschließlich unter Angabe dieser Fehlermeldung an Ihren eigenen E-Mail-Anbieter, nicht an XXX oder gar an den Webhosting-Kunden, den Sie versuchen zu erreichen!

Das wäre eine klare und deutliche Nachricht, die keinerlei Fragen aufkommen lässt. Der Absender leitet das so an seinen eigenen Provider weiter, dieser muss sich dann um das Delisting kümmern. Der Kunde weiß, wo der Fehler liegt.

Fast täglich melden sich aktuell teilweise panische Kunden, die glauben der Server hat eine Störung o.ä. - dabei liegt das Problem gar nicht bei uns. Klare und deutliche Kommunikation ist die Lösung.

Im Moment stehen viele IPs von Microsoft und Google auf Spam-Blacklisten. Viele Kunden haben den Spamfilter aktiv, werden Mails auf Grund dessen abgelehnt, bekommt der Absender nur diesen Text:

554 5.7.1 Your message was rejected because it appears to be spam

Ohne weitere Begründung.

99% aller Kunden glauben leider, der Fehler liegt bei uns. Die wissen gar nicht, dass der Provider des Absenders auf Spamlisten steht. (Woher auch?) Kann man diesen Text anpassen oder erweitern, z.B. mit einem Hinweis, das man sich bei Problemen mit Blacklistings an seinen eigenen Provider zu wenden hat und nicht an den Kunden den man versucht hat zu erreichen oder dessen Provider?

Im Moment kommen sehr viele Anfragen deswegen rein und wirklich jeder denkt, den Fehler verursachen wir. Nach Prüfung stellte sich bisher jedesmal heraus, dass die Absender-IPs teilweise auf bis zu 15 Blacklisten stehen.

Für einen Tipp wäre ich sehr dankbar, das würde viel Arbeit im Kundenservice ersparen.

Sollte schon erledigt sein, es gilt für alle PHP-Versionen.

Zitat von kk

Welche Distribution+Version?

Üblicherweise sollte es genügen, das Debian/Ubuntu-Paket libmagickcore-6.q16-6-extra zu installieren (je nach Distributions-Version kann der Name auch geringfügig anders lauten).

PHP-FPM muss danach ggf. neu gestartet werden (z.B. systemctl restart php80-fpm), damit die laufenden PHP-Instanzen die aktualisierten ImageMagick-Module finden und laden.

Viele Grüße

-Klaus Keppler

Alles anzeigen

Frage: diese Erweiterung gilt dann für die Standard-PHP-Version, oder auch für die zusätzlichen PHP-Versionen, welche durch LiveConfig bereitgestellt werden?

Geht es hier in der Entwicklung eigentlich weiter? Die letzten 3 Monate waren sehr ruhig.
Vorschläge für neue Funktionen wurden genug gemacht, die dem Admin die Arbeit erleichtern.

Vielleicht darf man auch erst in 10 -20 Jahren mit der Funktion rechnen...

Aber leider nicht über die Oberfläche, wie am 16. Februar 2018 angekündigt.

Zitat von kk

Wie wäre es, wenn LiveConfig ein Umschalten der CLI-PHP-Version per GUI ermöglicht?
Dazu würden wir dann /usr/bin/php durch ein (äußerst schlankes) Wrapper-Programm ersetzen, welches dann an den für den jeweiligen Vertrag/Benutzer ausgewählten Interpreter übergibt.

Eine andere (sauberere) Lösung sehe ich gerade nicht.

Wann gibt es diese Funktion? Das wäre eine große Hilfe, vor allem bei Kunden, die immer wieder anfragen... wäre das eine sorge weniger.

Reagiert eigentlich jemand unter der genannten Mailadresse?

Zitat von antondollmaier

Wir haben die Selbstverwaltung der Postfächer über den LCDEFAULTS "mail.weblogin.enabled=1" pauschal aktiv. Es gibt, IMHO, nur wenige Gründe, weshalb sich die Postfach-Nutzer nicht selbst anmelden können dürfen.

Danke, hieran habe ich gar nicht gedacht. Es gibt aber ein "aber": wenn der Kunde die Checkbox deaktiviert, steht die Passwort-Ändern-Funktion im Webmailer trotzdem bereit und spuckt eine Fehlermeldung aus. Der irritierte Kunde wundert sich. Es gilt grundsätzlich, Support-Anfragen wegen vermeintlich nicht funktionierenden Einstellungsmöglichkeiten zu vermeiden.

Gäbe es auch eine Lösung ohne Checkbox? Die Option im Webmailer steht ja allen Kunden bereit, auch denen, die die Checkbox nicht aktiviert haben und gar nicht wissen, dass diese erst aktiviert werden muss. Diese erhalten dann Fehlermeldungen.

Eine andere Idee wäre es, die Passwort-Ändern-Funktion im Webmailer automatisch auszublenden, wenn der Kunde die Checkbox nicht gesetzt hat.

Das wäre schlecht. Wie gesagt, 99,99% aller Kunden wissen wirklich nicht, das man erst den Haken in LiveConfig setzen muss, wenn im Webmailer die Möglichkeit besteht, das Passwort zu ändern.

Installierte LC Version: 2.18.10

Und ist bei dem betreffenden Mailaccount auch der "Self-service" in den Postfacheinstellungen erlaubt?
---> Nein. Ist das zwingend erforderlich? Ich würde die Option das Passwort zu ändern gern jedem Kunden anbieten, auch wenn dieser die Checkbox nicht aktiviert hat. 99,99% aller Kunden beachten diese erfahrungsgemäß überhaupt nicht.

Der Kunde hat sich in dem Falle mit der Mailadresse und dem Passwort angemeldet. Etwas anderes ist nicht zulässig. Was könnte noch die Ursache sein? Es ist noch LC aktiv.

Ich habe mich heute mal eingehend mit dieser Materie beschäftigt. Ich erhalte ebenso folgenden Fehler:

"Neues Passwort konnte nicht gespeichert werden. Ivalid e-mail and/or password"

config:

$config['password_driver'] = 'liveconfig';

$config['password_liveconfig_host'] = 'server1.xxxx.de';

$config['password_liveconfig_port'] = '8443'; // defaults to 8443

$config['password_liveconfig_accept_selfsigned'] = true; // accept self signed certificates

Die Datei liveconfig.php ist hier im Verzeichnis ergänzt: /htdocs/plugins/password/drivers

Hat jemand eine Idee oder gibt es irgendwo eine konkrete Anleitung oder funktioniert das Plugin schon gar nicht mehr? Noch ist LC2 aktiv.

Im Log steht nur: E-Mail password update failed - email='test1@meine-domain.de', IP='127.0.0.1'