Hallo,
ja, das habe ich auch gedacht. Aber dann habe ich folgenden Artikel gefunden:
Artikel von heinlein-support.de zu rspamd
Und heinlein ist sehr aktiv in diesem Feld unterwegs.
Das Resümee scheint mir zu sein, das beide Plattformen anfangs ähnlich effektiv sind, die Lernkurve bei rspamd jedoch etwas langsam ansteigt, dafür aber am Ende effektiver ist. Aber ich bin da eher Laie, deswegen wäre ich für Feedback hierzu dankbar.
Hallo zusammen,
ich habe nach wie vor trotz Einsatz von spamassassin und vieler Optimierungen der Konfiguration weiterhin regelmäßig mit viel Spam zu kämpfen.
Im Internet habe ich gelesen, das es rspamd gibt und dieses wesentlich effektiver sein soll.
Hat hier jemand schon Erfahrungen mit sammeln können?
Es läßt sich wohl sowohl in dovecot als auch in sendmail einklinken.
Ich würde mir wünschen, das dies als alternative Option in künftigen Server-Umgebungen von pd-admin mit berücksichtigt wird.
Hallo zusammen,
ich habe gerade gesehen, das Roudcube 1.4.1 als Stable veröffentlicht wurde.
Wird diese Version demnächst in die PD-Admin Server Umgebung mit aufgenommen?
Das sollte zwar eigentlich keine Rolle mehr spielen, aber hast du mal geschaut, ob die richtige Perl Version verwendet wird?
Früher musste man die Datei /usr/bin/perl durch eine symbolischen Link auf /usr/local/pd-admin2/bin/perl ersetzen.
Tat man es nicht, konnte es passieren, das der Standard Perl Interpreter des Linux Betriebssystems aufgerufen wurde, der natürlich seine eigenen Klassen aufrief und nicht die Klassen der PD-Admin Installation kannte.
Welche PHP Version hast du denn für die NextCloud Installation verwendet?
Es gibt einen dokumentierten Bug: PHP Bug 78516
Der bewirkt, das der Password Hash nicht korrekt ausgelesen und geschrieben wird.
Abhilfe war wohl in der Nextcloud Installation in der Datei hasher.php die Größe der Memory Cost auf =>8 einzustellen;
dann funktioniert wohl alles.
Ist übrigens ein Bug, der nur CentOS 7.6 in Verbindung mit PHP 7.3 betrifft.
Ich verwende bisher DKIM nicht, zumal ich hier seitens Herrn Bradler keine Info über den Support desselbigen gesehen habe.
Auch ohne DKIM kann ich alle Mails an Google zustellen. Voraussetzung ist allerdings, das der Server nicht geblacklistet ist.
Ich empfehle daher, vorher über folgende Adresse zu prüfen, ob der Server irgendwo geblacklistet ist und dann ggfs. diese Problem zu bereinigen:
Hallo,
ich habe aktuell den Fall, das das Passwort eines Users gepwned wurde und unter Verwendung des Roundcube Clients massenhaft Spam-Mail versandt wurde (konkret mit dem roundcube 0.95, welcher in der pd-admin SE Umgebung noch enthalten ist.
Das führt dann in der Regel zu einem raschen Blacklisting und damit natürlich zum Lahmlegen des Servers, weil die "ordentlichen" Mails nicht mehr von den anderen Mailservern angenommen werden. Da man das nie ganz ausschließen kann, möchte ich den Roundcube Client besser absichern.
Hat jemand eine Idee, wie man die roundcube Mail-Konfiguration besser absichern kann?
Ich habe Parameter gesehen für ein Delay des SMTP Versands sowie die Begrenzung der maximalen Anzahl von eMail-Adressen in einer Mail.
Aber vielleicht gibt es ja sinnvollere Methoden? Hat jemand eine Idee?
Hallo,
nach Installation der pd-admin Version 4.60 habe ich unter dem Punkt "Einstellungen" als letzten Eintrag stehen:
Pfad zur .htusers für Kibana-Proxy ....
Was hat es damit auf sich? Habe ich da ein Feature verpasst?
Vielleicht einfach mal den opcache aktivieren:
- in php.ini "zend_extension = opcache.so" eintragen
- falls PHP als FPM läuft, den entsprechenden service in /service mit svc -d FPM-xxxxxx; svc -u FPM-xxxxxx neu starten.
Nur so als schnelle Idee.....
Hallo,
bei der Sichtung des Logfiles zum Cronjob für die Funktion "letsencrypt -all" ist mir aufgefallen, das für diverse Subdomains kein Zertifikat ausgestellt wird.
Hierbei wird immer folgendes protokolliert:
|
Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer None Obtaining a new certificate Performing the following challenges: http-01 challenge for subdomain.domain.de Using the webroot path /opt/pdadmin/etc/ssl-validation for all unmatched domains. Waiting for verification... Cleaning up challenges Failed authorization procedure. subdomain.domain.de (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://subdomain.domain.de/.we…YXr-VOBvsbQyqxuncFh92nV0s: q%!(EXTRA string=<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html ) IMPORTANT NOTES: - The following errors were reported by the server: Domain: subdomain.domain.de Type: unauthorized Detail: Invalid response from http://subdomain.domain.de/.we…YXr-VOBvsbQyqxuncFh92nV0s: q%!(EXTRA string=<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html ) To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. certbot-auto failed############################### |
Bei Prüfung habe ich festgestellt, das diese Domains alle einen Redirect auf eine andere Adresse durchführen (Redirect 301), weil es so vom Kunden konfiguriert wurde.
Aus meiner Sicht dürfte hier entweder:
- gar kein letsencrypt Versuch gemacht werden, da die ggfs. externe Quelle bzw. der andere Pfad kein Anlegen des Challenge Files zuläßt
- oder in dem Container mit dem Redirect müsste auch eine alias-Konfiguration erfolgen, was aber nicht passiert.
Hat jemand anders von euch auch dieses Problem und wenn ja, wie geht ihr damit um?
Was das Ablehnen der Mails betrifft, so hat sich das mittlerweile wohl erledigt, denn die geänderte DNS-Adresse ist durch Replikation wohl endlich bekannt. Das Problem mit den Log-Einträgen hat sich aber nicht gelöst.
Soweit ich es bis jetzt feststellen konnte:
Dieser Log-Eintrag wird jedesmal erzeugt, wenn ich eine eMail an eine .gmail.com Adresse schicke.
So richtig verstehe ich das nicht, denn ich verwende auf meinem Server nur IPv4, weil mein Provider kein IPv6 anbietet.
Folglich erhalte ich bei DNS-Anfragen eigentlich auch immer nur die IPv4 Adressen zurück.
Daher verstehe ich nicht, warum qmail-remote eine Auslieferung an eine IPv6 Adresse versuchen sollte.
Es sei denn, die Information wird im Rahmen des Advertisements vom externen Mailserver angepriesen?!
Vielleicht hat ja einer noch eine Idee ....
Nein, das Verhalten ist nicht normal, denn:
a) in der pdadmin.conf ist für $apache_access_log der Eintrag /usr/local/pd-admin2/logs/access_log gesetzt
b) die httpd_log.pl gibt folgende Ausgabe aus:
Kann Logfile nicht finden. Bitte setzen Sie $apache_access_log
in der Konfigurationsdati /opt/pdadmin/etc/pdadmin.conf at /opt/pdadmin/bin/httpd_log.pl line 118.
Was war das Problem?
Wenn ich in der Oberfläche von pd-admin2 den Wechsel zwischen Apache 2.2 und Apache 2.4 mache, dann wird in der pdadmin.conf NICHT die Variable $apacherestart angepasst. Diese zeigte noch auf /usr/local/pd-admin2/bin/apachectl graceful, es fehlte das httpd-2.4 zwischen pd-admin2 und bin. Dann wird beim Skript-Aufruf zwar die access_log umbenannt, aber der Apache restart wird nicht ausgeführt und folglich das Loggen in die access_log.<timestampe> weiter ausgeführt. Ziemlich blöd, aber wenigstens habe ich es endlich gefunden. Jetzt funktioniert es wie es soll.
Hallo,
ich habe hier ein merkwürdiges Phänomen:
Ich verwende die aktuelle Version der PD-Admin Software sowie die aktuelle Standardumgebung.
Hierbei setze ich Apache 2.4 ein.
Leider erhalte ich keine Statistiken mehr, denn im Verzeichnis /usr/local/pd-admin2/logs ist keine Datei accesss_log mehr.
Vielmehr schreibt er die Logeinträge direkt in die jeweils letzte access_log.<time_stamp> Date, die auch brav immer durchrotiert wird.
Hat jemand eine Idee, wie bzw. wodurch solch ein Verhalten zustande kommen könnte?
Ja, habe ich gemacht.
Nach längerem habe ich zumindest soviel rausgefunden:
Ich habe einen Mail-Account, der per Kopie-an eine Mail auch an eine gmail.com Adresse schickt.
Dieses erfolgt durch die srs-forward.pl Datei. Google hat dies jedoch nicht angenommen, da irgendetwas beim SRS nicht zu passen scheint.
Daraus wurden dann bounce-Mails generiert, die sich dann zu double-bounces mehrfach aufgeschaukelt hatten, so das ich innerhalb kürzester Zeit 16000 Bounce-Mails hatte. Offensichtlich scheint es dann dem qmail irgendwann zuviel zu werden.
Hallo,
ich habe hier einen neu aufgesetzten CentOS 7 Server, auf dem IPv6 auf Kernel-Ebene deaktiviert ist.
Auf den ersten Blick läuft der Server ohne Probleme. Nach einer gewissen Zeit habe ich im Maillog jedoch die folgende Fehlermeldung:
qmail-remote Could not create IPv6 socket
Gleichzeitig werden scheinbar extrem viele Einträge in der queue generiert, so das faktisch der Mail-Service nicht mehr läuft.
Im Internet finde ich hierzu nichts.
Daher meine Fragen:
Ist jemanden dieses Problem bekannt?
Kann man irgendwie qmail-remote beibringen, das es gar keine Möglichkeit gibt, IPv6 auf dem Server zu nutzen (respektive das irgendwo deaktivieren)?
Beste Grüße.
BrowsingMan
Und wie löst ihr das Problem, das auf vServern in der Regel die Quota nur für die gesamte virtuelle Festplatte eingerichtet werden kann?
Die meisten Anbieter virtueller Server erlauben es nicht, Quota z. B. nur für /home einzurichten. Das gibt immer dann Probleme, wenn man für die Kunden die Generierung von Backups einrichtet.
Bei mir bricht das Migrationsskript ab, da ich seinerzeit schon folgendes ausgeführt hatte:
(damals war das glaube ich dovecot 2)
Im Skript ist ja die Zeile
drin
Wie stelle ich denn nun von Dovecot 2 auf Dovecot 2.2 um?
Reicht es aus, folgendes zu tun:
auszuführen oder müssen noch zusätzliche Schritte berücksichtigt werden?
Ich habe auch einige Wildcard-Zertifikate im Einsatz und das Verhalten tritt bei mir genauso auf.
Was für mich auch logisch wäre, denn ich vermute mal das hier einfach der Common Name des Zertifikates mit dem DNS-Namen des Webauftritts gematcht wird.
Sollte das zutreffen, wäre es sinnvoll, die Prüfung im pd-admin abzuändern, da viele Kunden Wildcard-Zertifikate nehmen und über sub-Domains unterschiedliche Inhalte abbilden.
Ich würde im Maillog mal schauen, wohin dieser Mail-Account Mails versendet.
Wenn es viele verschiedene Adressen sind, die teils nur leicht variieren, dann würde ich darauf tippen, das das Passwort des Mail-Acounts von einem Trojaner entwendet wurde und von einem Bot missbraucht wird.
Für diejenigen, welche es interessiert:
Ich habe das von tooliload zur Verfügung gestellte addon bei mir auf einem Server testweise im Einsatz und kann sagen, das dies bereits einen erheblichen Beitrag zur Vermeidung von Ärger geleistet hat.
Konkret hat ein Kunde auf seiner Wordpress Präsenz ein unsicheres Addon verwendet, das vom SteelRat Botnet entsprechend ausgenutzt wurde.
Dank des Addons gingen nur die ersten 50 dieser Mails raus (festgelegtes Limit auf Spam-Erkennung) und über 3700 Mails wurden abgefangen und einfach gedropped.
Vorteile:
1. Server wird gar nicht erst im cbl gelistet
2. Fehlerbereinigung (Identifizierung des Skriptes) ist leichter und kann zudem in Ruhe durchgeführt werden
3. Serverlast bleibt niedrig, da die Mails gar nicht erst in der Queue landen
An dem Grundproblem (Verwendung unsicherer php-Skripte seitens des Kunden) wird das zwar nichts ändern können, aber es ist meiner Meinung doch ein erheblicher Beitrag zur Schadensbegrenzung.