Bug 260011 - Transport error when answering a notification request
Summary: Transport error when answering a notification request
Alias: None
Product: KMail Mobile
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
Depends on:
Reported: 2010-12-15 23:20 UTC by Sabine Faure
Modified: 2011-01-08 02:09 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Sabine Faure 2010-12-15 23:20:39 UTC
Version:           unspecified
OS:                Linux

When the user sends an email requesting notification he never receives any because the recipient gets a transport error when trying to send the notification.

Reproducible: Always

Steps to Reproduce:
- Launch Kmail-mobile
- Click on 'Write new email'
- Enter a subject, a recipient (choose an email that you can read on your desktop computer and a different one than your Imap testing email since you should use it as the sender's email) and a few words in the editor
- Open the 'Actions' tab
- Click on 'Options'
- Click on ' Request Notification' to highlight it
- Click on 'Send'
- The recipient receives the email properly
- The recipient clicks on the email and see the pop up notification dialogue appearing
- The recipient should click on 'Send'

Actual Results:  
There is a 'sending failed' pop up error message saying: 'Transport 'kdab 1' is invalid preventing the recipient to send back a notification.

Expected Results:  
The notification should be sent back to the initial sender properly.

N900, 4:4.6~20101215.1206727-1maemo1.1206430
Comment 1 David Faure 2010-12-15 23:26:41 UTC
I think the root cause of the bug is that every mail sent by kmail-mobile contains a X-KMail-Transport field, with the (user-chosen) name for the transport which was used for sending the mail. KMail 1 didn't do that, and I see no good reason for this, so this looks like a bug.

In addition it's a bit strange that the sending of a MDN reuses the X-KMail-Transport field; but this probably can be ignored if kmail is made to never send mails with a X-KMail-Transport header.
Comment 2 Tobias Koenig 2010-12-28 15:04:58 UTC
commit af86ce9b8404335609fb992bb920446cbb3340bc
branch master
Author: Tobias Koenig <tokoe@kde.org>
Date:   Tue Dec 28 15:07:40 2010 +0100

    Remove private headers before passing message to MDA
    BUG: 260011

diff --git a/messagecomposer/akonadisender.cpp b/messagecomposer/akonadisender.cpp
index 37168e8..be01f98 100644
--- a/messagecomposer/akonadisender.cpp
+++ b/messagecomposer/akonadisender.cpp
@@ -154,6 +154,7 @@ void AkonadiSender::sendOrQueueMessage( const KMime::Message::Ptr &message, Mess
   qjob->addressAttribute().setBcc( bcc );
   MessageCore::StringUtil::removePrivateHeaderFields( message );
+  message->assemble();
   // Queue the message.
   connect( qjob, SIGNAL(result(KJob*)), this, SLOT(queueJobResult(KJob*)) );
diff --git a/messagecomposer/composerviewbase.cpp b/messagecomposer/composerviewbase.cpp
index 6fc4c3a..84b6fe8 100644
--- a/messagecomposer/composerviewbase.cpp
+++ b/messagecomposer/composerviewbase.cpp
@@ -677,6 +677,10 @@ void Message::ComposerViewBase::queueMessage( KMime::Message::Ptr message, Messa
   fillQueueJobHeaders( qjob, message, infoPart );
+  MessageCore::StringUtil::removePrivateHeaderFields( message );
+  message->assemble();
   connect( qjob, SIGNAL( result(KJob*) ), this, SLOT( slotQueueResult( KJob* ) ) );
Comment 3 Sabine Faure 2011-01-08 02:09:51 UTC
It is corrected now.

The initial sender now receives a 'Disposition Notification Message' saying: 'The message sent on DD-MM-YYYY TT:MM to RECIPIENT'S EMAIL with subject ''EMAIL SUBJECT'' has been displayed. This is no guarantee that the message has been read or understood.'

So I am closing this bug.

N900, 4:4.6~.20110106.1209.gitfde48d5-1maemo1.121147