Since a couple days I cannot send email with port=587 encryption=TLS, authentication=PLAIN I get the message Failed to transport message. Error during SSL handshake: error:1408F10B:SSL routines:ssl3_get_record:wrong version number I'm guessing this is coming from ksmtp, but it could also be coming from kdepim-runtime/agents/maildispatcher I can send email from thunderbird just fine using this setup and have been sending mail from Kontact for a long time without problems.
Did you try opening your smtp settings and press "auto detect" ?
yes. no joy. same error.
I confirm it too.
Just tested with master and mail.gandi.net, using STARTTLS/587 with a PLAIN auth without issue.
I tested a couple others I use daily with the same connection settings - gmx.com, infomaniak.com - and I tested gmail without getting errors.
I'm using Fedora 27, if that matters All distro updates applied. rebooted. same problem. I even tried reverting back 2 weeks in ksmtp and kdepim-runtime. stumped
sending mail works fine with the Fedora27 distro Kontact. which seems to indicate the problem is with a source code change somewhere in the Kmail stack. I reverted back to ksmtp and kdepim-runtime from April 10 but that didn't help. any ideas which other project(s) might be the causing the problem, besides ksmtp and kdepim-runtime?
(In reply to Allen Winter from comment #7) > I reverted back to ksmtp and kdepim-runtime from April 10 but that didn't > help. > any ideas which other project(s) might be the causing the problem, besides > ksmtp and kdepim-runtime? kmailtransport
Allen, Laurent, can you guys double-check that you have STARTTLS selected in your outgoing account settings? Maybe even try to create a new transport that's configured for STARTTLS? It looks like KSMTP is trying to open an encrypted communication despite being configured for STARTTLS (and then complains it does not understand the unencrypted response coming from the server). It seems to work for me here - I can't login anymore of course, but I actually get "Password refused" error from the SMTP server, which means the encrypted communication is established correctly.
This is solved Yay! I removed my distro mailtransport plugin: rpm --nodeps --erase kf5-kmailtransport the distro plugin is in /usr/lib64/qt5/plugins and /usr/lib64/qt5/plugins/mailtransport my hand-build plugs is in $KDE_PREFIX/lib64/plugins and $KDE_PREFIX/lib64/plugins/mailtransport I wonder if $KDE_PREFIX/lib64/plugins/mailtransport needs to be put into QT_PLUGIN_PATH?? I'll mark this resolved but I'd like to know if I should adapt my environment so this doesn't happen again. or perhaps the the stuff under mailtransport/ should be installed 1-level up
Do you have $KDE_PREFIX/lib64/plugins in your QT_PLUGIN_PATH? That's should be good enough - the code looks for the KMailTransport plugins in $QT_PLUGIN_PATH/mailtransport - at least for me it works this way just fine.
Yes, my $QT_PLUGIN_PATH looks fine. I played with a few things and nothing worked except for removing the distro plugin for mailtransport_smtpplugin.so I wonder if there's a .qtconf file somewhere that is overriding QT_PLUGIN_PATH oh well, at least the immediate crisis is solved.