Umlaute in Dateinamen kaputt bei EmailSend aus CSVWriter

Hallo,

mein Flow SH_refillWerbetueten muss irgendwann zwischen dem 6ten und dem 13ten Januar kaputt gegangen sein. Ich habe nichts bewusst geändert.

Ich schreibe dort (an zwei Stellen jeweils) eine CSV-Datei und verschickt die (separat) per EmailSend.

Dateiname ist

SH_Werbetüten_Großpack-nachbestellen_${current_timestamp!?string("yyyy-MM-dd hh-mm")}.csv

bzw

SH_Werbetüten_Einzel-auffüllen_${current_timestamp!?string("yyyy-MM-dd hh-mm")}.csv

Die Mails gehen egtl direkt an Monday.com um da ein Todo anzulegen. Dort kommen sie aber als "attachment-1" (ohne Dateiendung) an.

Zur Gegenprüfung hab ich die Mail gerade mal an mich selbst gesendet. Dort ist der Dateiname ein anderer, aber auch nicht korrekt:

= UTF-8 Q SH=5FWerbet=C3=BCten=5FEinzel-auff = = UTF-8 Q =C3_ ; filename 1=_ =BCllen=5F2021-01-25_04-07.csv =

Jetzt habe ich die Umlaute aus den Dateinamen entfernt, und so geht es.

Ich bin mir aber sicher, dass es davor auch mit Umlauten ging:

![image](upload://s38QSyPUkhtiL0Zfg5hGpYfpYm0.png "image")


Könnt ihr das wieder ermöglichen?

Danke Daniel

Fix ist in Arbeit.

Kannst du bitte mal testen? Wir haben einen Hotfix deployed. Hing mit einem Versionsupgrade einer Lib zusammen.

Ne, kommen immer noch gleich benannt an....

Sorry da ist etwas schief gelaufen...

Bitte nochmal. Danke.

Jetzt, ja: tut.

Vielen Dank für den schnellen Fix, Grüße Daniel

Ich hab noch einen!

Emails mit Emoji im Titel rufen ein seltsames Fehlverhalten hervor. Super simpler Flow:

image

Der Betreff hat zwei mal dieses Emoji drin, ganz am Anfang und ganz am Ende.
In der Vorschau sieht alles super aus. Der Durchlauf wirft dann aber einen (leeren) Fehler, wobei unten im Log alles gut aussieht. Nur: die Email kommt nie an.

image

image


Sobald ich die Emoji im Betreff entferne, klappt alles wie erwartet.

Klingt zwar ähnlich aber Emojis im EmailSend gingen leider noch nie.
Das ist leider nicht so schnell im Code zu beheben, sonder erfordert eine Datenbankanpassung (charset) einer relativ großen Tabelle. D.h. das müssen wir in einer der nächsten geplanten Wartungsfenster machen. Wir haben das mit auf die TODO-Liste gepackt. Können noch nicht versprechen, wann genau.


Evtl. würde es im EmailSendSMTP gehen. Der muss (aktuell) nichts in unserer DB zwischen speichern, sondern geht direkt auf euren eigenen SMTP. Der sollte dadurch das Problem nicht haben.

Ich habe hier auch noch ein Problem, und zwar beim Senden einer Excel-Datei. Ich habe es eben nachgestellt. Wenn ich mir eine Datei namens "Stüp18.xlsx" schicke, kommt folgendes an:


image

Nenne ich sie "Step18.xlsx", ist alles korrekt:



image

Es liegt hier offenbar auch am Umlaut (und auch hier: Ging früher problemlos)


Gruß Micha


Kannst du uns diese Stüp18.xlsx mal per Ticket zur Verfügung stellen?

@Micha:

Gerade mal versucht nachzustellen.
Im GMail kommt das korrekt an.



Im Quellcode der Mail steht:


------=_Part_2531_843875428.1611676074080
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Test
------=_Part_2531_843875428.1611676074080
Content-Type: application/octet-stream; name="Stüp18.xlsx"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Stüp18.xlsx"


Hast du die Möglichkeit, dir den Quellcode der Mail anzuschauen, was da bei dir steht?

Also, bei diesem dat-Anhang (also eigentlich Stüp18.xlsx) steht:


Message-ID: <167163972.2324.1611672774270@app05.de.apps.synesty.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0109_01D6F405.E15A3E90"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGf3eutaZsx96lPTLCiu5ACxVQB5w==


Bei demselben Inhalt, aber als Step18.xlsx gespeichert und versendet, steht aber dasselbe, soweit ich das beurteilen kann:


Message-ID: <236391878.2326.1611672824283@app05.de.apps.synesty.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0101_01D6F405.E1488B50"
X-Mailer: Microsoft Outlook 16.0



> Wir haben das mit auf die TODO-Liste gepackt. Können noch nicht versprechen, wann genau.

Ja, eilt auch nicht wirklich... Was mich primär verwirrt hat war der nicht-Fehler, bzw dass das Log gut aussah, aber dann nichts ankam. Vllt könnt ihr den ja aussagekräftiger machen (oder schon bei Eingabe warnen)


Grüße Daniel

@Daniel: Ja da hast du recht. Wir schauen mal dass wir den Fehler besser abfangen.

@Micha:

Kannst du in deinem Email-Quellcode mal noch schauen, ob du irgendwo die Stelle findest, wo der Dateiname auftaucht? Die Stelle von dir sieht ein wenig anders aus, als die von uns.

Müsste eigentlich unter dem Teil kommen, den du gepostet hast.


Auffällig ist der X-Mailer Header bei dir:

X-Mailer: Microsoft Outlook 16.0


Der kommt nicht von uns und wenn wir die Nachricht bei uns anschauen, dann ist da kein X-Mailer und kein Microsoft Outlook 16.0.

Das legt die Vermutung nahe, dass da irgendwie dein Outlook auch noch irgendwie dazwischen klemmt.

Wie sieht das ganze im Web-Mail bei dir aus?


Kannst du ausserdem sagen, wie groß deine Excel ungefähr war? Bei uns war es nur eine kleine Testdatei.

Und um ganz sicher zu gehen: Du redest vom EmailSend Step richtig? Oder vom EmailSendSMTP?




Genau, EmailSend. Die Datei war auch sehr klein. Und wie gesagt: Der Inhalt der beiden Dateien war ja derselbe, nur der Name einmal mit und einmal ohne Umlaut. Im Web Mail sehen bei beiden die Anhänge korrekt aus. Ich werde mir die Mail mal an einen anderen Mailaccount schicken, um zu sehen, ob das ggf. was mit meinem Mail Provider zu tun hat.

Update: Egal an welche Mailadresse, in Outlook kommt immer .dat an. Aber ich hab was anderes probiert: IIch hab mir nämlich selber Mails geschickt mit Umlauten in Namen, und die kommen überall komplett sauber an:


image


Wie man sieht, ist auch hier der Content-Type multipart/mixed, der Dateiname taucht nirgends auf. Nach allem was ich bisher sehe, sind nur Mailanhänge betroffen, die über euren EmailSend-Step versendet werden. Ich hab da auch noch weitere Tests gemacht mit allen drei auswählbaren mime types, überall dasselbe

Danke für die Infos.

Von wo aus hast du dir selbst Mails geschickt?


Dein Screenshot zeigt leider nicht alle Header - Das muss mindest eine A4 Seite lang sein. Keine Ahnung, ob Outlook das kann. Im Zweifel mal Gmail probieren da geht das über

Es sollte folgendes enthalten:


------=_Part_3504_1730425637.1611687154079
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Test
------=_Part_3504_1730425637.1611687154079
Content-Type: application/octet-stream; name*=UTF-8''St%C3%BCp18.xlsx
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename*=UTF-8''St%C3%BCp18.xlsx


Am Ende sieht man auch den Dateinamen encoded gemäß dem aktuellen RFC 2231.

Unser EmailSend sendet Mails gemäß RFC 2231.


Es scheint als hat Outlook generell Probleme mit diesem RFC2231, siehe hier und hier.



Hier findet man einen relativ aktuellen Hinweis auf einen Fix (mal nach RFC2231 suchen).




@Daniel wegen Emojis: Wir haben einen Fix deployed der die Emojis im Betreff erstmal entfernt. Ist nicht schön, aber besser als eine nicht gesendete Mail mit seltsamer Fehlermeldung.

Wir haben das Thema auf dem Schirm, ist allerdings aufwändiger.