SMTP-Probleme, nachdem erste Mail fehlschlägt

  • Anlehnend an Mailbox E-Mail-Validierung fehlerhaft? ist mir gestern beim E-Mail-Versand ein Problem aufgefallen. Ich bin mir nicht sicher, ob dies ein Bug im WSC ist oder ein Fehler vom Mailserver (Hoster: all-inkl).

    Ausgangssituation: In einem Script habe ich 100 E-Mails versendet. Versendet wurden diese in einer Schleife und direkt synchron über

    Code
    foreach ($email->getJobs() as $job) {
        BackgroundQueueHandler::getInstance()->performJob($job);
    }

    abgeschickt.

    Problem war dann, dass die 5. E-Mail-Adresse in der Schleife fehlerhaft war (siehe Mailbox E-Mail-Validierung fehlerhaft?). Dadurch gab es nicht nur bei dieser E-Mail Probleme, sondern auch bei allen 95 darauffolgenden. Die Probleme haben sich so widergespiegelt, dass jede Email ca. 1 Minute für den Versand benötigt hat (das Script lief also ca. 60 Minuten) und diese dann auch nicht direkt versendet wurde, sondern temporär erst ein TransientFailure für jede der 95 E-Mails entstand. Nach 15 Minuten wurden diese dann durch den BackgroundQueueHandler doch noch versandt.

    Um das Ganze nun nachzubilden, habe ich folgenden Script gebaut:

    Die Ausgabe ist folgende:

    shouldwork1@example.com und shouldwork2@example.com erhalten also auch Fehler vom Mailserver, wieso weiß ich nicht. Wird hier die Mailserver-Antwort von bug@example.com vom WSC falsch verarbeitet und dadurch entstehen Folgefehler oder ist das ganze ein Bug im Mailserver?

    Beste Grüße

  • Christopher Walz 17. August 2022 um 06:44

    Hat den Titel des Themas von „SMPT-Probleme, nachdem eine Mail fehlschlägt“ zu „SMPT-Probleme, nachdem erste Mail fehlschlägt“ geändert.
    • Offizieller Beitrag

    Hallo,

    eine erste Vermutung: Häufig setzen diese Anbieter ein Limit für die Anzahl der versendeten E-Mails pro Zeiteinheit. Wie sich die Systeme nach erreichen des Limits verhalten, ist uns nicht im Detail bekannt. Eventuell kann eine Nachfrage beim Anbieter hier Klarheit schaffen?

  • Ich habe mal noch etwas Logging betrieben (in SmtpEmailTransport::deliver und SmtpEmailTransport::read). Log beginnt ab dem Versand zu bug@example.com (Format ist \time(): Message).

    all-inkl-Mailserver:

    Code
    1660785772: RCPT TO: bug@example.com
    1660785772: 501 5.1.3 Bad recipient address syntax
    1660785772: RSET: shouldwork1@example.com
    1660785772: 502 5.5.2 Error: command not recognized
    1660785772: RSET: shouldwork2@example.com
    1660785776: 250 2.0.0 Ok
    1660785780: 250 2.0.0 Ok
    1660785780: RCPT TO: shouldwork2@example.com
    1660785784: 250 2.1.0 Ok
    1660785788: 250 2.1.5 Ok

    Gmail:

    Code
    1660786776: RCPT TO: bug@example.com
    1660786776: 555 5.5.2 Syntax error. p185-20020a6229c2000000b0052d748498edsm202284pfp.13 - gsmtp
    1660786776: RSET: shouldwork1@example.com
    1660786776: 502 5.5.1 Unrecognized command. p185-20020a6229c2000000b0052d748498edsm202284pfp.13 - gsmtp
    1660786776: RSET: shouldwork2@example.com
    1660786776: 250 2.1.5 Flushed p185-20020a6229c2000000b0052d748498edsm202284pfp.13 - gsmtp
    1660786776: 250 2.1.5 Flushed p185-20020a6229c2000000b0052d748498edsm202284pfp.13 - gsmtp
    1660786776: RCPT TO: shouldwork2@example.com
    1660786776: 250 2.1.0 OK p185-20020a6229c2000000b0052d748498edsm202284pfp.13 - gsmtp
    1660786776: 250 2.1.5 OK p185-20020a6229c2000000b0052d748498edsm202284pfp.13 - gsmtp

    Der Log sieht also bei beiden gleich aus. Ich kann mir also nicht vorstellen, dass das ein Fehler in beiden Mailservern ist. Vielleicht weiß Tim Düsterhus ja mehr.


    Grüße

    • Offizieller Beitrag

    Hallo,

    Wird hier die Mailserver-Antwort von bug@example.com vom WSC falsch verarbeitet und dadurch entstehen Folgefehler oder ist das ganze ein Bug im Mailserver?

    Ein bisschen von beidem vermutlich. Durch die Newline wird das RCPT TO vorab „beendet“ (was dann die Exception wirft, weil ungültig). Das abschließende und bereits gesendete > wird dann als Beginn der nächsten Transaktion interpretiert und macht dadurch das RSET kaputt. Bei der dritten E-Mail sollte es nach meinem Verständnis dann aber passen, weil nichts mehr im Buffer sein sollte und das RSET dann Wirkung zeigt.

    Anyway: Kannst du mir bei deinem All-Inkl-Webspace bitte ein SMTP-Konto einrichten und ein „vorausgefülltes“ Test-Skript mit Zugangsdaten geben (gerne per Ticket oder Konversation), damit ich es mit exakt dem All-Inkl-Mailserver testen kann? Deine Beispielausgabe ist in der Form leider nicht hilfreich, da mir nicht klar ist, wie genau der Logging-Code aussieht. Beim RCPT TO fehlen beispielsweise die <>.

  • Tim Düsterhus 29. August 2022 um 10:48

    Hat das Label Bestätigt hinzugefügt.
  • Tim Düsterhus 29. August 2022 um 10:49

    Hat den Titel des Themas von „SMPT-Probleme, nachdem erste Mail fehlschlägt“ zu „SMTP-Probleme, nachdem erste Mail fehlschlägt“ geändert.
    • Offizieller Beitrag

    Hallo,

    relevant ist der Mailserver, der im ACP eingetragen ist (d.h. der der in dem SmtpEmailTransport hinterlegt ist). Mit allen anderen Mailservern hat die Software nichts zu tun. Deswegen auch die Bitte um Zugangsdaten für ein Testkonto, damit ich es mit realistischen Daten testen kann, ohne mir selbst ein komplettes System (Postfix, Exim oder gar ganz was anderes?) aufbauen zu müssen.

    Die Zugangsdaten werden selbstverständlich vertraulich behandelt und etwaige E-Mails nur an von uns kontrollierte E-Mail-Adressen versendet.

    • Offizieller Beitrag

    Hallo,

    … die Background-Queue macht genau das was sie soll: Es ist keine E-Mail verloren gegangen.

    hier muss ich mich korrigieren: In meinen Tests hat der Bug dafür gesorgt, dass mindestens eine E-Mail verloren gegangen ist. Konkret wird die E-Mail unmittelbar nach der fehlerhaften E-Mail auch zu einem „Endgültig fehlgeschlagen“.

    Vielen Dank an Christopher Walz für die Zugangsdaten, ich konnte den Fehler wie beschrieben reproduzieren.

    Das abschließende und bereits gesendete > wird dann als Beginn der nächsten Transaktion interpretiert und macht dadurch das RSET kaputt.

    Diese Vermutung war nicht komplett richtig: Das > wird selbst bereits von einer Newline abgeschlossen und ist daher nicht der Beginn der nächsten Transaktion (>RSET), sondern ein vollständig alleinstehender Befehl (>). Entsprechend desynced die Verbindung tatsächlich vollständig, weil ein zusätzlicher Befehl eingefügt wird und nicht nur ein Befehl verändert.

    Die Korrektur ist hier:

    Detect possible SMTP connection desync in SmtpEmailTransport by TimWolla · Pull Request #4981 · WoltLab/WCF
    see https://www.woltlab.com/community/thread/296850-smtp-probleme-nachdem-erste-mail-fehlschl%C3%A4gt/
    github.com
  • Tim Düsterhus 5. September 2022 um 11:49

    Hat das Label 5.5.5 hinzugefügt.
  • Tim Düsterhus 5. September 2022 um 11:49

    Hat das Label von Bestätigt auf Behoben geändert.
  • Marcel Werk 5. September 2022 um 12:02

    Hat das Label 5.4.23 hinzugefügt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!