Version: 1.7.2 (using KDE 3.3.2, Gentoo) Compiler: gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) OS: Linux (i686) release 2.6.9-gentoo-r8 Hello. I can't read mail's subject in many letters. It's very annoying. The problem is with messages like following: ***** Subject: Добро пожаловать на форумы Gazety.Ru MIME-Version: 1.0 Content-type: text/plain; charset=windows-1251 Content-transfer-encoding: 8bit Charset: windows-1251 Добро пожаловать на форумы Gazet ***** Kmail does not interpret subject to be in cp1251 encoding. So subject is unreadable. The only subjects I can read are of such form: ?Windows-1251?B?wPDj7iDoIMHr/ufu4uD/IODw9eDo6uA=?= Another issue. Changing charset in view menu only affects message body. And subject charset remains the same. So. 1) I think kmail should set subject encoding same to the body, if it's not mentioned otherwise. 2) And changing charset in view menu should affect subject, for such mails... Thank you for your attention. IMHO kmail is best mail client for Linux now. Thank you.
Can you attach one such digest to this bug report, intact? It would help us find the problem. A screenshot of KMail exhibiting the buggy behaviour would also be nice. As far as I understood, the problem happens only on the headers of the attached messages. You said you can see some subjects, but I did not quite understand what exactly makes them different: do you see the Base64-encoded version or the decoded form? As for the message list pane, sorry, but it should be working fine. Email headers are, as per RFC 2047, restricted to 7-bit. So email headers MUST use the RFC 2047 form of encoding (which is actually what you seem to have working). Anything else is broken behaviour on the part of the sender's email client.
Created attachment 8664 [details] Screen shot of kmail window that illustrates the problem. In next comments I'll show the messages.
As you can see from the message in #2 there is a problem with the first mail. Below is the source of mail: ***** Return-path: <gazety@undeliverable.zenon.net> Received: from [195.2.83.184] (port=25 helo=frontend1.aha.ru) by mx3.mail.ru with esmtp id 1CdVlC-000J66-00 for my_mail@mail.ru; Sun, 12 Dec 2004 18:35:46 +0300 Received-SPF: none (mx3.mail.ru: 195.2.83.184 is neither permitted nor denied by domain of undeliverable.zenon.net) client-ip=195.2.83.184; envelope-from=gazety@undeliverable.zenon.net; helo=frontend1.aha.ru; Received: from [195.2.72.36] (HELO pm3.zenon.net) by frontend1.aha.ru (CommuniGate Pro SMTP 4.2.6) with ESMTP-TLS id 117812431 for torre_cremata@mail.ru; Sun, 12 Dec 2004 18:35:46 +0300 Received: (from gazety@localhost) by pm3.zenon.net (8.12.9/Zenon/Postman) id iBCFYn8M044316; Sun, 12 Dec 2004 18:34:49 +0300 (MSK) (envelope-from gazety) Message-Id: <200412121534.iBCFYn8M044316@pm3.zenon.net> To: torre_cremata@mail.ru Subject: Добро пожаловать на форумы Gazety.Ru MIME-Version: 1.0 Content-type: text/plain; charset=windows-1251 Content-transfer-encoding: 8bit Date: Sun, 12 Dec 2004 15:34:48 UT From: admin@gazety.ru X-Spam: Not detected Status: RO X-Status: RC X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: Charset: windows-1251 ***** Yes. Actually the problem is on the senders email side. It sends 8 byte encoded subjects. But I think that there exist(?) a way to determine such broken subjects and recode them. The charset can be taken from the message body. So now I see that this is not a bug, but this can become an item in the wishlist. So if it possible to make such messages visible, this would be great. There are still many servers, that send such broken mails... P.S. Thank you for fast response.
I am changing the Summary of the bug to reflect your wish. I don't like the broken behaviour in the emails I receive, but this could be a handy feature.
This is related to (but no duplicate of) wish #65766.
*** Bug 105357 has been marked as a duplicate of this bug. ***
*** Bug 106964 has been marked as a duplicate of this bug. ***
*** Bug 118179 has been marked as a duplicate of this bug. ***
*** Bug 119641 has been marked as a duplicate of this bug. ***
For 3.5.1 I changed kmail to use the fallback charset even in the subject line, when none is given there (no rfc2047 conforming tags in Subject)
*** Bug 120819 has been marked as a duplicate of this bug. ***
*** Bug 122539 has been marked as a duplicate of this bug. ***
>For 3.5.1 I changed kmail to use the fallback charset even in the subject line, when none is given there (no rfc2047 conforming tags in Subject) Kmail 3.5.2 - problem not solved.
There is no problem to solve since this is not a bug.
Accordingly, this is a wishlist item. One can of course debate whether it's right to adapt to broken software - it may discourage the authors from fixing what's broken and encourage others to write more broken software. But in practice, you have limited power.
You see.... this issue makes kmail unuseable for many users. And... the body of such broken mail is recoding succesfully, why not the header? And third: when I set encoding manually, it affects only on the body, not the header. So, the header is always unreadable.
Ben: you have to understand that the Header being broken does not mean the Body is broken too. In fact, most mailers get the body right, but not the header. This is what KMail can't decode. KMail works perfectly as long as the other side is sending properly-formatted emails. If your peer is using broken software, please urge him to upgrade. The specification that says how an email should be encoded has existed for 9 and a half years. That said, however, if we didn't think it would be useful to have this feature, we wouldn't have an open wish report. So, yes, we will probably implement it. It's just not a high priority.
I'll have to agree with Ben though, as most end-users would. As a user, I think that this is part of the software and would really help you guys out with the "wish" that KDE is usable by many people (not just the ones using EXCLUSIVELY simple charsets) Moreover, this is one of the first, if not the first thing you notice when you first configure an email account. At this stage, it pretty easy to switch to another client. I really don't want to be a pessimist but I think you should really give a second thought about the "priority" state of this "wish" (read bug). Still, I love KMail ;-)
OK, thanks. But I mean another problem. When I set encoding using kmail menu (for such broken letter, I still need to read headers :)), it affects only the body. Can it affect the headers too? Or, do I have to post a new bug? :) Last time Thiago said, that this duplicating it (bug 122539).
Right, leave it in this one. And, yes, it is a wish: working around other mailers brokenness is not a bug in our side.
*** Bug 127014 has been marked as a duplicate of this bug. ***
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding.
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.