Bug #32965
closed
Swiftmailer inserts unprintable characters when non-ASCII characters are present
Added by Nils Blattner over 12 years ago.
Updated almost 11 years ago.
Description
When there are non-ASCII characters in the subject (in our case "Umlaute" - äöü - or french characters éàè etc.), the swiftmailer inserts unprintable characters and breaks the UTF-8 encoding for some reason.
The TYPO3-core where we had and solved the problem was always a 4.5.2 so far. But since I did not see any changes to the Swiftmailer class mentioned below, I guess it still persists in 4.7.
Bad subject:
Stellenausschreibung - =?utf-8?Q?Ober=C3=A4rztin/Oberarzt?= sowie =?utf-8?Q?Assistenz=C3=A4rztin/Assisten?=
Should look like:
Stellenausschreibung - Oberärztin/Oberarzt sowie Assistenzärztin/Assistenzarzt
As it has been a little while since I actually debugged the issue, I do not remember where exactly this issue comes from, but it can be resolved with patching the file:
typo3/contrib/swiftmailer/classes/Swift/Transport/SimpleMailInvoker.php
The idea is to remove all nonprintables from the subject as shown in the attached patch.
I understand this is not an ideal solution, however it was the only one I found at the time.
Kind regards
Nils
Files
I see that an update for swiftmailer 4.1.3 was pushed with #32062 - but only for TYPO3 4.7. Could you maybe check if updating swiftmailer helps the problem? I guess you might just want to exchange the swiftmailer itself if possible below typo3/contrib/swiftmailer/
In the changelog of swiftmailer
https://raw.github.com/swiftmailer/swiftmailer/master/CHANGES
I found that 4.1.2 has a change "fixed charset on parameter header continuations". Maybe that relates to your problem? Or something that changed between the 4.0.x-series (which I guess you might still have in 4.5.x) and the 4.1-series of swiftmailer?
In case we know that an update to swiftmailer helps it I guess that makes it easier to decide how to continue in this issue.
Looking forward to your reply.
- Category set to Backend API
- Status changed from New to Needs Feedback
The behaviour of SwiftMailer follows RFC2047 [1] exactly.
The subject of an email is not part of the body, but just another header. Any word with non-ASCII characters must be encoded.
From your example:
Stellenausschreibung - Oberärztin/Oberarzt sowie Assistenzärztin/Assistenzarzt
"Oberärztin/Oberarzt" is a word with a non-ASCII character. SwiftMailers default encoding is UTF-8, so it becomes:
=?utf-8?Q?Ober=C3=A4rztin/Oberarzt?=
=? <charset> ? <encoding> ? <encoded-text> ?=
charset: utf-8, encoding: Q (Quoted Printable, can also be B : Base64)
I just tested with Thunderbird and your subject was generated as:
Subject: Stellenausschreibung - =?ISO-8859-1?Q?Ober=E4rztin/Oberarzt_so?=
=?ISO-8859-1?Q?wie_Assistenz=E4rztin/Assistenzarzt?=
(It sent an ISO-8859-1 mail)
There is no bug IMO, it is completely standard compliant.
[1] http://tools.ietf.org/html/rfc2047
- Status changed from Needs Feedback to Closed
Closed because of no Feedback for more than 90 days.
I wonder why this issue has been closed. I had the same problem in version 6... But if you change to smtp instead of using swiftmailer, it helps as well.
If you read the history of this issue it becomes clear why it was closed:
- a year ago there was answer as to why the behaviour of SwiftMailer is correct (and maybe the mail client used by the reporter incorrectly displayed the encoded subject)
- 2 months ago it was noted that no feedback was received for a very long time. Apparently it was not an issue anymore to the reporter.
You mention that you "change to smtp instead of using swiftmailer"; where do you change that? Do you use an extension that still uses the old mail API (which is picked up by an adapter and sent using the new mail API (based on SwiftMailer))? If the extension uses the new mail API directly things should go right.
I tested with the subject the reporter and the subject was displayed correctly in several mail clients.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by