Beiträge von tbc233

    Weiters den ipv6 Support verbessern. Ich weiß nicht ob sich hier was getan hat, aber momentan tut man sich nichts gutes, wenn man für den Hauptservernamen einen AAAA Record hinterlegt. Es führt dazu dass Leute die per ipv6 daher kommen, nicht auf die pdadmin Oberfläche kommen.

    Ich hätte mal mit viel Hingabe alles in der apache Konfig (respektive template) adaptiert damit das funktioniert, nur um dann festzustellen dass die ipv6 Besucher einen Lizenzfehler bekommen beim pd-admin einloggen.

    Den Auslieferungszustand und/oder die Installationsroutine verbessern.

    Ich muss irgendwie bei einer Installation immer noch sehr viel manuell machen. Manche Dinge mach ich vielleicht obwohl sie gar nicht mehr nötig sind? Dinge wie


    - dc-install.sh durchlaufen lassen, damit ich SSL auf den Maildiensten habe

    - Cronjob anlegen damit mir das Verzeichnis /opt/pdadmin/tmp/top/ nicht vollläuft (hier gab es schon Fälle wo den Leuten die inodes ausgingen)

    - Cronjob anlegen damit mir /var/log nicht mit xferlog Dateien übergeht

    - fail2ban installieren (ohne fail2ban auf den Mailports betreibe ich keinen Server mehr - wäre genial wenn man das in die Umgebung intergieren könnte)

    - $pop3_alt_login_field = 'email'; in pdadmin.conf einfügen. Bin unsicher ob das noch nötig ist aber ich glaube es ist nötig damit die Leute sich mit der E-Mail Adresse authentifizieren können

    - Squirrelmail mittels htaccess sperren (das Ding sollte wirklich nicht mehr zugänglich sein)

    Naja, Du könntest dem problematischen Empfänger ein Mail schicken und dabei das maillog beobachten. Dann musst Du nicht die 7 Tage warten. Bitte wie gesagt aber daran denken dass qmail meines Wissens nach nach dem Anlegen dieser Datei neu gestartet werden muss.


    Der Fehler an sich ist seit Jahrzehnten in der qmail Szene bekannt. Der 1er sorgt dafür dass qmail mit den DNS einträgen umgeht, die es fälschlicherweise für falsch hält - lange geschichte. Wenn meine Diagnose stimmt, sollte das Mail damit nun raus gehen.


    Ich würde es übrigens gut finden wenn die Serverumgebung mit diesem Wert ausgeliefert wird. Mir würde nichts einfallen was da dagegen spricht.

    Man sollte hier nicht unerwähnt lassen dass die Geschichte von qmail und den CNAME Fehlern eine Geschichte voller Missverständnisse ist. Beim rumgooglen kann man Tage damit verbringen. Der Fehler kommt nämlich zum Beispiel auch wenn die DNS Antwort zu lang für qmail ist.


    Die Serverumgebung hat hier vor einiger Zeit dankenswerterweise den ignorewronganswer Switch integriert.


    Steht bei Dir eine 1 in der Datei /var/qmail/control/ignorewronganswer ? Wenn nein, leg die Datei an und mach eine 1 rein. Starte dann die Dienste neu und probiere es erneut.

    Das hat nichts mit Deinen SSL Zertis zu tun, hier wird über das Zertifikat von database.clamav.net gemeckert.


    Bei einem Test auf einem meiner Server konnte ich das Problem jetzt nicht nachvollziehen. Bist Du mit der Serverumgebung soweit halbwegs up to date?

    Eventuell statt localhost mal 127.0.0.1 versuchen. Port mal 25 statt 587 probieren.


    Wenn das alles keine neuen Erkentnisse bringt, würde ich nicht länger nach dem Fehler suchen, sondern die Transportmethode von smtp auf den sendmail Befehl oder php-mail() umstellen, Gambio kann das soweit ich mich erinner.

    Der Cron Eintrag ci_dhe_params.sh ruft das Skript /usr/local/pd-admin2/share/mkdhparams auf, welches den Fehler bringt, dass /usr/local/bin/certtool nicht existiert.
    Warum lautet die IF-Bedingung 'test "gnutls" = "openssl"', welches nie Wahr sein kann
    Warum wird sich darauf verlassen, dass es /usr/local/bin/certtool gibt?

    Bei mir kommen jetzt auch Mails vom cron aufgrund des regelmäßigen Aufrufs von /usr/local/pd-admin2/share/mkdhparams und der Ausgabe dass es /usr/local/bin/certtool nicht gibt. Ich bin mir ziemlich sicher dass dieses Script vorher jahrelang problemlos durchgelaufen ist.


    Bin jetzt unsicher was der genaue Impact davon ist, dass das Script abbricht und ob ich certtool über die lokale Paketverwaltung installieren soll.

    Sieht mir bisher nach einem ganz normalen Spamversand unter Nutzung einer Deiner Domains aus. Tendentiell sieht es derzeit so aus als wäre das nicht über Deinen Server gelaufen.

    Durch sowas muss jeder der eine Domain hat alle Zeitlang mal durch. Sehr lästig, keine Frage. Ein SPF Record für die Domain kann ein bisschen helfen, führt er doch dazu dass viele Mailserver das ursprüngliche gefälschte-Absender Mail erst gar nicht annehmen.

    Erwähnenswert ist vielleicht diese Geschichte unter "Mitigation"

    Zitat
    Code
    qmail can be protected against the RCE (Remote Code Execution) by
    configuring the file "control/databytes", which contains the maximum
    size of a mail message (this file does not exist by default, and qmail
    is therefore remotely exploitable in its default configuration).


    Im databytes File wird ja ganz allgemein die maximale Größe einer Nachricht definiert, die qmail annimmt. Im Auslieferungszustand existiert diese Datei nicht. Das heißt, selbst ein 20GB Mail würde angenommen werden. Diese Datei sollte man daher meiner Meinung nach ohnehin anlegen um zu vermeiden dass irgendein Spezialist ein riesen Mail spoolt. Ein Punkt, den wir pd-admin Freunde tendentiell ohnehin etwas verschnachlässigen.

    Ich habe mir https://www.qualys.com/2020/05…-code-execution-qmail.txt mal angesehen. Mit meinem qmail Halbwissen find ich es etwas komisch.


    qmail-smtpd sind mal ziemlich sicher speichermäßig begrenzt aufgrund der tcpserver Aufrufe mit softlimit. Nun meinen die Entdecker dieser Lücke, dass auch qmail-local davon betroffen ist. Das ist ja eigentlich nur das Tool das die Nachrichten lokal zustellt. Ich persönlich denke nicht, dass es im pd-admin Setup speichermäßig begrenzt ist, andererseits ist mir derzeit nicht klar, wie jemand qmail-local so viel Speicher zumuten könnte.

    Okay, /usr/local/pd-admin2/bin/checksmtppasswd ist ja in Wirklichkeit ein Link auf /bin/checksmtppasswd. Das hat bei mir einen Zeitstempel von heute, stammt also aus dem SE Paket und blieb auch dort trotz meines Downgrades. Es muss also wohl eher ein Zusammenhang mit dem in der Fehlermeldung bemängelten mysql.so oder dynaloader.pm sein...

    Dankeschön.


    Jetzt habe ich doch was im syslog aus dem betroffenne Zeitraum gefunden:


    Code
    Apr 30 10:11:40 smtpd: 1588234300.875797 install_driver(mysql) failed: Can't load '/usr/local/pd-admin2/lib/perl5/site_perl/5.10.1/x86_64-linux/auto/DBD/mysql/mysql.so' for module DBD::mysql: libgcc_s.so.1: failed to map segment from shared object at /usr/local/pd-admin2/lib/perl5/5.10.1/x86_64-linux/DynaLoader.pm line 200.
    Apr 30 10:11:40 smtpd: 1588234300.875844 at (eval 5) line 3
    Apr 30 10:11:40 smtpd: 1588234300.875858 Compilation failed in require at (eval 5) line 3.
    Apr 30 10:11:40 smtpd: 1588234300.875871 Perhaps a required shared library or dll isn't installed where expected
    Apr 30 10:11:40 smtpd: 1588234300.876091 at /usr/local/pd-admin2/bin/checksmtppasswd line 16