Bug 494945

Summary:	"From" name with special character breaks email sending
Product:	[Applications] kmail2	Reporter:	Stefan Dösinger <stefandoesinger>
Component:	general	Assignee:	kdepim bugs <kdepim-bugs>
Status:	REPORTED ---
Severity:	normal
Priority:	NOR
Version First Reported In:	6.2.1
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	bad email good email

Description Stefan Dösinger 2024-10-17 17:20:56 UTC

Created attachment 174954 [details]
bad email

SUMMARY

kmail 6.2.1 from KDE Gear 24.08.1 fails to send E-Mails with two of my mail providers (gmx.at and gmail). The server refuses to send the emails because supposedly the "from" address is not mine.

I have isolated the issue down to the "ö" character in my name. If the from address is "Stefan Dösinger <stefandoesinger@gmx.at>", sending fails. If I set the name in the kmail identity to "Stefan Doesinger" or leave it empty, sending succeeds.

This happens on a new KDE installation. Interestingly it does not happen on a second system that has been upgraded over the years and the E-Mail setup is a few years old. As far as I can see the difference in the generated emails is this:

Bad version:
From: Stefan Dösinger <stefandoesinger@gmx.at>

Good version:
From: Stefan =?UTF-8?B?RMO2c2luZ2Vy?= <stefandoesinger@gmx.at>

Both versions also have these headers:
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"

I have attached two email files for reference

STEPS TO REPRODUCE
1. Start with a fresh KDE setup, e.g. create a new Linux user
2. Set up an E-Mail account with a special character in the sender name (not the sender address)
3. Try to send an email

OBSERVED RESULT

Sending the Email is rejected. It depends a bit on the exact provider. gmx says "transaction failed" when sending. gmail seemingly sends, but the recipient (in this case my gmx address) rejects the email because supposedly the From address is invalid.

EXPECTED RESULT

Email gets sent correctly

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Gentoo, KDE 24.08.1

ADDITIONAL INFORMATION

The "good" system is an x86_64 system, the bad one an aarch64 one. But I suspect the platform doesn't matter. Instead, something in ancient config files hides the bug on one of them

Comment 1 Stefan Dösinger 2024-10-17 17:21:36 UTC

Created attachment 174955 [details]
good email

Comment 2 Stefan Dösinger 2024-10-17 18:41:45 UTC

I think some of my understanding of what triggers the bug is wrong: I tried setting up my email account in a fresh Linux user on the amd64 system: The result is that the umlaut in the "From: " and "To :" fields are properly =?UTF-8? escaped. So that it works there has nothing to do with my year old grown config.

Other than the CPU architecture, the other difference I could spot is that the x86_64 system had accessibility libraries enabled (gentoo +accessibility use flag), whereas the arm64 system did not. I am changing that on the arm64 system now and will report back. It doesn't seem to have an effect on akonadi and kmail specifically, but it does affect Qt.

Other things I tested and I am convinced have no effect:
* Wayland vs X11
* The language (english vs german) that is active when setting up the email account

Comment 3 Stefan Dösinger 2024-10-18 07:46:30 UTC

I start to believe that this is actually an aarch64 vs x86_64 difference.

On aarch64, kmail believes the "ö" character is valid to send in headers. If I save the email as a file, the ö is encoded as ISO-8859-1 with character value 0xF6. On x86_64, it is properly escaped.

Other extended characters get escaped properly. If I add some Hebrew character to my name, the From like has the RFC 2047 coding.

Some other headers, like "X-KMail-Identity-Name:" or the subject are not affected.

Is it possible there's a signed vs unsigned char bug somewhere? That's the most obvious difference between x86 and arm I can think of here...

I updated my installation to pull in the accessibility libraries. This did not fix the problem.