Plesk 9.2.1 Greylisting

[Huschi]

Klar, super Idee einfach mal ein paar Server auf die Auth-Whitelist zu setzten.
Alternativ: Weg von dem veralteten und in der heutigen Zeit absolut überflüssig gewordenen SMTP-after-POP!

Bin mal gespannt wie die Reaktionen hier sind...

huschi.

 

[Twister]

Also irgendwie funktioniert beim grey von plesk die whitelist nicht habe dort *arcor.de eingetragen jetzt schick ich mir ne mail und sie wird trotzdem gegryd

Was mir auffält ist ersagt mir über das panel

Teste eMail-Adresse Adresse ungültig

die mail gibts aber


Eine frage hätte ich zu den einträgen in der Blacklist
was bedeuten den diese einträge?

*[0-9][0-9][0-9].[0-9][0-9][0-9].[0-9[0-9]][0-9]*

Gruss
Twister

 

[haggybear]

Also irgendwie funktioniert beim grey von plesk die whitelist nicht habe dort *arcor.de eingetragen jetzt schick ich mir ne mail und sie wird trotzdem gegryd

WO hast Du das eingetragen, in welcher Datenbank, in der welcher Tabelle??

Gruß
Haggy

 

[Twister]

WO hast Du das eingetragen, in welcher Datenbank, in der welcher Tabelle??

Wo: in deinem GLM
Welche Tabelle: [White/Blacklist] linke Seite wo auch die mail.ru und so gestanden sind.

habe aber glaube ich rausgefunden unter Administration steht noch was von 5 min wenn ich das auf null setzte und die mail wurde schonmal akzeptiert funktioniert es ob das nun mit zusammen hängt kann ich leider nicht beurteilen.

Gruss Twister

 

[Twister]

Und das mit dem es sei die Adresse ungültig kommt bei mehreren vor obwohl die wirklich existieren

Gruss
Twister

 

[zeroninja]

Scheinbar werden die Einträge in der Mysql Datenbank ignoriert bzw. es zählen nur die Einträge in der settings.db, ich weiß jetzt nicht ob im glm an beiden Stellen Änderungen vorgenommen werden.

Wenn du root - Zugriff auf den Server hast, lad dir doch mal die settings.db runter (/var/lib/plesk/mail/greylist/settings.db) und sieh die dir mal mit einem SQLite Browser an. (gibt es zB als Addon für Firefox )

Mit dem Addon kannst du dann zb auch direkt die einträge editieren.

Die Einträge mit den Zahlen dienen dazu dial-up und Server ohne ReverseDNS zu blocken.

Beispiel:
list type: black, from: port-92-204-47-106.dynamic.qsc.de, match string: .*[0-9][0-9]-[0-9][0-9]-[0-9][0-9].*

Gruß
zeroninja

 

[haggybear]

Wenn du root - Zugriff auf den Server hast, lad dir doch mal die settings.db runter (/var/lib/plesk/mail/greylist/settings.db) und sieh die dir mal mit einem SQLite Browser an. (gibt es zB als Addon für Firefox )

Warum so umständlich? Einfach auf der Konsole:

sqlite3 /var/lib/plesk/mail/greylist/settings.db

Und los gehts!

Gruß
Haggy

 

[zeroninja]

Ich gehe immer erstmal davon aus, dass die meistens Benutzer wenig auf der Konsole machen wollen und lieber etwas rumklicken, wenn möglich.
(Wir sind doch alle Opfer von GUIs )

Aber wer natürlich lieber die Konsole nutzt und sich mit SQLite da dann auskennt, kann das natürlich auch da machen. *g*

Gruß
zeroninja

 

[nocrash]

und noch was vom Support

es ist leider weder ein Termin noch ein Workaround ansonsten bekannt. Bitte beachten Sie dazu den Artikel des Herstellers unter:
KB Parallels: [Info] Errors "database is locked" are shown in maillog. That cause them?

Was spricht dagegen, dass Ihre Kunden SMTP-Auth nutzen?

Der letzte Eintrag der beschriebenen Art ist 5 Tage alt
(www pop3d-ssl: IMAP connect ), und die /var/lib/plesk/mail/poplock/poplock.db ist aktuell. Das passt also noch nicht zu unserem relaylock, authpsa Block Problem.

 

[Huschi]

@nocrash:
Ich kann mich dem Support nur anschließen. Was spricht gegen das modernere SMTP-Auth?
Und Deine Argumentation bzgl. der aktuellen poplock.db verstehe ich nicht.

huschi.

 

[nocrash]

Naja,mehrere hundert Kunden,die jetzt umkonfigurieren müssen.Aber hast recht,haben lange genug SMTP-Auth verweigert;-) ich bezog meine db Anspielung auf den db lock eintrag, der tauchte nämlich nicht in den logs auf,als das system die letzten Tage immer wieder stand.

 

[Huschi]

Da kann ich nur sagen:
Dann hast Du wohl hunderte von Kunden seit Jahren falsch beraten.

Nur weil Deine Symptome nicht ganz auf die Fehlerbeschreibung passen, heißt es nicht, dass es dennoch Abhilfe schaffen könnte.

huschi.

 

[haggybear]

Dann hast Du wohl hunderte von Kunden seit Jahren falsch beraten.

Dem kann ich mich nur bedingt anschließen. Sicherlich ist POP-Before doch schon eher ein Relikt aus längst vergangenen Zeiten, aber ich glaube die Devise sollte auch ein Stück weit sein "Never touch a running system".

BTW:
Hat jemand auch schon festgestellt sobald ein wenig (mehr) Last auf die SQlite-DB geht, der Speicherverbrauch exponentiell nach oben schießt?

Gruß
Haggy

 

[Huschi]

aber ich glaube die Devise sollte auch ein Stück weit sein "Never touch a running system".

Nach über 10 Jahren greift dieser Spruch nicht mehr.
Wenn man bedenkt, dass SMTP-after-POP nur eine Übergangslösung war, bevor sich die SMTP-Auth umgesetzt und als RFC veröffentlicht wurde, setzt jeder, der es immer noch einsetzt einfach aufs falsche Pferd.

PS: Zu SMTP-after-POP gibt es keine RFC!
Sprich: Es war/ist/wird nie standardisiert.

huschi.

 

[haggybear]

Nach über 10 Jahren greift dieser Spruch nicht mehr.

Das haengt aber auch von den eigenen Moeglichkeiten ab. Wenn man nicht weiss wies geht, dann gilt 'never touch....'

Gut ist aber auch egal, das SMTP after POP3 hat damals gmx als erstes/r verbrochen, daher denke ich das es sowieso niemals zur Diskussion stand, es zu standardisieren.

Gruss
Haggy

 

[Twister]

Hatte das gleiche Problem, bzw. bei uns wurde der Server mit relaylock und psa_auth prozessen zugemüllt, bis er fast still stand.
Fehler wird behoben:
-Greylistening Serverweit ausschalten
-Qmail stoppen (falls nicht von selbst gestoppt)
-Über Konsole /usr/local/psa/admin/sbin/mchk ausführen

Danach geht wieder alles, der Server rennt und kommt langsam zur Beruhigung. Wichtig dann in der /var/log/mail.err schauen, welche Postfächer unter Umständen Probleme machen.

Habe ja das gleiche Problem nur wird bei mir durch die oben beschriebene Methode der Fehler leider nicht behoben.
Ich kann nur feststellen, dass alle 2 Wochen am Sonntag mein Server sich ins nirvana befördert.
Habe mir zwar selber einscript geschrieben , dass mir die Processe zählt und ab einer bestimmten anzahl PSA einfach stoppt und wieder neustartet.

Gibts hier schon was neues ?

Gruss
Twister

 

[Schewal]

Das Greylisting zieht mir mittlerweile den kompletten Server runter und startet immer mehr Prozesse mit /usr/local/psa/handlers/info/05-grey-fskV6m/executable

Kann man das irgendwie abstellen, hat jemand dafür eine Lösung?

Bei mir jetzt auch, gibts da schon eine Lösung?

 

[Schewal]

**********

 

[Schewal]

Ich hab jetzt spamassassin deaktiviert, jetzt läufts eig. wieder stabil. Kann es sein dass sich die beiden nicht vertragen?

 

[rukl]

Kann ja nun auch nicht die Lösung sein...

...dass man bei einem kostenpflichtigen Produkt solange wichtige Funktionalitäten abschaltet, bis es irgendwie läuft aber eben nicht so, wie angedacht und behauptet. Oder die Klippen durch Einsatz von Drittlösungen umschifft. Und in Zusammenhang mit Plesk gibt es einige dokumentierte, elementare Eigenschaften, die zum versprochenen Leistungsumfang gehören und nicht funktionieren. Und dann ist das System so geschlossen, dass man nur wenig Chancen hat, effektiv Fehlersuche zu betreiben. Und dann die Schuld bei den Kunden zu suchen, die einfach nur das falsche wollen - fragwürdig!

Im Resultat kann man da nur festhalten: für den ernsthaften Einsatz zu riskant und bis man sich da alles zusammengebastelt hat, kann man auch direkt völlig ohne Plesk arbeiten. Das eigentliche Argument für so ein Tool ist ja die Zeitersparnis beim Aufsetzen und Administrieren.

Ich für meinen Teil werde genau das demnächst dann auch machen sobald ich die Zeit dafür habe.

Gruß rukl