SMTP Versand bei 4-354 funktioniert nicht

    • Offizieller Beitrag

    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?

    • Offizieller Beitrag

    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.

  • qmail-smtpd: qmail-smtpd/VC started


    bedeutet ja, dass zumindest der Dienst läuft. Ohne konkrete Fehlermeldung ist es natürlich schwierig etwas dazu zu sagen. 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.

    • Offizieller Beitrag

    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.



    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.

    • Offizieller Beitrag

    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.

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

    Ohne smtp-auth wird es eine "normale" Mail-Zustellung sein, wie von anderen Mail-Servern auch. Diese Anleitung halte ich für sehr hilfreich: https://www.stevenrombauts.be/…p-with-telnet-or-openssl/

    • Offizieller Beitrag

    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
    • Offizieller Beitrag

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

    • Offizieller Beitrag

    Ich muss das Thema nochmal aufgreifen, langsam verzweifle ich etwas.


    Ich habe auf den betroffenen Systemen nun nochmal einen Versuch gewagt mit Update auf SE 0.369 (4) und pd-admin 4.70. Danach wieder kein Mailversand möglich. Meldung im Syslog


    Code
    smtpd: 1605751813.541401 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::m$
    smtpd: 1605751813.541428  at (eval 5) line 3
    smtpd: 1605751813.541434 Compilation failed in require at (eval 5) line 3.
    smtpd: 1605751813.541442 Perhaps a required shared library or dll isn't installed where expected
    smtpd: 1605751813.541449  at /usr/local/pd-admin2/bin/checksmtppasswd line 16
    smtpd: 1605751813.716765 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::m$
    smtpd: 1605751813.716799  at (eval 5) line 3
    smtpd: 1605751813.716805 Compilation failed in require at (eval 5) line 3.
    smtpd: 1605751813.716810 Perhaps a required shared library or dll isn't installed where expected
    smtpd: 1605751813.716815  at /usr/local/pd-admin2/bin/checksmtppasswd line 16


    Spannend ist hier, dass diese Probleme anscheinend nur beim Absetzen von Mails (mit SMTP-Auth) auf dem Port 25 auftreten. Testmails von mir auf Port 465 (mit SSL) haben jederzeit funktioniert. Ebenso hat die reguläre Mail Einlieferung auf Port 25 stets funktioniert.


    Nach einem Rück-Umbenennen des pd-admin2 Verzeichnisses auf die Version vor dem Update funktionierte alles wieder. Allerdings natürlich sehr unsauber, da nun wieder die alte Serverumgebung mit dem nagelnauen pd-admin läuft. Ich befürchte hier Side-Effects im Betrieb mit dieser Kombination.


    Die eingesetzte Distri ist Gentoo. Mir ist klar, dass dies eher exotisch ist, andererseits setze ich seit 18 Jahren immer wieder mal pd-admin mit Gentoo ein und hatte vorher noch nie Probleme. Auch diese beiden betroffenen Systeme liefen vorher 3-4 Jahre stabil mit pd-admin.


    Ich wäre hier sehr froh eine Lösung zu finden. Mir bliebe sonst nichts anderes übrig als diese beiden Server auf eine andere Distri zu migrieren (weil auf meinen Centos Servern habe ich dieses Problem nicht), das wäre natürlich ein sehr hoher Aufwand.


    Danke vorab für jeden Input.

    • Offizieller Beitrag

    Ich habe jetzt gesehen dass auf dem betroffenen System im qmail-smtpd/run ein Softlimit von nur 50000000 drin ist. Andere (neuere) pd-admin Server haben hier 125000000. Also mehr als das Doppelte.


    Ich werde mal versuchen diesen Wert anzupassen und dann wieder das neue /usr/local/pd-admin2 Verzeichnis in Stellung zu bringen. Da warte ich aber noch etwas bis sich die betroffenen User wieder beruhigt haben.

    • Offizieller Beitrag

    Habe nun das Softlimit des unverschlüsselten smtpd auf 125000000 erhöht. Es scheint als wären die Probleme damit vom Tisch, ich beobachte weiter. In Summe würde das alles Sinn ergeben, auch die Tatsache dass es während der problematischen Phases auf Port 465 funktioniert hat (weil dort lauscht ja stunnel ohne Softlimit in diesem Sinne).