Bug 52399 - mime encoded mail with eight bit characters are displayed wrong
Summary: mime encoded mail with eight bit characters are displayed wrong
Status: RESOLVED WAITINGFORINFO
Alias: None
Product: kmail
Classification: Applications
Component: mime (show other bugs)
Version: unspecified
Platform: Mandrake RPMs Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-12-30 01:49 UTC by Robin Rosenberg
Modified: 2012-08-19 01:06 UTC (History)
3 users (show)

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 Robin Rosenberg 2002-12-30 01:49:31 UTC
Version:           1.5 (using KDE 3.1.0 (RC5))
Installed from:    Mandrake Linux Cooker i586 - Cooker
Compiler:          gcc version 3.2.1 (Mandrake Linux 9.1 3.2.1-1mdk)
OS:          Linux (i686) release 2.4.20-2mdk

Mime encoded quoted-printable received mail containg eight bit characters gets those chopped off in the display and when transferred to the clipboard.

This test mail cut from the inbox file (after being cut from a real mail and resent)
----BEGIN---
From robin.rosenberg@dewire.com 
Return-Path: <robin.rosenberg@dewire.com>
Delivered-To: roro@www.dewire.com
Received: (qmail 18049 invoked by alias); 30 Dec 2002 00:37:55 -0000
Delivered-To: robin.rosenberg@dewire.com
Received: (qmail 17919 invoked from network); 30 Dec 2002 00:17:00 -0000
Received: from unknown (HELO DEWIRE:COM) (unknown)
  by unknown with SMTP; 30 Dec 2002 00:17:00 -0000
From: Robin Rosenberg <robin.rosenberg@dewire.com>
To: Robin Rosenberg <robin.rosenberg@dewire.com>
Content-Transfer-Encoding: 8bit
Subject: Test
Content-Type: multipart/mixed;
  boundary="Boundary-=2000020403120849000"
Status: R 
X-Status: N
X-KMail-EncryptionState:  
X-KMail-SignatureState:  

--Boundary-=2000020403120849000
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hej dude

Tack f
Comment 1 Ingo Klöcker 2002-12-30 02:29:03 UTC
Subject: Re:  New: mime encoded mail with eight bit characters are displayed wrong

Quoted-printable encoded data must not contain 8 bit characters. So 
basically the message you received was not correctly encoded. Maybe 
your mail server automatically converted the quoted-printable to 8 bit 
(as indicated in the Content-Transfer-Encoding header of the message) 
but forgot to change the Content-Transfer-Encoding header of the 
message part accordingly.

It's disputable whether the quoted-printable decoder should strip off 8 
bit characters or whether the decoder should ignore and output them. 
Marc?
Comment 2 Robin Rosenberg 2002-12-30 03:46:06 UTC
Our server did nothing. The sample was perhaps toos short. There ere other QP-encoded 
data in the letter.  
Here is my reasoning why the mail should be displayed anyway: 
2. The original had Content-Transfer-Encoding set to 7bit on the main envelope (which IS 
wrong), but I changed it to 8bit and resent it. If the server is 8-bit clean (e.g. starting the 
SMTP session with EHLO and 8BITMIME is reported back) the mail should pass if the main 
message is marked as eight bit and is mime-encoded. 
3. The QP says that certains characters MAY be recoded. This goes against the intentions of 
QP, but... 
 
To resolve the original problem I had, both 7bit and 8bit should just be "ignored", (as long as 
no security problems arise). 
 
Comment 3 Marc Mutz 2002-12-30 14:00:55 UTC
Subject: Re:  New: mime encoded mail with eight bit characters are displayed wrong

On Monday 30 December 2002 02:24, Ingo Kl
Comment 4 Ismail Donmez 2004-07-20 13:24:54 UTC
Ok this looks like an INVALID bug. Can we please close this?
Comment 5 Till Adam 2004-07-20 15:51:47 UTC
Marc?
Comment 6 Christoph Hintermüller 2004-07-30 09:57:19 UTC
As an enduser of KMail I do not care about rfc's and/or mailsserveers dooing improper, incomplete work. I just wan't to read my mail without any strange and unreadable chars. So the quick fix would be to ad a possibility to let kmail to fix this eventhough not it's duty. Furhter let the user decide if he want's to activate this, activate it but get warnings or stick to the standard.

Is it possible to figure out which server or client did this bad encoding?? Or if bad conversion occurs it could been any of the ones in the trace of the mail??? If the bad guy is traceable just extend the messages about bad encoding by something like -> bad encoding rather likely to be introduced by <server> contact it's master at <address> ?? [contact] [don't]

or so

or at least say mail contains bad char if you still wanna read click her as it is allready done for html mails and start recode in the background.

cu
Chris
Comment 7 Philip Rodrigues 2006-10-29 11:20:30 UTC
From the comments, it looks like this should now be a wishlist - changing
Comment 8 Myriam Schweingruber 2012-08-18 08:11:55 UTC
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.
Comment 9 Luigi Toscano 2012-08-19 01:06:45 UTC
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.