Bug 84325

Summary: character set for outgoing mails is not always minimal
Product: [Applications] kmail Reporter: Eugen D <eugen>
Component: generalAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED UNMAINTAINED    
Severity: normal CC: chris.kerr, kollix
Priority: NOR    
Version: 1.6   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: Contains 3 mails tarred from my "$HOME/Mails/drafts/cur" folder: jap, jap+umlaut and jap+removedUmlaut

Description Eugen D 2004-07-01 20:15:53 UTC
Version:           1.6 (using KDE 3.2 BRANCH >= 20040204, SuSE)
Compiler:          gcc version 3.3.1 (SuSE Linux)
OS:                Linux (i686) release 2.4.21-192-athlon

my charset list for outgoing mails is set to
- us-ascii
- iso-8859-1
- iso-2022-jp
- utf-8

If I write mails containing only japanese and latin characters (not using umlauts etc.) then normally iso-2022-jp is used, which is corrected. It is the first in the list which contains all chars.
But sometimes my mails get out as utf-8, even though all characters are contained in iso-2022-jp.

In order to check wy that happens, I wrote a mail using japanese chars, saved it in the "Draft" folder and looked into the mail code: encoding was iso-2022-jp (7bit). Then I added an umlaut, saved it again - the new encoding was utf-8 (base64). Until now everything's fine. But when I deleted the umlaut and saved the mail again, the encoding still was "utf-8".

Thus my theory, why some of my mails containg only iso-2022-jp characters are sent as utf-8 is, that if I write an umlaut during mail creation and the mail is backed up on disk ($HOME/dead.letter), the utf-8 encoding is used - later deletion of the umlaut does not change the encoding back to the minimal one.

Unfortunately many web mail clients (in Japan?) cannot handle these (base64 encoded) utf-8 mails :(
Comment 1 Don Sanders 2004-07-02 12:13:50 UTC
Please attach/provide a tar'd copy of a mail that can be used to 
reproduce the problem.

Comment 2 Eugen D 2004-07-04 13:28:16 UTC
Created attachment 6548 [details]
Contains 3 mails tarred from my "$HOME/Mails/drafts/cur" folder: jap, jap+umlaut and jap+removedUmlaut
Comment 3 Chris Kerr 2005-08-09 17:45:12 UTC
I have this problem too. I tried disabling "Keep original charset when replying and forwarding" but it didn't seem to help.

What is more, kmail doesn't even seem to understand its own utf8/base64 encoding - messages in the sent-mail folder come up as garbage when opened. However, on choosing "send again", the resulting composer window contains the correct text.
I also cannot read iso-2022-jp sent mail - but I do not know if this is just because I have something incorrectly installed. Again, clicking "send again" magically recreates the correct text.
Comment 4 Martin Koller 2009-09-05 13:28:22 UTC
reproducable with KDE 4.3.1
Comment 5 Laurent Montel 2015-04-12 10:25:07 UTC
Thank you for taking the time to file a bug report.

KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2.

We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.