Bug 347781 - Regression - Kmail 4.14.6 Automatic determination of SMTP protocol (TLS and port) is broken on all providers
Summary: Regression - Kmail 4.14.6 Automatic determination of SMTP protocol (TLS and p...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kmail2
Classification: Applications
Component: config dialog (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR minor
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-16 08:00 UTC by stakanov.s
Modified: 2018-01-31 16:52 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description stakanov.s 2015-05-16 08:00:44 UTC
Go configure, accounts, sending. Set up an SMTP account and try to "automatically determine protocol".
Gives:
failure and wrong indications on all accounts, wrong port, wrong transport (no encryption instead of TLS 587).
Such failure will be nefast for the less proficient user and may induce usafe settings without any transport security. Proven with: freenet, web.de, proximus (skynet.be).
If set up by hand will work flawlessly. 

Reproducible: Always

Steps to Reproduce:
1. create smtp
2. ask for automatic determination of available transport
3. Gives "no method available, check transport" or an unsafe method without encryption will be proposed). 

Actual Results:  
transport smtp relevation in configuration - advanced is broken - unsafe 

Expected Results:  
should work out of the box (did in the past)

opensuse 13.2 from rpm

protocol hit was smtp with TLS on port 587 (failure is complete whatever provider). This is AFAIK a very common setting. 

Workaround: RTFM of the provider that however is often difficult to reach and to find. Many less proficient user will be dumped here.
Comment 1 Denis Kurz 2017-06-23 20:01:30 UTC
This bug has never been confirmed for a KDE PIM version that is based on KDE Frameworks (5.x). Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the oportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it.

Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Comment 2 Denis Kurz 2018-01-31 16:52:01 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.1 aka 15.12, preferably more recent), please open a new one unless it already exists. Thank you for all your input.