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
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.
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* ) ) ); m_pendingQueueJobs++; qjob->start();
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