Bug 388068 - With the kmail version 5.7 can no longer send mails.
Summary: With the kmail version 5.7 can no longer send mails.
Status: REOPENED
Alias: None
Product: kmail2
Classification: Applications
Component: general (show other bugs)
Version: 5.7.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 388079 388325 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-12-20 11:41 UTC by Unknown
Modified: 2020-11-30 12:24 UTC (History)
22 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Unknown 2017-12-20 11:41:49 UTC
Hello,
With the kmail version 5.7 can no longer send mails.
The reception works.
Qt 5.10
KF 5.41
latest Version of Arch Linux
Greeting
Comment 1 Stephen Anthony 2017-12-20 13:48:15 UTC
Happens for me too with KDE Neon.
Comment 2 Olivier Churlaud 2017-12-20 19:17:23 UTC
*** Bug 388079 has been marked as a duplicate of this bug. ***
Comment 3 Olivier Churlaud 2017-12-20 19:18:24 UTC
The same here : nothing changed in the configuration, and it worked before. 

Thunderbird works fine with the configuration. 

=> The problem is in kmail/akonadi/pim
Comment 4 Frank Noack 2017-12-20 20:50:27 UTC
This problem arises if you use SSL encrpyption. Switching back to TLS solves the problem for the moment.
Comment 5 Stephen Anthony 2017-12-20 21:00:50 UTC
Switching to TLS for smtp.gmail.com doesn't work for me; it still complains about either "server error" or "mail transport failed".
Comment 6 Frank Noack 2017-12-20 21:18:15 UTC
is the port correct? And please restart Akonadi.
Comment 7 Stephen Anthony 2017-12-20 21:29:37 UTC
OK, checked port and restarted Akonadi.  Got a popup saying that the message was sent successfully.  On the console where I restarted Akonadi, I got message saying "org.kde.pim.ksmtp: Socket error: 2".

In any event, the test email(s) went through, so it seems to be working for TLS; I will leave it on that setting.
Comment 8 Gunter Ohrner 2017-12-21 08:46:38 UTC
Thanks, can confirm that switching from SSL to TLS also worked for me as a workaround.
Comment 9 Daniele 2017-12-22 10:18:20 UTC
Hi
Opensuse tumbleweed here.
Qt 5.9.3
KF 5.40
Akonadi 17.12
libtls16 2.6.3
libcrypto42 2.6.3
libssl44 2.6.3

With italian Aruba provider that uses TLS on port 25 and authentication PLAIN Kmail 5.7 no longer sends emails.
error message:
"Your SMTP server does not support PLAIN.
Choose a different authentication method.
The server responded: "5.7.0 ...authentication rejected"

Cheers
Comment 10 SFA 2017-12-22 10:18:34 UTC
Same issue with Tumbleweed, kmail 5.7 and latest akonadi

Switching from SSL->TLS works for sendinfg 1 email, then error again.
Comment 11 Unknown 2017-12-22 10:25:48 UTC
"Switching from SSL->TLS works for sendinfg 1 email, then error again."

Is the same with Arch Linux. I have the systen downgrade to 17.08
Comment 12 Luca Beltrame 2017-12-22 11:31:49 UTC
Potential fix to solve this issue is under review: https://phabricator.kde.org/D9476
Comment 13 Frank Noack 2017-12-22 12:12:36 UTC
The patch from  https://phabricator.kde.org/D9476 works for me.
Comment 14 Metko 2017-12-22 12:47:21 UTC
(In reply to Frank Noack from comment #13)
> The patch from  https://phabricator.kde.org/D9476 works for me.

Is it possible to get a binary patch somewhere?
Comment 15 Frank Noack 2017-12-22 12:56:07 UTC
I used the patch with Gentoo Linux which provides a simple way to patch files with a diff.
Comment 16 Mark Gannon 2017-12-22 16:24:14 UTC
Can you give a little more help on applying the patch on gentoo?  I tried the patch (renamed as smtpsend.patch) in /etc/portage/patches/kde-apps/kmailtransport-17.12.0/ and /etc/portage/patches/kde-apps/kmail-17.12.0 and then ran ebuild <ebuild file here> prepare and it failed in both cases.
Comment 17 Andreas Sturmlechner 2017-12-22 16:32:35 UTC
The correct package would be ksmtp. But you just need to sync, and 17.12.0-r1 will be available to you.
Comment 18 Daniele 2017-12-22 18:46:18 UTC
Hi 
Good work! the patch works on tumbleweed.
Thank you very much.

cheers

Daniele
Comment 19 Stephen Anthony 2017-12-22 18:58:01 UTC
Tangentially related to this issue; is it better to use SSL or TLS when a server offers both?  I've changed to TLS to 'work around' this current issue, but I wonder if I should just leave it that way, even when SSL is fixed.
Comment 20 Fabian Vogt 2017-12-23 12:09:34 UTC
Git commit ec2afd27c790fbde63a9c2bdd1f97a59fe04b18e by Fabian Vogt.
Committed on 23/12/2017 at 12:09.
Pushed by fvogt into branch 'Applications/17.12'.

Fix duplicate authentication

Summary:
The response to EHLO triggers an authentication command, but with TLS
two EHLOs are sent: For the 220 from the server and after TLS negotiation.
However, sending it twice results in an unexpected "503 already authenticated"
response which ends up getting parsed by the SendJob, causing confusion.

By leaving the EHLO-resending to the SessionPrivate, the state can be properly
tracked.
Related: bug 387926

Reviewers: mlaurent, dvratil

Subscribers: lbeltrame, cgiboudeaux

Differential Revision: https://phabricator.kde.org/D9476

M  +19   -10   src/session.cpp
M  +1    -0    src/session_p.h
M  +0    -1    src/sessionthread.cpp

https://commits.kde.org/ksmtp/ec2afd27c790fbde63a9c2bdd1f97a59fe04b18e
Comment 21 Martin Schnitkemper 2017-12-30 13:23:18 UTC
This problem is not limited to the SSL or TLS encryption, it still does not work with outgoing mails and attachments, regardless if encryption is active or not.  Latest ksmtp is installed, but does not solve the problem.  

I still get a server error, and no progress bar while sending, but the mail will be send in a background process and delivered to the receipient, but remains in the outgoing mail folder of kmail as unsent due to an error.

OS is Arch Linux.
Comment 22 Christoph Feck 2018-01-02 17:15:55 UTC
Martin, please report your issue as a new ticket, ideally providing the SMTP conversation log showing the error.
Comment 23 Christoph Feck 2018-01-02 17:18:47 UTC
*** Bug 388325 has been marked as a duplicate of this bug. ***
Comment 24 Martin Schnitkemper 2018-01-02 22:14:27 UTC
(In reply to Christoph Feck from comment #22)
> Martin, please report your issue as a new ticket, ideally providing the SMTP
> conversation log showing the error.
Of course, if someone can guide me how to get a SMTP log out of kmail.
Comment 25 Olivier Churlaud 2018-01-16 18:23:55 UTC
It worked, and it's back.

Last change on my computer is the update of the Frameworks 5.42
Comment 26 Kishore 2018-01-19 12:04:16 UTC
Here is the message i see from akonadi process (after akonadictl restart) on a gmail account. The UI notification reports "Failed to transport message. Server Error".

qt.network.ssl: QSslSocket::startClientEncryption: cannot start handshake on non-plain connection

KDE Neon user edition
Kontact 5.7.1
KDE Frameworks 5.42.0
Qt 5.9.3 (built against 5.9.3)
The xcb windowing system
Comment 27 Franco Pellegrini 2018-03-27 20:30:22 UTC
I am also seeing this issue. Nothing changed in the config, and cannot send mails... they remain in the outbox while it keeps failing and retrying... Eventually after some retries, it does send the email.

KDE Neon
Plasma: 5.12.3
Frameworks: 5.44.0
QT: 5.10.0
Kmail: 5.7.3

I don't know how to get a log out of it... if someone points me to it, I will be happy to upload it
Comment 28 Christophe Marin 2018-03-30 09:42:59 UTC
You already tried clicking on the "auto detect" button from the "advanced" tab of your account settings ?

(in KMail preferences / Accounts / Sending).
Comment 29 Cyrille Dunant 2018-03-30 09:45:49 UTC
As a comment -- I don't know if that helps -- I actually resolved the issue by reconfiguring everything from scratch.

My suspicion is that as I run git snapshots, the configuration sometimes gets muddled up, and it results in things like emails not being sent.
Comment 30 spam 2018-04-03 02:22:32 UTC
I have this problem too. Every once upon a miracle mail does get sent. Normally, however it's not sending.

Here's SMTP session log:

S: 220-domain.tld ESMTP Postfix (Debian/GNU)
C: EHLO hostname.localnet
S: 250-domain.tld
S: 250-SIZE 10485760
S: 250-ETRN
S: 250-STARTTLS
S: 250-ENHANCEDSTATUSCODES
S: 250-8BITMIME
S: 250-DSN
S: 250 SMTPUTF8
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
C: EHLO hostname.localnet
S: 250-domain.tld
S: 250-SIZE 10485760
S: 250-ETRN
S: 250-ENHANCEDSTATUSCODES
S: 250-8BITMIME
S: 250-DSN
S: 250 SMTPUTF8

I'm running debian and kmailtransport is version 17.12.3-1
Mail sending works with different clients.
Comment 31 Taras 2018-05-22 20:27:31 UTC
Hello!

Also have this bug in Kmail 5.7.3 on Fedora 28 but **only** for Gmail. OAuth is used for IMAP and it works. For SMTP have to use generated application password (see https://support.google.com/accounts/answer/185833). KMail can't send emails via Gmail account in this use case. Unfortunately can't find out how to grab SMTP session log in Akonadi.

P.S. FYI "OAuth via SMTP (for Gmail only for now) has been merged into current development branch and will be available in the August release of KDE Applications." https://forum.kde.org/viewtopic.php?f=215&t=140338#p397756
Comment 32 DeMus 2018-05-30 08:56:46 UTC
Qt5.11, Plasma 5.12.5, Frameworks 5.46.0, Kontact 5.8.1
Outgoing mails are sent back from draft to the local folders Outbox and stay there, after some time I receive a notification there is a time-out.
Tried downgrading, doesn't work, tried exchange SSl to TSL, didn't work.
Comment 33 Franco Pellegrini 2018-11-21 21:23:35 UTC
This is no longer happening to me in latest versions
Comment 34 leftcrane 2020-08-03 19:16:58 UTC
Still happening. Kmail fails to send emails at random times with this error message.
Comment 35 leftcrane 2020-08-03 19:22:45 UTC
Seeing tons "no carrier" messages from various agents in Akonadi console when this happens. Takes a couple round of restarting/killing kmail to get it working again.

I use Gmail btw
Comment 36 leftcrane 2020-11-30 12:11:08 UTC
The bandaid here is *aborting the activity* of the "Mail Dispatcher Agent" and restarting it. This is the only solution that works.
Comment 37 leftcrane 2020-11-30 12:24:57 UTC
Aborting the dispatcher will fix the problem of emails silently getting stuck in the outbox. 

However, it will not fix the new bug I've discovered (since upgrade to Version 5.15.1) wherein the composer window gets grayed out after hitting send. It will stay that way indefinitely and nothing will be sent. I have not discovered a "fix" for this.

Sometimes emails do get sent out, but whenever they do you get a prompt to create a duplicate address book entry for the recipient (i.e, asks to save a contact that's already been saved and auto-suggested by Kmail in the field). Here of course you have to hit dismiss.

I know all these bugs should be filed separately. But the problem with sending are so numerous and intractable that I can't justify putting in the effort.