Mailer: Encoding der Namen von Dateianhängen gefixt
authorMoritz Bunkus <m.bunkus@linet-services.de>
Wed, 5 Jun 2019 15:02:47 +0000 (17:02 +0200)
committerMoritz Bunkus <m.bunkus@linet-services.de>
Wed, 5 Jun 2019 15:13:13 +0000 (17:13 +0200)
commitbbb2383f64acde4451b241c200600e4bb33a9030
tree733357bdcdb275eee9abc24afeb3f19f8ba42651
parentab7c51c13324db5af2f7c6a3856f41f742c6c8d6
Mailer: Encoding der Namen von Dateianhängen gefixt

Email::MIME encodiert den Dateinamen, der im »Content-Disposition«-
Header enthalten ist, nicht selber. Daher muss der Aufrufer das
tun. Andernfalls kann es bei Nicht-ASCII-Zeichen dann dazu kommen,
dass das empfangene Mail-Programm diese in einem anderen Zeichensatz
interpretiert (z.B. ISO-8859-1), obwohl wir immer UTF-8 senden. Ein
Halleluja für Legacy-Standards.

Weiterhin gibt es einen subtilen Bug in Email::MIME. Eigentlich steht
der Dateiname ja bereits im »attributes«-Hash, das an
»Email::MIME->create()« übergeben wird. Hier könnte man den Dateinamen
schon encodiert reinschreiben.

Das funktioniert auch — aber nur manchmal. Intern scheint das Modul
über die Hash-Keys von »attributes« zu iterieren und je nachdem,
welche Keys es schon gesehen hat, das vom Aufrufer vorgenommene
Encoding rückgängig zu machen. Da die Hash-Key-Reihenfolge aber bei
jedem Aufruf von Perl zufällig gewählt wird, passiert es halt
manchmal, dass diese Keys bereits gesehen wurden und Email::MIME das
Encoding rückgängig macht.

Daher muss der »Content-Disposition«-Header unbedingt nach dem
Erzeugen mit »create« gesetzt werden. Dann lässt Email::MIME ihn auch
genau so, wie er sein soll.
SL/Mailer.pm