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