Kann man die Konfiguration dieses Abbruch möglicherweise dem Nutzer überlassen?
Also das man selbst entscheiden kann, wieviele gescheiterte Mailversande toleriert werden.
Zum Hintergrund: Wir verschicken täglich per MailSendSMTP eine Bestandsliste an knapp 150 Mailadressen. Jetzt ist der Server eines Kunden grad offline und natürlich werden 4 Mitarbeiter bei dem Kunden mit der Bestandsliste versorgt.
Ich muss nun die betroffenen Adressen entfernen, den Flow neu starten und anschließend die Adressen wieder hinzufügen. Wenn die Serverprobleme beim Kunden morgen nicht behoben sind, kann ich das ganze dann nochmal machen.
Viel schöner wäre, wenn ich die Grenze für den Abbruch selbst unter Kontrolle hätte und dem Step einfach sage, dass er selbst nach 20 gescheiterten Mails noch mit Warnung fortfahren soll.
Für mich ist das grade beim MailSendSMTP relevant, aber für den normalen MailSend-Step ist es bestimmt auch interessant.
Wir schauen uns das mal an. Hast du zufällig eine Liste (wenn auch unvollständig) von Fehlermeldungen? Anders gefragt: ist es immer „Domain not found“ oder auch mal was anderes?
Ok danke. Wir haben das intern als Ticket angelegt und schauen mal wie wir das angehen.
Aus dem Bauch heraus tendieren wir dazu exakt diesen konkreten Fehler zu ignorieren und die betroffenen Email-Adressen als Warnung auszugeben.
Okay. Das wird dann von euch „hard coded“, richtig?
Ich glaube, ich bin bei eigentlich allen anderen Übertragungsfehlern auch mit einer Warnung zufrieden. Sowas wie die errorBehavior-Option beim FTPUpload-Step ist nicht einfach umsetzbar?
Ja, so der erste Gedanke. Evtl. noch für ein paar weitere Fehler die den Empfänger betreffen.
Wir müssen das mal noch etwas genauer untersuchen. Dieser Fehler bei dir scheint der häufigste zu sein. Es gibt noch ein paar weitere den Empfänger betreffende Fehlercodes.
Alles andere deutet auf ein (Konfigurations-) Problem mit dem Mailserver oder der Verbindung hin und da wäre ein schneller „fail fast“ Abbruch (aus unserer Sicht) besser (kann man sicher auch diskutieren).
Theoretisch ja.
Wenn z.B. euer SMTP-Server gerade nicht erreichbar ist und in einen Timeout läuft, dann wäre es irgendwie schlecht 100 weitere mal zu probieren und ggf. immer wieder in den Timeout zu laufen. D.h. man müsste nach den Fehlerarten unterscheiden.
Stimmt. Wenn der sendende Server nicht erreichbar ist, ist das natürlich nochmal was anderes.
Wobei auch hier die Möglichkeit, mit einer Warnung fortzufahren, von Vorteil ist. Im Beispiel von oben schicken wir die Bestände auch per FTP an manche Kunden. Die FTPUpload im Flow sollte im besten Fall dennoch ausführen werden, auch wenn unser SMTP-Server unerreichbar ist.
Das ist aber nicht wirklich unsere Hauptproblem. Wenn unsere SMTP-Server wegen Wartungen o.ä. nicht erreichbar ist, sind wir ja in den meisten Fällen vorgewarnt und können den Flow entsprechend anpassen.
Ich dachte jetzt hauptsächlich an Fehler auf Seite des empfangenden Servers. Da die Mail ja an Dutzende verschiedene Kunden bzw. Mailserver rausgeht, kommt es hier schon mal häufiger vor, dass der ein oder andere Mailversand scheitert.
Ok, wir werden jetzt eine kleine Verbesserung einbauen. Diese geht aber erst in den nächsten Tagen live. Wir sagen Bescheid.
Und zwar ignorieren wir jetzt alleSendFailedException. Darunter fallen die ganzen SMTP 45X und 55X Fehler, worunter auch „Domain not found“ von oben fällt. Damit sollten wir die meisten Fehler dieser Art erwischen.
Für alle anderen Fehler, belassen wir unser bisheriges Limit. Das sollten dann Fehler wie „Connection refused“, „Timeout“ usw. sein.
Wir beobachten dann erstmal wie es sich damit verhält. Du kannst gern Feedback geben, falls noch etwas durchrutscht.
zu SMTP Fehlercodes...
Diese ganzen SMTP-Fehlercodes scheinen leider von verschiedenen Mailservern nicht immer konsistent verwendet zu werden. Wir waren z.B. nicht in der Lage diesen Fehler von dir zu reproduzieren…egal wie nicht existent unsere Empfängeradresse war. Deswegen müssen wir jetzt erstmal schauen, ob unser jetziger Ansatz alles erwischt.
