"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.

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!

adding usability keyword

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.

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.

adding string keyword, raising severity - i had to explain this too many times already

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. :-)

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.

        { 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: ?

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.

Fejj: My guess is that common users may know what TLS / SSL is. I prefer the strings with both specified.

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.

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 ** ;-)

fejj, agree on that point :). Lets try out SSL / TLS. Andre: you have a patch? :)

no, not yet, but i can do this. gotta sleep now. :-)

Created attachment 59104 [details] [review]
proposed fix for the UI part

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.

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. :)

Created attachment 59114 [details] [review]
proposed fix, take 2

Pimped the patch by adding a descriptive translator comment.

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. ;-)

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.

Created attachment 59121 [details] [review]
proposed fix, the "happy translators" take

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

Created attachment 59122 [details] [review]
oops ;)

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. :-/

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. :)

guenther: Patch looks fine to commit.

Andre: Make sense to fix that as well.

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.

as we've changed the irritating strings, targetting this to 2.5.

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.

/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.

kinda, yeah.

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...

Mailer issue. Reassigning it to partha.

Created attachment 64067 [details] [review]
321797.patch

patch stops any/all fallback for SSL/TLS

fixed in CVS

May I ask which release this fix is targetted for?

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. ;-)

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.

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. :-(

*** Bug 339939 has been marked as a duplicate of this bug. ***

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?

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.

(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.

what about my previous comment and the upgrade path? you will force distros to divert from upstream other way