I composed an email. I clicked send, assuming that it would be sent. A couple of hours later, I looked at kmail2's UI. There was still a message in the outbox. No sending progress bar showed. I clicked File->Send Queued Messages. The email still sat in the outbox, no progress bar showed. I rebooted my system, logged in again, restarted kmail2, and clicked File->Send Queued Messages. Still no joy. No diagnostic dialog. No diagnostic output on the console. Went to the outbox. Opened the message. Clicked send. It got sent. Reproducible: Always Expected Results: Send my email, or give me a dialog explaining that you're not going to do that and why you can't do that.
I am using 4.9.3 and also observe that mail in my local outbox dir gets stuck. Steps to reproduce: 1. Save a mail in ~/.local/share/local-mail/outbox/new/foo.bar containing: From: whaterver@example.com To: some@user.com Subject: blabla Date: Sat, 08 Dec 2012 00:02:53 +0100 does not work 2. (observation) KMail detects the mail and it is shown in Local Folders/outbox 3. I select "Send Queue Messages" from the tray icon. What did you expect? I expect the mail dispatcher to deliver the mail which makes the KMail progress bar visible and finally show a notification with the result (success/failure). What happened instead? No visual feedback and the mail(s) are still not sent. When looking in my .xsession-errors log, I see: kmail2(9808)/kdepimlibs (mailtransport) Akonadi::FilterActionJob::doStart: Fetching collection 5 kmail2(9808)/kdepimlibs (mailtransport) Akonadi::FilterActionJob::Private::traverseItems: Traversing 3 items. kmail2(9808)/kdepimlibs (mailtransport) MailTransport::SendQueuedAction::itemAccepted: Item doesn't have DispatchModeAttribute. kmail2(9808)/kdepimlibs (mailtransport) MailTransport::SendQueuedAction::itemAccepted: Item doesn't have DispatchModeAttribute. kmail2(9808)/kdepimlibs (mailtransport) MailTransport::SendQueuedAction::itemAccepted: Item doesn't have DispatchModeAttribute. kmail2(9808)/kdepimlibs (mailtransport) Akonadi::FilterActionJob::Private::traverseItems: No subjobs; I am done kmail2(9808)/kdepimlibs (mailtransport) MailTransport::DispatcherInterfacePrivate::massModifyResult: succeeded. I started akonadiconsole, tab Browser, Collection Local Folders/outbox and selected one affected message on the right panel. When clicking the attributes tab, I see no attributes. When creating a message and queue it, I can see the following attributes: - AddressAttribute (empty) - TransportAttribute (number) - SendActionAttribute (empty) - DispatchModeAttribute "never" - SentBehaviourAttribute "moveTo6"
I understand there can be many reasons for failing to send an email, but would it be possible at least to make it much more obvious when something is not working right? Knowing that an email was not sent is often very critical. Why isn't there a configurable notification for this? Note there is already a notification for email transport failure, but I believe here it is different: for some reason Kmail did not even try to send the email, despite of the fact the user pressed "send" button. If kmail is a situation it won't even try to send an email after pressing that button, then this should definitely trigger an alert too.
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
I gave up on Kmail about a year and a half ago. As far as I'm concerned, you can close this bug.
Thanks for the feedback.