After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 321797 - change mailer and ldap backend code for TLS / SSL
change mailer and ldap backend code for TLS / SSL
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.8.x (obsolete)
Other Linux
: Normal minor
: ---
Assigned To: parthasarathi susarla
Evolution QA team
: 339939 (view as bug list)
Depends on:
Blocks: 230402 327508
 
 
Reported: 2005-11-18 12:20 UTC by Daniel Holbach
Modified: 2013-09-13 00:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed fix for the UI part (1.22 KB, patch)
2006-02-10 21:17 UTC, Karsten Bräckelmann
none Details | Review
proposed fix, take 2 (1.56 KB, patch)
2006-02-10 23:52 UTC, Karsten Bräckelmann
none Details | Review
proposed fix, take 3 (1.63 KB, patch)
2006-02-11 05:07 UTC, Karsten Bräckelmann
none Details | Review
proposed fix, the "happy translators" take (1.85 KB, patch)
2006-02-11 05:27 UTC, Karsten Bräckelmann
none Details | Review
oops ;) (1.85 KB, patch)
2006-02-11 05:30 UTC, Karsten Bräckelmann
committed Details | Review
321797.patch (6.30 KB, patch)
2006-04-21 18:58 UTC, Jeffrey Stedfast
committed Details | Review

Description Daniel Holbach 2005-11-18 12:20:13 UTC
Version details: 2.4.1
Distribution/Version: Ubuntu Breezy

Forwarded from http://bugzilla.ubuntu.com/show_bug.cgi?id=18305

Using Ubuntu 5.10, Evolution 2.4.1.

In Edit/Preferences/Accounts/Edit/Sending Email, there is a combobox offering
"never", "whenever possible", and "always" as choices for a secure connection.
Choosing the "whenever possible" option, it would seem that SSMTP (port 465)
would be checked first, but this does not seem to be the case.

At work I have firewall settings such that SMTP (port 25) is blocked, but SSMTP
is not. Using the "always" setting I can send mail, but using the "whenever
possible" setting I get "no route to host". This seems unintuitive, and I think
the correct behavior would be for this to work.
Comment 1 André Klapper 2005-11-20 10:54:50 UTC
"use secure connection always" is ssl, using "whenever possible" is tls.
you can also set the port directly by adding a semicolon and the port number
after the server address, e.g. "smtp.example.com:465".

setting to NEEDINFO, please REOPEN when you add a comment. thanks in advance.
Comment 2 Daniel Holbach 2005-11-22 12:09:42 UTC
New user comment:

Be that as it may, it seems that the combobox is at least confusing, in that it
shows "never", "whenever possible", and "always". The first one gives SMTP, the
last one SSMTP, and so I find it quite reasonable to assume to the  "whenever
possible" option first tries SSMTP, and, should it fail, go back to SMTP. Maybe
it would be useful to give choices "never (SMTP)", "always (SSMTP)", or "custom"
and then people can enter the port themselves.

This is not a "it doesn't work" bug, it's a "descriptions are unclear" bug.
Thank you for your time!
Comment 3 parthasarathi susarla 2005-11-22 13:20:37 UTC
adding usability keyword
Comment 4 Srinivasa Ragavan 2005-11-22 13:54:15 UTC
I guess, it has nothing to do in UI. I dont think, we need to add SMTP or SSMTP
to the combo box. It has user level terms like Always Secure or Never, which in
technical terms means the same.

With 'Whenever possible', it should try SSMTP and incase of a failure it should
fallback to SMTP, ideally. If not, that is a bug that needs to be fixed, i feel.

Please correct me if my understandings are incorrect.
Comment 5 Srinivasa Ragavan 2005-11-22 14:19:12 UTC
Sorry guys, thanks to partha on clearing the doubts on this.
My earlier point is not right. Please ignore that.

Always is SSL (SSMTP)
Never is unsecure (SMTP)
When ever is TLS (SMTP) It happens over the transport layer.

i dont think, we can fix this at the Combo box level. I would suggest that these
details should go to help and documentation, troubleshooting. So that one who
does these can really understand. And the account creation/Edit is a too smaller
place to put such details and most users dont even know what these
protocols/security/tcpip layers.

Please put forward your point.
Comment 6 André Klapper 2006-01-11 10:48:10 UTC
adding string keyword, raising severity - i had to explain this too many times already
Comment 7 André Klapper 2006-02-07 08:47:30 UTC
evolution/mail/em-account-editor-c:

static struct {
	char *label;
	char *value;
} ssl_options[] = {
	{ N_("Never"), "never" },
	{ N_("Whenever Possible"), "when-possible" },
	{ N_("Always"), "always" }
};

don't always argue that stupid gnome users could be misguided by an additional term like "SSL". also think of administrators or medium users which definitely get misguided by stupid and vague options, and volunteers answering the same user question on the mailing lists or on irc over and over again. i am sick of explaining that "always" means "SSL" while "Whenever possible" actually means "TLS". "Whenever possible" also implies that you do not know *if* you have a secure connection, which can be misleading.

so please add this information to the strings.
now.
monday is string freeze.
thanks in advance.

my proposal (please improve):
	{ N_("Never"), "never" },
	/* Translators: this is an "Use secure connection" option: */
	{ N_("Whenever Possible (TLS)"), "when-possible" },
	/* Translators: this is an "Use secure connection" option: */
	{ N_("Always (SSL)"), "always" }

quoting partha from evolution users mailing list (dec 13th, 2005) regarding this bug report here: "the options are way too vague, and i am trying real hard to get the sorted out for the coming release."
so partha, srag, what's up? make the gnome-2.14 world an even better one and fix this, or at least tell me what to commit. :-)
Comment 8 André Klapper 2006-02-07 08:54:52 UTC
please do NOT state that this should only go into help. options just be clear and not a vague "whenever possible" if it means something totally different. this is a string *bug*, and not an "add a sentence to the docs" enhancement.
Comment 9 Srinivasa Ragavan 2006-02-07 09:26:36 UTC
        { N_("Never"), "never" },
        /* Translators: this is an "Use secure connection" option: */
        { N_("Whenever Possible (TLS)"), "when-possible" },
        /* Translators: this is an "Use secure connection" option: */
        { N_("Always (SSL)"), "always" }

This Looks fine for me,instead of just SMTP/ SSMTP or SSL/TLS etc... 

Partha: ?
Comment 10 Jeffrey Stedfast 2006-02-07 15:51:14 UTC
Honestly I think an even better menu would simply be:

Never
TLS
SSL

leave out "Always" and "Whenever Possible" altogether. If you keep those strings, it's still "confusing" imho.

Also, the backend code *may* have to be changed such that neither option falls back to something else.
Comment 11 Srinivasa Ragavan 2006-02-07 17:56:26 UTC
Fejj: My guess is that common users may know what TLS / SSL is. I prefer the strings with both specified.
Comment 12 Jeffrey Stedfast 2006-02-07 20:05:57 UTC
ok, but Whenever Possible still prsents confusion. What will it mean exactly?

will it mean it'll use TLS whenever it is available and fallback to cleartext if not? But that's not what a user will want... he'll want to select TLS and have it use TLS or fail.
Comment 13 André Klapper 2006-02-08 00:33:02 UTC
right. it just leads me to the confusion that i cannot be sure if i have a secure connection at all - so it's meaningless.
if i use the wireless lan of my university, i just cannot dare to submit my passwords as clear text, so only using encryption "*whenever* possible" sounds way too dangerous to me - i would not use it at all, because i don't know what i get.

i second jeff now.

** this is the standard "monday is string freeze" footer ** ;-)
Comment 14 Srinivasa Ragavan 2006-02-08 02:33:26 UTC
fejj, agree on that point :). Lets try out SSL / TLS. Andre: you have a patch? :)
Comment 15 André Klapper 2006-02-08 02:40:14 UTC
no, not yet, but i can do this. gotta sleep now. :-)
Comment 16 Karsten Bräckelmann 2006-02-10 21:17:02 UTC
Created attachment 59104 [details] [review]
proposed fix for the UI part
Comment 17 Karsten Bräckelmann 2006-02-10 21:20:58 UTC
I strogly agree with Jeff in comment 10. There is no need for obscure strings. ISPs will tell their users to use SSL, no other phrase.

The above patch fixes the UI issue. This needs to be approved and committed before String Freeze on Monday. The backend code should be reviewed, in case there is any fallback logic that breaks this explicite option. Can be done after String Freeze.
Comment 18 Karsten Bräckelmann 2006-02-10 23:37:11 UTC
Entirely agree with comment 7 as well. The users are not dumb. Period. And the currently obfuscated atrings are confusing and misleading even to knowledgeable users. This can be seen on the mailing lists.

ISPs do tell teir users to enable "SSL", if they do support it. They never tell their users to "try using some security, if you find it" or something like this. Just use the terms that really are correct. TLS is not "whenever possible. The reporter explained the meaning of "whenever possible" correctly.

FWIW: I do *not* agree with comment 5. A single combobox that *needs* the user to have a look at the documentation? Don't think so. The UI should be as self descriptive as possible. Additional information in the docs is fine. But if you ever expect the average user will have to consult the docs to change some very basic settings, the UI simply is fucked up and needs to be corrected. IMHO.

Agreed to comment 12 and comment 14 too, FWIW. :)
Comment 19 Karsten Bräckelmann 2006-02-10 23:52:12 UTC
Created attachment 59114 [details] [review]
proposed fix, take 2

Pimped the patch by adding a descriptive translator comment.
Comment 20 Karsten Bräckelmann 2006-02-10 23:56:58 UTC
Since "Always" and "Whenever possible" finally is going to die, "Never" doesn't feel right any longer as well. This probably should be plain "No"...

Another approach to distinguish these options correctly probably would be:
Use secure connection: {"No", "Yes, TLS", "Yes, SSL"}. But then this might be overkill and ugly. ;-)
Comment 21 Karsten Bräckelmann 2006-02-11 05:07:34 UTC
Created attachment 59120 [details] [review]
proposed fix, take 3

As per discussion on IRC:

* Make the strings way more descriptive
  (as they used to be for a short period in time, *sigh*)
* Moved translator comment, to make it useful.
Comment 22 Karsten Bräckelmann 2006-02-11 05:27:06 UTC
Created attachment 59121 [details] [review]
proposed fix, the "happy translators" take
Comment 23 André Klapper 2006-02-11 05:29:16 UTC
fyi:

the current strings were introduced at
http://cvs.gnome.org/viewcvs/evolution/mail/em-account-editor.c?r1=1.7&r2=1.8

they are also the original strings:
http://cvs.gnome.org/viewcvs/evolution/mail/em-account-editor.c?r1=1.2&r2=1.3
Comment 24 Karsten Bräckelmann 2006-02-11 05:30:03 UTC
Created attachment 59122 [details] [review]
oops ;)
Comment 25 André Klapper 2006-02-11 05:41:46 UTC
srag,
what's up with the same strings regarding ldap at /addressbook/gui/component/ldap-config.glade ?

also change them? the comments would also have to be changed, are they correct at all (one states that evo both tries ssl *and* tls; the "whenever possible" one could also be wrong)?

please post an explicit proposal for thst file *and* its comments, so we can get this in. :-/
Comment 26 Karsten Bräckelmann 2006-02-11 05:44:59 UTC
And please do not forget: Get this patch in by Mon. And review the Mailer code to actually do what the user wants. No fallback, no magic, no fu. :)
Comment 27 Srinivasa Ragavan 2006-02-13 05:28:58 UTC
guenther: Patch looks fine to commit.

Andre: Make sense to fix that as well.
Comment 28 André Klapper 2006-02-13 14:45:51 UTC
the UI part is fixed:
http://cvs.gnome.org/viewcvs/evolution/addressbook/gui/component/ldap-config.glade?r1=1.38&r2=1.39
http://cvs.gnome.org/viewcvs/evolution/mail/em-account-editor.c?r1=1.42&r2=1.43

now the mailer/ldap backend code has to be checked *not* to fallback on other stuff, or even use an unsecure connection.
Comment 29 André Klapper 2006-02-18 12:20:47 UTC
as we've changed the irritating strings, targetting this to 2.5.
Comment 30 André Klapper 2006-04-20 20:21:52 UTC
backend code obviuosly has not been changed. i can access my pop mails by using the tls encryption setting, though i don't use tls. this is evo 2.7.
Comment 31 Karsten Bräckelmann 2006-04-20 20:23:58 UTC
/me curses mid air collisions


If the user chooses to use a TLS encrypted connection, Evo MUST use TLS
and MUST NOT fall back to unencrypted. Ever. Period.

This is a serurity issue.

Blocker. Target for 2.6.x, the current stable release.
Comment 32 André Klapper 2006-04-20 20:26:01 UTC
kinda, yeah.
Comment 33 Karsten Bräckelmann 2006-04-20 20:31:10 UTC
Given that Evolution used to be broken in this regard, here is a VERY BAD side note:

* Since "whenever possible" used to work for ISPs that do not support TLS,
  changing the backend code will bite those users. The 2.6.x options clearly
  state "TLS", but it works without encryption, too. Once we change this, all
  users that used to use "whenever possible" with the fallback to no encryption,
  will not be able to retrieve their mail after updating.

This really is bad...
Comment 34 Srinivasa Ragavan 2006-04-21 18:27:53 UTC
Mailer issue. Reassigning it to partha.
Comment 35 Jeffrey Stedfast 2006-04-21 18:58:30 UTC
Created attachment 64067 [details] [review]
321797.patch

patch stops any/all fallback for SSL/TLS
Comment 36 Jeffrey Stedfast 2006-04-24 15:24:26 UTC
fixed in CVS
Comment 37 Daniel Holbach 2006-04-24 15:31:18 UTC
May I ask which release this fix is targetted for?
Comment 38 André Klapper 2006-04-24 15:49:41 UTC
daniel: it's been committed both to head and gnome-2-14 branch, and 2.6.1 and 2.7.1 are already out, so it will be part of 2.6.2 and 2.7.2.

i just ask myself if we also have to change any fallback code for ldap... after a quick grep i guess that the answer is "no".

...so let's get prepared for users unable to access their mail now, because the fallback code is gone. i am one of them. ;-)
Comment 39 Daniel Holbach 2006-04-24 16:00:00 UTC
Thanks a lot, I'm happy to hear that it's fixed. I hope the best for you, André :-)

2.14.2 will be too late for us, so we'll maybe have to patch evolution for Ubuntu Dapper release.
Comment 40 André Klapper 2006-04-25 23:47:20 UTC
ok, i'm one of these users who used the "whenever possible" setting. this changed to the label "TLS" now, but of course i haven't looked into my settings for years, why should i, it always WORKEDFORME(TM).
so suddenly now i get a pop-up which says "Could not connect to pop.example.com: SSL unavailable", which is part of e-d-s.
i know, i can access my pop mail by changing the "TLS" setting to "No encrpytion". 

but the "SSL" message is totally misleading, that's the issue - this is not about SSL at all, but TLS is failing.

comments?

in evolution's po file, we already have a message "TLS not Available" (yes, i see the typo). but not in evolution-data-server's po file, so fixing this for 2.6 would break the string freeze.
(unimportant note: "TLS not Available" and "SSL unavailable" could also be harmonized.)

reopening, sorry. :-(
Comment 41 André Klapper 2006-04-27 18:28:38 UTC
*** Bug 339939 has been marked as a duplicate of this bug. ***
Comment 42 Sebastien Bacher 2006-05-03 17:08:52 UTC
We just had a discussion for Ubuntu about that. Breaking user configuration on upgrade is not nice. Why is the TLS with fallback mode an issue? What is wrong about having a fallback? That option works fine for many people. Maybe if you want a strict TLS option you could add one mode:
* no encryption
* TLS with fallback
* TLS
* SSL

That way working configuration would keep working with any modification required for the user and a "strict TLS mode" would be available?
Comment 43 Sam Morris 2006-05-03 17:21:38 UTC
Might as well make the selection into this then:

 * attempt TLS (default)
 * TLS only
 * SSL only

On no account should my password be disclosed over a non-secure connection if I have picked TLS in the preferences.
Comment 44 André Klapper 2006-06-01 12:09:29 UTC
(refering to comment 40):
fixed by fejj's patch for bug 342001:
http://cvs.gnome.org/viewcvs/evolution-data-server/camel/providers/pop3/camel-pop3-store.c?r1=1.125&r2=1.126

closing, finally.
Comment 45 Sebastien Bacher 2006-06-04 12:55:33 UTC
what about my previous comment and the upgrade path? you will force distros to divert from upstream other way