6
Mailserver mit Problem mit Umlauten im Betreff
Mahlzeit!
Ich habe hier einen Endkunden, der von uns Rechnungen per SMTP erhält. Seit kurzem können die Mails nicht mehr zugestellt werden.
Ursache ist ein "ü" im Betreff. Liegt daran, dass das schon seit immer in unserem Firmennamen auftaucht.
Und ja, wenn ich mir die Mail an meine private GMX-Adresse sende und das Postfach dann mit Betterbird ansehe hab ich ein Kodierungsproblem beim ü. Ich geh davon aus, dass da UTF-8 erwartet wird, aber ISO 8859-1 ankommt.
Mir ist halt noch nie untergekommen, dass da ein Mailserver eine Mail zurückweist, wegen falschem Zeichen im Betreff.
Ich weiß auch nicht, was der Kunde da im Einsatz hat. Hat selber eine Firma und eine eigene Maildomain.
Lösung wäre jetzt wohl, dass entweder das ERP die Mail per UTF-8 versendet oder der Mailserver mit ISO 8859-1 klarkommen müsste.
Oder lieg ich da falsch?
k.
Ich habe hier einen Endkunden, der von uns Rechnungen per SMTP erhält. Seit kurzem können die Mails nicht mehr zugestellt werden.
>>> DATA
<<< 550 Subject contains invalid characters.
550 5.0.0 Subject contains invalid characters.Ursache ist ein "ü" im Betreff. Liegt daran, dass das schon seit immer in unserem Firmennamen auftaucht.
Und ja, wenn ich mir die Mail an meine private GMX-Adresse sende und das Postfach dann mit Betterbird ansehe hab ich ein Kodierungsproblem beim ü. Ich geh davon aus, dass da UTF-8 erwartet wird, aber ISO 8859-1 ankommt.
Mir ist halt noch nie untergekommen, dass da ein Mailserver eine Mail zurückweist, wegen falschem Zeichen im Betreff.
Ich weiß auch nicht, was der Kunde da im Einsatz hat. Hat selber eine Firma und eine eigene Maildomain.
Lösung wäre jetzt wohl, dass entweder das ERP die Mail per UTF-8 versendet oder der Mailserver mit ISO 8859-1 klarkommen müsste.
Oder lieg ich da falsch?
k.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 669329
Url: https://administrator.de/contentid/669329
Ausgedruckt am: 23.11.2024 um 09:11 Uhr
6 Kommentare
Neuester Kommentar
Servus!
Der Mailheader erlaubt nach RFC 822 nur printable ASCII (zwischen 33 und 126). Alles andere musst du mit RFC 1342 codieren. Manche Mailserver sind da wohl strenger mit den RFCs.
Kann sein, dass der Mailversand im ERP eventuell "einfach" gestrickt ist und auf solche Details nicht achtet.
Stefan
Der Mailheader erlaubt nach RFC 822 nur printable ASCII (zwischen 33 und 126). Alles andere musst du mit RFC 1342 codieren. Manche Mailserver sind da wohl strenger mit den RFCs.
Kann sein, dass der Mailversand im ERP eventuell "einfach" gestrickt ist und auf solche Details nicht achtet.
Stefan
3
Kenn ich, macht Netcup auch bei ihren Mailservern und ist absolut legitim. Problem ist das deine Umlaute nicht nach RFC korrekt mittels Quoted-Printable oder Base64 encodiert werden.
Da wird 100% der Mail-Client dran schuld sein, viele einfach gestrickte Clients oder vielfach auch PHP Skripte die die mail() Funktion nutzen denken nicht daran das Subject richtig zu kodieren wenn da non ASCII Zeichnen drin vorkommen, und dann beschwert sich eben so manch strikterer Mailserver darüber.
Gruß catrell
Da wird 100% der Mail-Client dran schuld sein, viele einfach gestrickte Clients oder vielfach auch PHP Skripte die die mail() Funktion nutzen denken nicht daran das Subject richtig zu kodieren wenn da non ASCII Zeichnen drin vorkommen, und dann beschwert sich eben so manch strikterer Mailserver darüber.
Gruß catrell
1
Man möchte es nicht glauben, aber AldiTalk versendet ebenfalls solche nicht RFC konformen Mails wenn man seine E-Mailadresse bestätigen lassen will. Ist man dann bei einem solchen Provider bekommt man diese Mails erst gar nicht.
Habe ich schon mehrfach dem Support gemeldet, hat sich aber nie was getan, da erreicht man einfach niemand kompetenten der versteht was man meint, Discounter halt.
Habe ich schon mehrfach dem Support gemeldet, hat sich aber nie was getan, da erreicht man einfach niemand kompetenten der versteht was man meint, Discounter halt.
1
Ah, oke...Dann muss ich da mal mit den ERP-Leuten reden.
Zitat von @kpunkt:
Lösung wäre jetzt wohl, dass entweder das ERP die Mail per UTF-8 versendet oder der Mailserver mit ISO 8859-1 klarkommen müsste.
Die Zahl der MTAs, die tatsächlich SMTPUTF8 verstehen, dürfte verschwindend gering sein.
Moin,
Einfach beim Sender auf RFC-Konformität achten. Dann tut das auch.
lks
Einfach beim Sender auf RFC-Konformität achten. Dann tut das auch.
lks
1
