Bug 88159

Summary: Resending emails without attachment is broken
Product: [Unmaintained] kmail Reporter: Jim Dabell <jim>
Component: generalAssignee: kdepim bugs <pim-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: dennis, raphael.langerhorst
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Jim Dabell 2004-08-26 21:00:22 UTC 
Version:            (using KDE KDE 3.3.0)
Installed from:    Gentoo Packages

If you send an email with an attachment, and then re-send it without the attachment, the headers of the second email look like they are simply copied from the original email.  This results in a blank email in at least some cases.  This only happens when you are prompted for a 'forgotten' attachment.

How to reproduce:

1.  Send an email to yourself with an attachment.

2.  Go to your sent-mail folder, right-click on the email you just sent, and select 'Send Again...'.

3.  Make sure you mention the attachment in the email.

4.  Remove the attachment from your email.

5.  Click 'Send'.

6.  Answer 'Send as Is' when it prompts you for an attachment.

This will result in an email being sent with the header:

Content-Type: Multipart/Mixed;
  boundary="Boundary-00=_VVhLBM4V20oEHUZ";
  charset="iso-8859-1"

(Well, in my particular case, the boundary and charset might vary elsewhere.)

Upon receiving this email in KMail, the body appears to be completely blank.  The email has an icon indicating that it has attachments.  Removing the offending header by editing the file manually on the server results in KMail treating it correctly.
Comment 1 Tom Albers 2004-10-02 21:17:28 UTC 
*** Bug 90547 has been marked as a duplicate of this bug. ***
Comment 2 Tom Albers 2004-10-02 21:19:45 UTC 
*** Bug 87944 has been marked as a duplicate of this bug. ***
Comment 3 Ingo Klöcker 2004-12-08 00:46:10 UTC 
CVS commit by kloecker: 

Fix message composition of editted messages where all attachments are removed or where the crypto format is changed from a MIME-format to inline or unsigned. As the comment in messagecomposer.cpp explains we can't blindly trust the content-type of the message . Instead we have to assume that the content-type is invalid as soon as the user made any change to the message. OTOH, we must not reset the content-type if the message wasn't modified in the composer which is for example the case if a groupware invitation is sent.
The new parameter in KMComposeWin::slotSelectCryptoModule is necessary to detect changes of the crypto format.
Add isModified() and setModified() to KMComposeWin to easily query and (re)set the modification status.
In KMComposeWin::slotContinueDoSend() reset the modification status only if sending/saving as draft really succeeded.
BUG: 88159
BUG: 93512


  M +49 -27    kmcomposewin.cpp   1.892
  M +11 -1     kmcomposewin.h   1.263
  M +6 -0      messagecomposer.cpp   1.38