Beiträge von thomas16

wie oben schon erwähnt habe ich hier die obige Sieve-Regel aktiv. Dabei lege ich allerdings den "Spam"-Ordner nicht selbst an - der Kunde bekommt auf Nachfrage die Informationen bezüglich des Ordners sowie Imap und damit hat er es selbst in der Hand.

Zitat von antondollmaier

Ich würde mal vermuten, dass der MySQL-Benutzer und dessen Passwort nicht korrekt sind.

alternativ hat der User joserv keine Rechte an der LC-DB

...zumal bei LC die Wege zur Bug-Behebung kürzer sind als bei vielen anderen Programmen. So ein Showstopper(tm KK) wird sehr wahrscheinlich mit einem der nächsten Updates behoben, sofern es ein Fehler im LC ist.

Zitat von bfal

Nicht wenn der Kunde das für seine Adressen selbst entscheiden kann.

genau das ist der Punkt und anders ist es nicht sinnvoll

zusätzlich wäre es wünschenswert, ganze TLD zu töten -> *.ru wäre doch nett

wenn es nen alternativen Weg gibt - immer her damit

ich hab hier eine globale Regel mit Sieve angelegt: Wenn der Kunde einen Ordner Spam anlegt, wird erkannter Spam verschoben, ansonsten bleibts im Posteingang

require ['fileinto'];
# rule:[Spam]
if header :contains "subject" "SPAM-Verdacht"
{
        fileinto "INBOX.Spam";
}

grade habe ich einem Kunde die Vorteile der zeitgesteuerten Abschaltung des Autoresponders schmackhaft gemacht, kommt doch direkt die Frage: geht das auch mit Weiterleitungen? (Kunden sind unberechenbar)

Nach kurzem Überlegen: klingt durchaus sinnvoll, denn es gibt genug Anwender, die nen Autoresponder für Abwesenheitszeiten zusammen mit einer temporären Mailweiterleitung nutzen.

*schweißabwisch* hab gelesen nen Berg Bugs abarbeiten

macht aber praktisch keinen Sinn, dass sich Rechte beim reboot ändern
Ich melde mich in ner ruhigen Minute

SA läuft, Erkennung alles mit 0,0

Zitat von antondollmaier

Ich bin mir auch sicher, dass LiveConfig niemals eine Version veröffentlicht, die Konfigurationen schreibt, die nicht Reboot-fest sind.

das glaube ich auch nicht, allerdings ist dass das Verhalten seit Deb8-Deb9

Ich checke das nochmal, wenn der nächste Reboot eh ansteht.

deb 9, komplett gepatcht und aktuellstes LC

Hier tritt das Problem des nicht funktionierenden SA nach jedem Reboot auf. ich habe mir für die Reaktivierung ein kleines Script gebastelt, was folgendes im Groben macht:
-Aufforderung in LC SA zu deaktivieren
-remove SA
-LC Neustart
-install SA und aktivieren im systemctl
-Aufforderung zur Aktivierung SA in LC
-LC diag

so sieht meine Umgehungslösung aus.

Hier ebenso fast problemlos. Wiedermal war es aber so, dass das Update nur durchlief, nachdem Lifeconfig vorher beendet wurde.

hier das Gleiche und danke für die Lösung, es ist also kein Einzelfall.

Es wird natürlich nur die entsprechende Version installiert - in meinem Fall die 10.0.4-1. diese wird dann auch als aktuell betrachtet. *kopfkratz*

würde ich als nicht sinnvoll erachten - beim Wechsel des DB-Servers kracht es dann unter Umständen - der kleinste gemeinsamme Nenner sollte da schon genutzt werden.

das Problem ist in dem Fall die Inkonsistenz der Konfigzeile nil vs. "php56"

Zitat von HBO

Gilt glaube aber auch nur für Neuverträge bzw sobald eine neue Domain hinzu gefügt wird.

Nachdem ich kürzlich auch ein Problem mit der defaut PHP-Version hatte, bin ich da mal etwas tiefer rein.
Ergebnis war, wenn die erste Zeile fehlerhaft in meinem Fall "nil" statt nil oder php5 statt nil wird die default Version der distri verwendet.
Bei einem Update von Deb 8 auf 9 verblieb php5 und php7 kam dazu. Deinstalliert man nun php5, wird default nun das php7 - bestehende Verträge die default PHP hatten, bekommen dann alles mit PHP7 ausgeliefert(wegen der fehlerhaften Zeile).
Sobald man php5 wieder als default konfiguriert hat, bekommen alle Altverträge wieder php5. Wichtig ist dazu nur, mal kurz in die Web-Einstellungen im LC gehen und einfach speichern.

Das zumindest meine Erfahrung - ob letzteres unnötig ist, habe ich nicht getestet.

PS: Die Anführungszeichen um nil sind tödlich

gefühlt läuft die Oberfläche noch etwas schneller - wurde an der Schraube etwas gedreht?

ebenso dafür - auch wenn ich noch keine Probleme an der Stelle hatte - sehr sinnvoll.

dazu bräuchte man Headerdaten und Logfiles, um da ne fundierte Auskunft geben zu können.
Vermutlich erfolgte der Versand an Adressen per BCC