Bug 79639 - Auto-detect encoding/charset for invalid mails
Summary: Auto-detect encoding/charset for invalid mails
Status: RESOLVED FIXED
Alias: None
Product: kmail
Classification: Applications
Component: mime (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-14 16:01 UTC by Marcus Sundman
Modified: 2007-09-14 12:17 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Sundman 2004-04-14 16:01:38 UTC
Version:            (using KDE KDE 3.2.2)
Installed from:    Debian testing/unstable Packages
OS:          Linux

KMail should auto-detect the encoding/charset of incoming messages that have a missing or invalid Content-Type and/or Content-Transfer-Encoding. I know it's not kmail's fault if incoming messages have invalid headers, but the fact remains that many messages are displayed well in other email clients but not in kmail. Perhaps the user should provide an ordered set of preferred fallback charsets, similarly to how it's done for composed messages. If an incoming message doesn't match any of these then kmail is free to choose any available charset as best it can, preferably taking the LC_* and LANG values into account. (The "View -> Set Encoding" is completely useless as it is now. At the very least it should provide a fallback encoding instead of an overriding one. It should be completely replaced with a working system, though.)
Comment 1 Ismail Donmez 2004-07-20 20:53:44 UTC

*** This bug has been marked as a duplicate of 79254 ***
Comment 2 Marcus Sundman 2004-07-20 22:27:28 UTC
This is not a duplicate of #79254 which is about being able to change the encoding to be used for the header fields. This bug report is about having a default encoding for the message content (although this could well be extended to include the headers as well).
Comment 3 Tuomas Suutari 2004-11-05 15:11:31 UTC
I have had similar problems with non-ASCII messages that do not specify encoding at all. For me they have ALL been ISO-8859-1 coded messages. And because I use UTF-8 as my local encoding, they are all shown incorrectly!

Has anyone seen non-ASCII messages without encoding specification, that are not ISO-8859-1?

I think it could be a good workaround to assume ISO-8859-1 (instead of local encoding) for messages without encoding specification. RFC 2045 says they are ASCII, so because ISO-8859-1 covers ASCII it wouldn't even break the standard.

What do You think?
Comment 4 S. Burmeister 2004-11-05 18:17:56 UTC
Maybe you want to have a look at bug 84702, which already had a patch that did not really solve the problem but at least was a start towards solving these issues.
Comment 5 Vahur Lokk 2004-12-17 10:01:28 UTC
*** This bug has been confirmed by popular vote. ***
Comment 6 Till Adam 2005-01-08 15:59:10 UTC
CVS commit by tilladam: 

Make it possible to specify a fallback encoding in the config dialog under
Appearance -> Message Window which is used if there is no override codec 
active (Encoding set to Auto) and the mail itself does not specify one
either. Since it is impossible to find a default for this which works
everywhere the settings defaults to locale, unless locale is eucjp in
which case the jis7 encoding is used. So if you are a SuSE 9.2 user, for
example this will default to utf8 but you can then set it to the encoding
the mails you get are usually in. iso-8859-15, for example, for germany.

Sven, thanks for reporting and insisting on this solution. It's probably
the right thing to do (TM).

BUG: 45279
BUG: 84702
BUG: 79639


  M +75 -1     configuredialog.cpp   1.506
  M +19 -0     configuredialog_p.h   1.104
  M +7 -0      kmail.kcfg   1.31
  M +5 -0      kmmessage.cpp   1.506