Version: 1.6.1 (using KDE 3.2 BRANCH >= 20040204, Mandrake Linux Cooker i586 - Cooker) Compiler: gcc version 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk) OS: Linux (i686) release 2.6.3-4mdksmp Just installed Mandrake 10.0 Community and trying to configure Kmail was able to receive just fine but cannot send. Tired removing and reinstalling smtp server info still will not send. New to Linux so don't know if this is handled differently from other Linux distributions or even older versions of Mandrake?
I have the same problem, I can not get KMail to send emails. Maybe this is a Mandrake related problem?
Does my comment to http://bugs.kde.org/show_bug.cgi?id=81611 help? If so, please close this bug report as a duplicate.
*** Bug 80817 has been marked as a duplicate of this bug. ***
Recently I managed to configure my main account to send emails. I do not know what the problem was in the first case, KMail is lacking feedback in this area (bug 78895). The other problem I have (another user) seems to be bug 73316.
Seems to be the same bug as #76479: (mail can't be sent because of missing sender address in default identity, failed messages in outbox block new mail sending) Also this problem (Mandrake 10.0 Official), but the sender address IS set. Problem appeared after changing other config settings.
Possible diagnosis of bug ------------------------- Sequence of actions: Checked the contents of file ~/.kde/share/config/kmailrc but [Transport 1] section appears to be completely normal. Confirmed that still unable to send mail (error shown in status bar: Unrecognised transport protocol). Deleting and re-creating Network/Sending settings in config did not fix problem. After deleting Default Identity and Network/Sending and Network/Receiving settings and re-creating from scratch a new default identity, the problem was resolved and I was able to send mail again. Dist: Mandrake 10.0 Kmail vers: 1.6.1 (Using KDE 3.2 BRANCH >= 20040204 extracts from kmailrc [$Version] update_info=kmail.upd:1,kmail.upd:4,kmail.upd:5,kmail.upd:6,kmail.upd:7, kmail.upd:8,kmail.upd:9, kmail.upd:3.1-update-identities, kmail.upd:3.1-use-identity-uoids, kmail.upd:3.2-update-loop-on-goto-unread-settings, kmail.upd:3.1.4-dont-use-UOID-0-for-any-identity, kmail.upd:3.2-misc,kmail.upd:3.2-moves Comparing to the OLD version of kmailrc, in the working version the [Compose] current-transport= section is set to the same as the name= in [Transport 1] In the broken version, current-transport is set to a previous name of the sending transport I had used when setting/resetting in order to try and fix the problem. It looks to me as if current-transport is not being updated correctly if the Network/Sending transport is modified after initial setup. Therefore, the only way to fix it is to delete and recreate the default identity. The $version update list above seems relevant too, since several relate to identities. Can anyone else confirm this? regards Chris
I can confirm that the "current-transport" field in kmailrc is not updated, when I change the smtp entry name. The Transport1 entry is updated immediately without closing and restarting KMail, but NOT the current-transport field. However, even IF the entry matches an existing fully configured smtp account, I am still not able to send the e-mail and I receive the "Unrecognised transport protocol" error. I then tried a total new setup by deleting the kmailrc, deleting the entries in .kde/share/apps/kmail/imap. Still no success in sending. BTW, my sender address is set in the default identity (have only one anyway). Regards, Mike
I also find that it won't send. telnet smtp.sbcglobal.yahoo.com 25 Trying 66.163.171.137... Connected to smtp.sbcglobal.yahoo.com. Escape character is '^]'. 220 smtp812.mail.sc5.yahoo.com ESMTP ehlo 250-smtp812.mail.sc5.yahoo.com 250-AUTH LOGIN PLAIN 250-PIPELINING 250 8BITMIME My version is KMail 1.7 using KDE 3.3.0 from the SUSE rpms. I get the error: Sending failed: The message content was not accepted. The server responded: "See http://pobox.com/~djb/docs/smtplf.html. " The message will stay in the 'outbox' folder until you either fix the problem (e.g. a broken address) or remove the message from the 'outbox' folder. This link says: It was generated by qmail, an Internet message transfer agent. Your mailer tried to send an e-mail message to a server running qmail. Unfortunately, qmail spotted a problem: your mailer sent a bare LF. I hope this helps.
kde-3.3.1/kmail-1.7.1/compiled from sources. when i'm trying to send an email with attachment kmail reports an error: "sending failed: unknown error 50 (...) the server responded: xxx.xxx.xxx.xxx SMTP incoming data timeout - closing connection. (...) the following transport was used: exim@localhost" exim log: 2004-10-31 18:42:19 SMTP data timeout (message abandoned) on connection from localhost [127.0.0.1] when i select 'suggest automatic display' it sends email correctly.
Created attachment 8110 [details] testcase from outbox.
ps). 'suggest automatic display' helps only on text files.
all the points about transports not being updated after deletion, and empty from address in the identity have been fixed in KMail 3.4. Can you please check if that solves your issues and report back if they do not.
have any of you been able to test this with a more recent version of KMail?
Using SUSE9.3, newly loaded, testing KMAIL, no outgoing mail SMTP,(incoming IMAP fine) because of malformed header ( wrong address, non-existant URL ) the first time it brought up an error message, but the second message, held in the buffer, blocked me for 12 hours.... till I read this thread at 01:30 am. Maybe a simple fix is to flush messages to Trash ( sorry I have no pgming skls )on failure to send.
I can confirm this on SuSE 10.0, KDE 3.4.2 level B, kmail 1.8.2. This has happned twice for me. First time I gave up kmail and tried Evolution (only to give up in even more disgust after about one week). Got back to kmail (after fully un-installing kmail, deleting ~/.kde/share/kmail and ~/.kde/share/config/kmail*, and re-installing kmail). Reconfigured all my e-mail accounts, everything fine. After some few months (meanwhile changes we done to the configuration in almost all areas) I again cannot send to any account but the default one. I am not sure what goes on here. What would you need to find more about it?
OK. Further tests show that I can send only with an account that does not use authentication nor encryption. It does not matter if this account is the default or not. All other accounts use authentication/encryption, and all fail to send out. Interesting to note that, when looking at the account details (sending) the SMTP port is set to 25 and I cannot reset it. If I try to "Check what server supports, Kmail marks the server as TLS/plain, and sets the port to 25!!
Bis repetita after upgrading to KDE-3.5.2, rest is the same I have downloaded the sources, and will have a try on it -- since I am getting hit by it, and the developers are not, it stands to reason that I will have much more chances of finding out what goes on here. Also, given the amount of different errors reported here, I wonder if it might not be a better idea to open a new issue.
Anyone still seeing this in the latest version of KMail?
I'm closing this bug report because each KMail related issue mentioned here has its own individual report in bugzilla. This bug has become almost a dumping ground or a help center discussion for the many ways sending mail can break. Basically, we are taking the advice of comment #17 above. If you need help configuring KMail please consider subscribing to the kdepim-users mailing list. A definite bug with an easy work-around: make sure you have a sending account marked as "Default". Configure KMail->Accounts->Sending [Set as Default]
I had the same problem. If you're using a Gmail account, check your port number - 465 or 587 - and encryption type. Although "Check What The Server Supports" enables TLS encryption, it should have been SSL to work properly. Notice it also resets the port number to 25. But a Gmail Help page says it "requires TLS" and: "Use STARTTLS: Yes (some clients call this SSL)". More notes: 1) Other email clients have a "secure connection (SSL)" option. 2) I think the error message is not very helpful. I solved the problem when I ignored it. Regards