Sie können die IPs des Kunden nur nicht als Admin bearbeiten. Wenn Sie eine Session als Kunde/Reseller starten, dann können Sie die IP-Einstellungen bearbeiten.
Wird trotzdem überarbeitet... ![]()
Sie können die IPs des Kunden nur nicht als Admin bearbeiten. Wenn Sie eine Session als Kunde/Reseller starten, dann können Sie die IP-Einstellungen bearbeiten.
Wird trotzdem überarbeitet... ![]()
Eben wurde Version 1.7.4-r3086 mit folgenden Änderungen freigegeben:
Vielen Dank für die Rückmeldungen!
Bezüglich der Auswahl der PHP-Versionen für NGINX: das ist etwas komplizierter: da NGINX ja nicht selbst die notwendigen FastCGI-Instanzen starten kann, haben wir hierfür ein Helfer-Script (/etc/init.d/nginx-php-fcgi). Dieses liest aus den NGINX-vHost-Konfigurationen jeweils aus, was für PHP-Instanzen gestartet werden sollen. Dort unterstützen wir derzeit nur eine PHP-Instanz pro Vertrag in NGINX.
Wir erweitern aktuell dieses Starter-Script sowie die notwendigen Anweisungen in den NGINX-vHosts, in Kürze* sollten also auch verschiedene PHP-Interpreter mit NGINX möglich sein.
*) voraussichtlich bis Ende kommender Woche
Eben wurde Version 1.7.4-r3086 mit folgenden Änderungen freigegeben:
Vielen Dank für die Rückmeldungen!
Kurze Vorab-Info: DKIM wird ab der nächsten LC-Version (1.8.0) direkt unterstützt. Dabei bietet LC dann die Möglichkeit, Keys selbst zu erzeugen oder zu importieren, erstellt ggf. die dazugehörigen DNS-Records und konfiguriert OpenDKIM entsprechend.
Eine erste Vorab-Version dürfte in ca. 2 Wochen bereit stehen.
Hmm, Fehler gefunden: wenn in den LCDEFAULTS bei den ".enabled"-Feldern eine "1" gesetzt ist, dann wird diese Option auch aktiviert wenn die Checkbox nicht angehakt ist (ist ein unerwünschtes Verhalten unserer Formularklasse: wird eine Checkbox nicht gesetzt, wird diese natürlich auch nicht im HTTP-Request an den Server gesendet - uns hier fügt die neue LCDefaults-Funktion eben dann den Wert aus der Datenbank ein
Merkwürdig, dass uns das nicht auch schon aufgefallen ist.
Ich empfehle daher, vorerst die .enabled-Werte in der LCDEFAULTS auf "0" stehen zu lassen. Die Fehlerbehebung ist recht einfach und dürfte morgen früh schnell erledigt sind.
Viele Grüße
-Klaus Keppler
Ach ja, zur nachträglichen Aktivierung (=Massen-Update aller Postfächer) ist auch schon eine Lösung in Arbeit - Details dazu dann auch bis Ende der Woche. Ein einfacher Eingriff in die DB genügt jedenfalls nicht, da die gewünschten Änderungen aktiv angetriggert werden müssen, damit der LC-Client-Prozess diese übernimmt.
Die Werte aus LCDEFAULTS werden nur beim Programmstart eingelesen - d.h. starten Sie LC bitte neu, dann sollten auch die neuen Werte gelten.
(Die Doku für LCDEFAULTS kommt noch bis Ende dieser Woche ins Handbuch ;))
Der Fehler wurde mit v1.7.4-r3082 beseitigt (wird in Kürze bereitgestellt).
Mir sind noch zwei Dinge aufgefallen: Wenn ich eine Weiterleitung erstelle und als Ziel http://www.domain.de/* eingebe, erfolgt die Weiterleitung auf z.B. http://www.domain.de//index.php (man beachte die zwei Schrägstriche).
Ist mit v1.7.4-r3080 erledigt.
ZitatUnd bei mir sind die Tooltips für die Weiterleitung und die PHP-Version beim Bearbeiten einer Domain auf Englisch.
Ist mit v1.7.4-r3081 erledigt.
Eben wurde eine weitere Aktualisierung bereitgestellt (v1.7.4-r3079): nach Aktivierung vom SpamAssassin musste LiveConfig bislang neu gestartet werden, da es sonst die Spam-Einstellungen nicht in /etc/postfix/spamassassin angelegt hatte. Dieser Fehler (eine Zeile in Lua...) ist damit beseitigt.
Sie meinen vermutlich PHP 5.3.x für Debian 7?
Wurde eben aktualisiert, nun ist da auch das SOAP-Modul mit drin (php-5.3-opt_5.3.29-1+wheezy11_amd64.deb)
Einfach nur das Paket "spamassassin" installieren und LiveConfig neu starten - das war's.
Hallo,
es sieht so aus als ob die Spam-Einstellungen erst nach einem LiveConfig-Neustart in /etc/postfix/spamassassin geschrieben werden. Wer also das selbe Problem hat, einfach LiveConfig mal neu starten. Wir suchen bereits nach der Ursache...
Eben wurde noch eine aktualisierte Version bereitgestellt (v1.7.4-r3077), bei der die korrekten Spamfilter-Standardwerte für bestehende Postfächer voreingestellt sind. (3.0/5.0 statt 0/0).
Was aber immer noch ist das die /etc/postfix/spamassasin Datei bis auf den LiveConfig Header leer bleibt...
Haben Sie für irgendein Postfach (Hosting -> E-Mail -> Postfach bearbeiten) den Spamfilter aktiviert?
Ab sofort steht eine aktualisierte Version bereit (v1.7.4-r3077), bei der korrekte Spamfilter-Standardwerte für den Spamfilter voreingestellt sind.
Die Meldung "lcsam_lookup(Empfänger
not found" heißt nur, dass lcsam bei einer eingehenden E-Mail an Empfänger keine Spamfilter-Einstellungen in /etc/postfix/spamassassin(.db) finden konnte - die E-Mail wird somit ungefiltert zugestellt.
Sobald Sie im LiveConfig bei einem konkreten Postfach die Spamprüfung aktivieren, sollte die betroffene Mailadresse (und alle Aliase) in die /etc/postfix/spamassassin mit aufgenommen werden. Passiert das nicht, dann prüfen Sie bitte mal die /var/log/liveconfig/liveconfig.log, ob dort irgendwelche Meldungen auftauchen.
Prüfen Sie bitte, ob in der Datei /etc/postfix/spamassassin ein Eintrag für die Empfängeradresse (hier: user@empfaenger.ch) existiert - danach sucht lcsam nämlich. Außerdem sollte die Datei /etc/postfix/spamassassin.db existieren jünger oder gleich alt wie die /etc/postfix/spamassassin sein.
Bei verdächtigen Mails wird (wie im Handbuch beschrieben) der Betreff modifiziert (***Spam-Verdacht***). Zudem sind im Mail-Header die Ergebnisse der SA-Analyse enthalten. Wenn Sie für Ihre Kunden einen ausführlichen Report wünschen, dann können Sie das gerne in der SpamAssassin-Konfiguration aktivieren.
Update: report_safe wird wohl doch nicht klappen, da lcsam nur die Ergebnisse der Spamprüfung vom SpamAssassin-Prozess ausliest. Es ist SA also nicht möglich, eine Mail zu modifizieren (in diesem Fall also z.B. einen Bericht vorzuschalten). Bei Bedarf können wir das längerfristig in lcsam mit aufnehmen.
Ich habe eine Stunde herumgemacht. Spamassassin klappte erst, nachdem ich mich einmal mit den Emaildaten direkt in Liveconfig einloggte, dann gings für alle Konten. Vorher als Kunde/Reseller: Keine Chance, auch nichts im Logfile
Das Anmelden im LiveConfig hat nichts mit SpamAssassin/lcsam/Postfix/etc. zu tun.
ZitatNa was nützt ein "Spam-Verdacht", wenn die Email dann einfach so angezeigt wird?
Bei verdächtigen Mails wird (wie im Handbuch beschrieben) der Betreff modifiziert (***Spam-Verdacht***). Zudem sind im Mail-Header die Ergebnisse der SA-Analyse enthalten. Wenn Sie für Ihre Kunden einen ausführlichen Report wünschen, dann können Sie das gerne in der SpamAssassin-Konfiguration aktivieren. Da diese Berichte aber i.d.R. auf Englisch sind, weiß ich nicht, ob Sie damit wirklich weniger Verwirrung bei den Kunden stiften. Aber das kann jeder so machen wie er will. ![]()
ZitatIch habe den Wert für Abweisen auf 999 gesetzt und die Spamassi-Testzeichenkette gesendet: Email wurde abgewiesen. Klar, der Test ist krass, aber ich möchte sicherstellen, dass nie abgewiesen wird.
Kein Wunder, das GTUBE-Testmuster wird durch SpamAssassin mit 1000 Punkten bewertet. Siehe Doku. Und im Log finden Sie das auch:
ZitatSep 23 11:27:34 test lcsam[12006]: 88.198.223.3: REJECT (SPAM 1000.0/5.0/3.0), From: [...], To: [...], Subject: Spam-Test...
Viele Grüße
-Klaus Keppler