Beiträge von tbc233

Da gabs schon mal was

Binärcode in error_log

Zitat von Twilo

Eine Änderung der eMail-Adresse bei "Zwei-Faktor-Authentisierung (2FA)" hat keine Auswirkung; d.h. die email-Adresse kann NICHT geändert werden.

Ich steh grad am Schlauch.
An welcher Stelle haben wir eine Zwei Faktor Authentifizierung?

Zitat von Twilo

Ist die Frage, ob die Verbindung unverschlüsselt stattfindet, vom Datum her könnte es fast passen …

Was den Zeitpunkt angeht hast Du nicht unrecht, aber Threadstarter sagte ja es war Port 587 eingetragen, ich glaub über den kann man gar keine SSL Verbindung aufbauen.

Zitat von Twilo

Hat es evtl. damit etwas auf sich?

Abgelaufenes Root-Zertifikat entfacht Ärger bzw. AddTrust: Probleme durch abgelaufenes Root-Zertifkat

Dürfte bei Verwendung von Port 587 oder 25 (unverschlüsselt) keine Rolle spielen.

Zitat von monderka

Fatal error: Uncaught RuntimeException: The mail could not be sent, check the debug logs for more information. in /home/hirsedby/www.hirse-paradies.de/admin/gm_send_order.php:323

Diese debug logs von denen hier die Rede ist wären interessant.

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.

Zitat von Twilo

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.

Das schleppen wir seit meinem Thread schon lange mit.

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.

Danke Dir!

Einen Hinweis auf Memory Allocation gibts bei mir allerdings nicht. Aber ich werde es prüfen.

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...

Hmmm, eine libgcc_s.so.1 hab ich eigentlich durchaus auf dem System...

Dankeschön.

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

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

Ich werd mal auf jeden Fall die Stunnel Umstellung machen.

Wenn ich alles richtig verstehe, dürfte diese ja auch bei dem 4-342, auf dem ich jetzt wieder zurück bin, keine Probleme machen. Dann probier ich meine pd-admin2 Ordner nochmal rück- rück-umzubenennen. Vielleicht hat das ja alles doch irgendwie miteinander zu tun.

Zitat von Sumeragi

qmail-smtpd: qmail-smtpd/VC started

bedeutet ja, dass zumindest der Dienst läuft.

Korrekt, das würde ich auch bestätigen weil eingehende Mails soweit funktioniert haben und an die Mailboxen zugestellt wurden.

Zitat von Sumeragi

Ich würde zunäcsht einmal mit telnet (Port 25) bzw. openssl (Port 465) versuchen händisch eine Mail einzuliefern. Dabei muss es dann ja eine Fehlermeldung geben.

Das habe ich probiert als der Zustand bestand, jedenfalls die unverschlüsselte Variante auf Port 25. Der Dialog ging durch bis zum Schluss, wenn auch ohne Auth, weil ich auf die Schnelle nicht wusste wie ich ein smtp-auth in telnet machen kann.

Ganz allgemein funktionierte es nur dann anscheinend nicht, wenn smtp-auth im Spiel war.

Habe den Thread Kein E-Mail Empfang/Versand nach SE-Update erst jetzt bemerkt, prüfe gerade ob der auch auf mich zutreffen könnte (versehentliche Installation eines anderen MTAs kann ich aber in jedem Fall ausschließen)

Edit: Das betroffene System ist tatsächlich nicht auf Stunnel umgestellt. Das werden ich mir mal ansehen, erklärt aber meiner Meinung nach nicht warum es auch unverschlüsselt über Port 25 nicht ging.

Hätte eben einen Server auf 4-534 upgegradet. (vorher 4-0.342).

Danach funktionierte der Versand via SMTP-Auth nicht mehr. Weder unverschlüsselt auf Port 25, noch verschlüsselt auf Port 465. Ich bekam dazu keine Meldungen im mail.log oder sonst wo, es kam einfach nur "qmail-smtpd: qmail-smtpd/VC started" und im Mailclient eine Meldung dass die Verbindung zum SMTP Server verloren ging.

Eingehende Mails die von anderen Server daher kamen, wurden hingegen problemlos in die Mailboxen zugestellt.

Aufgrund leichter Panik und absolut keiner Idee wo zu suchen beginnen ich könnte, habe ich das /usr/local/pd-admin2 Verzeichnis wieder auf die vorige Version rück-umbenannt. Damit geht es nun wieder.
Möchte zu einem späteren Zeitpunkt wenn weniger User online sind die Mail benötigen, dann nochmal weiter rückstellen und schauen.

Allerdings weiterhin unsicher wie ich das debuggen könnte. Jemand eine Idee?