Bug 216678

Summary: Subject line not being processed out of email message
Product: [Applications] kmail Reporter: John Wheaton <johnwheaton2>
Component: generalAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED NOT A BUG    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Ubuntu   
OS: Unspecified   
Latest Commit: Version Fixed In:
Attachments: Email with subject line that does not appear correctly

Description John Wheaton 2009-11-29 16:39:11 UTC
Version:            (using KDE 4.3.2)
Installed from:    Ubuntu Packages

I will attach an email message that kmail does not process properly.  The subject line is not processed out.  What I get for a subject is "(No Subject)" and then the top of the email looks like this:

Content-Transfer-Encoding: 7bit Subject: My Comic Page 11/29/2009 MIME-Version: 1.0 Errors-To: errors@myucomics.com X-Uclick-UID: 89fb9bab497d599fce8274018831dfde


I initially thought this was a problem on the sending side, but my wife sees these emails normally under gmail.  So now I suspect kmail.  Now that I think of it, I used to get mail under Thunderbird and it processed these just fine.
Comment 1 John Wheaton 2009-11-29 16:39:53 UTC
Created attachment 38680 [details]
Email with subject line that does not appear correctly
Comment 2 Torgny Nyblom 2009-11-30 07:59:34 UTC
The example email is invalid.

Everything after the first blank line is the body of an email message and everything before is the header.

You should file a bug to the people/organization providing the sending program/service.

If the email was received ok and KMail altered the headers while adding the X-KMail-* headers then please reopen.
Comment 3 John Wheaton 2009-11-30 13:28:18 UTC
I disagree that this is not a kmail problem.  As I said, this email appears properly under Thunderbird and Gmail.  If it did not, I would be continuing to pursue uclick about their emails.  It looks like kmail is putting its headers above the Content-Transfer-Encoding heading.

Can you help me understand how the email is invalid so that if the decision remains that this is not a kmail problem I can informedly converse with uclick?
Comment 4 Torgny Nyblom 2009-11-30 15:08:33 UTC
From your attached mail.
-----
1: Content-type: text/html;
2:   charset=ISO-8859-1
3: Status: R
4: X-Status: N
5: X-KMail-EncryptionState:  
6: X-KMail-SignatureState:  
7: X-KMail-MDN-Sent:  
8:
9: Content-Transfer-Encoding: 7bit
10:
11: Subject: My Comic Page 11/29/2009
-----
at line 8 above there is an empty line. This is the mailformats way of saying headers section ended, body begins. Hence everything below is by definition the body of the email. So the rendering in KMail is correct.

However if it is KMail that inserts the blank line (#8) then there is an issue in KMail, but not the one you reported here. To find out which we would need to see the mail source before it is processed by KMail. If the blank line is present then it's not a bug in KMail but if the blank line is missing then it's a bug in KMail.
Comment 5 John Wheaton 2009-11-30 15:28:36 UTC
Aha.  Now I get it.  I'm not an email format expert.  :-)

Yes, I was able to get the original email source, before KMail put in its headers, and indeed there is a blank line in there.

---
1: Message-id: <20091130115010.22867.qmail@mail04.uclick.com>
2: Content-type: text/html; charset=ISO-8859-1
3: 
4: Content-Transfer-Encoding: 7bit
5: 
6: Subject: My Comic Page 11/30/2009
---

Based on what you've described, line 3 shouldn't be blank.  Now I have something more constructive to go back to uclick with.  I've been trying to describe this problem to them but haven't received any response.  I suspect with more concrete information like this they'll have something better to work with.

Thanks!  I agree this is invalid.  KMail is not the culprit here.
Comment 6 Torgny Nyblom 2009-11-30 16:18:10 UTC
Nor should line 5...