Bug 84325 - character set for outgoing mails is not always minimal
Summary: character set for outgoing mails is not always minimal
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kmail
Classification: Applications
Component: general (show other bugs)
Version: 1.6
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-07-01 20:15 UTC by Eugen D
Modified: 2015-04-12 10:25 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Contains 3 mails tarred from my "$HOME/Mails/drafts/cur" folder: jap, jap+umlaut and jap+removedUmlaut (10.00 KB, application/octet-stream)
2004-07-04 13:28 UTC, Eugen D
Details

Note You need to log in before you can comment on or make changes to this bug.
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.