exactly the same here. There's also a forum post which mentions the problem: http://forum.kde.org/viewtopic.php?f=20&t=95621

+1 here, kde 4.6.4, archlinux, i686. 
I tried with signed/unsigned messages, if that matters. 
Also, (not sure) but i think i was able to send mail some times, but then it gets qued and never works again.

+1 here, KDE4.6.4

Reboot (sic!) solved the problem so far, will see if it persist after suspend/wakeup tomorrow...

Tried it on a fresh install without previous mail data. Works there.
I suspekt the migration tool does something wrong.
Had to downgrade on my work box, because I need an working email client.
Maybe going to try kmail 2. again if there is a working migration tool.

In my case it turns out that NetworkManager is the cause. When I make a network connection with NetworkManager, sending mail works perfectly, but when I shut down NetworkManager, the akonadi mail dispatcher switches to offline mode and stays that way. There's the "Work offline" entry in the "File" menu which has no effect on this. Maybe a nice solution would be to allow the user to override the status message from NetworkManager via this menu entry? I.e. NetworkManager goes offline -> KMail switches to offline mode (incl. notification). Then I can switch KMail back online explicitly with File/Work online.

For the time being, it would be nice to have a workaround using some dbus-send quirkery if possible. I tried:

dbus-send /MailDispatcherAgent org.freedesktop.Akonadi.Agent.Status.onlineChanged boolean:true
dbus-send / org.freedesktop.Akonadi.Agent.Status.onlineChanged boolean:true
dbus-send /modules/networkstatus org.kde.Solid.Networking.Client.statusChanged uint32:4

But that seems to have no effect. Maybe the message is only accepted from a specific sender? Dunno what to do here.

Side note: Maybe NetworkManager needs some fixing in that area, too, but its use cases have always been extremely shallow, so I think we should try and stay independent of it.

I'm having this problem right now, and I'm not using NetworkManager - I'm using WICD.  Messages just sit in the "outgoing" folder and refuse to go anywhere, and there are no messages or other indication why.  This has continued through a full shutdown and restart. This just started happening today on the latest 4.6.x version, so I tried upgrading to the 4.7 RC2 - same problem on 4.7RC2 as well.

Oh, additional note: I'm RECEIVING email (via IMAP) just fine, only sending is failing for me.

Okay, one last note and I'll shut up - I finally got it to send by disconnecting and reconnecting, which I assume made KDE notice that I was connected (I had originally connected to the network before starting KDE).  Once I did that, it looks like the stuck messages finally went through.

It looks to me like solid/KDE has gotten stuck in the NetworkManager "why would you be connected to the network without starting a GUI login first?" thinking, so KDE assumes you're offline unless it gets a "we've just connected to the network" signal after starting.  That would also explain the report on the forum from someone seeing this problem with a static IP as well.

That's my guess anyway.  The aspect of this bug that I would argue belongs to kmail is the lack of a warning or indication that the reason it's not sending is because it hasn't been told the network has been started (even though it runs IMAP just fine in the meantime.)

Should a separate bug be opened for solid(?) about it not checking for a pre-existing network connection when KDE starts?

Just upgraded to KDE 4.6.5 and KMail 4.6.1, and now it's completely dead. No matter what I do with NetworkManager, KMail won't send anything. Haven't had the time to look at the DBus chit-chat yet.

This was working for me in kde 4.6.5 (kdepim 4.6.1)
and now it is broken in KMail
Version 2.1.96 (kde 4.7rc2)

I killall kded4 -9 
then kded4 & disown
without restarting akonadi or kmail.
then I got a message about a certificate and the email was sent.

Installed from OpenSUSE packages.

KMail 2.1.1
KDE 4.6.5 release 7
Akonadi 1.6.0

Same problem here. My mailserver is using a selfsigned certificate. When I try to send a mail, the mail stays in the local outbox and can not be sent. No network communication with the server can be seen. No error messages in .xsession-errors. (anywhere else to look?) Removing and readding the SMTP account results in a "Can not read kwallet" error and a config file storage of the password.

When I use the workaround from Hussam in #12, things work again. (No question about the certificate, seems it remembers I accepted it once.)

I did not migrate, deleted and recreated the accounts.

If this happens again I am willing to provide more logs and debugging if the developers can say me what to look for. 

I consider this a showstopper for 4.7 if it is not fixed. Not being able to send mail without any error message is pretty much the worst showstopper possible for a mail client, isn't it?

Hussam Al-Tayeb, thank you so much!  I was tearing my hair out over this one, but restarting kded solves the issue perfectly for me!  I'm so pleased there's a low-impact workaround for this.  It also gives me hope that this might be a silly little bug and easily fixed.

i can still confirm the bug on kde 4.7, 
also Clark's solution (#9) with reconnecting to network (wicd here too) works for me, yay! I think workaround with killall kded4 does basically the same effect- so solid's fault? 
Anyways, please vote for the bug, i hope it can be addressed soon as it's kinda showstopper for kmail. 
Thanks

*** This bug has been confirmed by popular vote. ***

After executing Hussams workaround, everything is running fine now, even after the update to 4.7. Can not reproduce :(

Not easy to reproduce. It's happened only twice to me so far. But in case it happens again, can the developers please tell us some steps to obtain some information that can help them figure out the problem?

Here's a strange thought: for people having this problem, what do you get if you do "zcat /proc/config.gz | grep AUDITSYSCALL"?

I finally got around to tracking down an unrelated irritation (relating to udisks permissions) that came down to this, which also solved the "no 'shut down' option in the menu" issue that I've been having but not caring about for so long. Maybe coincidentally, I've not seen this kmail issue since then, either.

I'm just wondering if issues with the network state detection might be another consolekit-related problem (consolekit evidently requires CONFIG_AUDITSYSCALL=y to function properly).

I have tried ALL that it has commented in the bug. So far:

- Delete all kmail1,2 and akonadi config and mails and recreate acounts.
- Restart kded4
- Restart network (from kmail and from networkmanager) 
- Check that mail transport is correctly set

and kmail STILL don't send emails.

I have CONFIG_AUDITSYSCALL=y and consolekit is already running.

Finally I have manager to solve restarting akonadictl stop/start as said in bug 

https://bugs.kde.org/show_bug.cgi?id=274750

I wanted to follow up and report that my AUDITSYSCALL thing does, indeed, turn out to be unrelated.  KMail is still doing this (i.e. silently refusing to send) to me.

I have noticed that on occasion if log out of KDE and back in, then restart kmail, I get the kwallet popup once which is apparently for the incoming (IMAP) mail.  On a couple of occasions at least, I can then close kmail, disconnect from the network (via wicd), then reconnect...and all of a sudden I get another kwallet popup asking for permission, and when granted, I finally get an "email sent" notice (note that "kmail" appears to have been closed at this point, but evidently the process trying to send via SMTP is still running in the background, blocked on whatever the heck it is that's causing this problem).  Is KMail maybe not asking for access to the password "wallet" for SMTP on the assumption that it has already accessed the wallet for the IMAP password and doesn't think it needs to again, or something?  (Just grasping at metaphorical straws here, I have no idea and this bug is starting to drive me Nucking Futs...)

@S Clark => This is indeed an annoying bug, but maybe you haven't noticed that there's an easy workaround?  Just enter the following commands in Konsole:

killall kded4
kded4

That should fix the problem, and the e-mail should send.  You'll notice your system tray icons go weird in between the commands, but everything should go back to normal afterwards.

after restarting akonadi the queued mail was lost... but kmail asked to use kwalletmanager and it asked the SMTP password, and now I'm able to send email with KMail 2...

I've only tried it once so far, but I've just updated to 4.7.1, and now kmail does seem to be correctly popping up the request for access to kwallet and send on the first try.  Perhaps this is now fixed in 4.7.1?

Just happened to me again under 4.7.1 after reconnecting to the internet.
I killall -9 kded4 and ran kded4 again
I got get kwallet message and was able to send my email afterwards.

I've encountered the same problem with KMail as part of KDE 4.7.1 on Arch Linux.  (I don't know where to find the KMail version, as it just says "KMail Version 4.7.1" in the About dialog.)

For me, the solution was to run this command as root:

/etc/rc.d/network restart

(This being for Arch Linux, the command might be different on other distros.)

in 4.7 git branch, kmail now warns me that the mail dispatcher is offline and offers to make it online instead of simply not sending queued messages.

Restarting network, akonadi, kded4 and kmail did not work for me.
I killed .local/share/akonadi and .config/akonadi
KMail showed local folders, but the sending configuration still present
I cannot send a new message because KMail says "unknown collection".
kmail2(14888)/libakonadi: Resource id's don't match:  "akonadi_maildir_resource_0" "akonadi_mixedmaildir_resource_1" 
so I killed .kde4/share/apps/kmail2 and the e-mail went out
Note that this time the outbox name is localised.

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.

Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.