Project

General

Profile

Actions

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.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Backend API
Target version:
-
Start date:
2012-01-04
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.5
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

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

patch.diff (70 Bytes) patch.diff Nils Blattner, 2012-01-04 15:04
Actions #1

Updated by Stefan Neufeind about 12 years ago

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.

Actions #2

Updated by Jigal van Hemert about 12 years ago

  • 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

Actions #3

Updated by Jigal van Hemert about 11 years ago

  • Status changed from Needs Feedback to Closed

Closed because of no Feedback for more than 90 days.

Actions #4

Updated by Michel Baeriswyl almost 11 years ago

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.

Actions #5

Updated by Jigal van Hemert almost 11 years ago

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.

Actions

Also available in: Atom PDF