527078 - smtp with user/password refused after migration

Status: RESOLVED DUPLICATE of bug 524868

(SeaMonkey :: MailNews: Backend, defect)

Description

[Jean-François Perron]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0

smtp.free.fr
port 25
use user/password (correctly set) 
STARTTLS if available
works for SM 1.1.18
but after migration in SM 2.0 this does not work
STARTTLS if available appears greyed
I specify no secure connexion
does not work either
I set no user/pass
and this work

I had many smtp with user/pass ok in SM 1.1.18
(I tested again)

Reproducible: Always

Actual Results:  
I have to modify smtp settings
suppress SARTTLS if available
suppress user/pass

Expected Results:  
SM 2.0 could work identically as SM 1.1.18


I hope there is no problem behind the suppression of user/pass authentication

Comment 1

[rsx11m]

Requirements have changed in the new release and are now more strict. The option "STARTTLS if available" is only supported for accounts which have been set up with that option, but not for new accounts (the reason being that if a server supports encryption, it should be selected, but then it's not good to fall back to an unencrypted line in the future with the user thinking that it is working). Similarly, providing a user name and password for a server which doesn't request one is now an error as well.

See related bug 522633, and bug 524868 with a report similar to yours.

Comment 2

[rsx11m]

It's actually not just similar but the same, thus duping, even though it may
be covered by a more comprehensive solution for bug 522633 or just added to a release note as known issue.

Comment 3

[Jean-François Perron]

(In reply to comment #1)
> Requirements have changed in the new release and are now more strict. The
> option "STARTTLS if available" is only supported for accounts which have been
> set up with that option, but not for new accounts (the reason being that if a
> server supports encryption, it should be selected, but then it's not good to
> fall back to an unencrypted line in the future with the user thinking that it
> is working). Similarly, providing a user name and password for a server which
> doesn't request one is now an error as well.

I think that it was done like that for a user who is not every time in the same place, so not using his own provider every time
So I could hope that authentication is better than none at all  even if the link is not secure. But in practice this does not happens, the roaming provider in general have a smtp without auth required, but it's not always the case.
If I do not set his own smtp, I can see some error messages like "we don't relay" or else.
In the case I had in SM 2.0 the error message was not clear at all.
 
> See related bug 522633, and bug 524868 with a report similar to yours.

If a change of using has to take place, this have to be more clearly documented for every day users, and if possible explained in a way that they can agree. the bug 522633 is not understandable for me.

Comment 4

[rsx11m]

The discussion on the "STARTTLS if available" was in bug 350314, if I found the right one. I agree that this may be an issue if a server requires authentication depending on your location (whether you are trying to send from a "trusted" or an "untrusted" network). Bouncing forth and back between secure and unsecure connection/authentication was considered a problem. The workaround would imply to define two different SMTP servers, one without authentication and connection security, the other one with. I don't see an easy way how to resolve that without reintroducing the ambiguity again whether the authentication information is sent securely or not.

Comment 5

[Jean-François Perron]

I cannot understand why this would be an error of the user to set a valid user/password for SMTP access, as far as this SMTP accept this user/password, even if it could do it without, as it was done in SM 1.1.18 and precedents, if sent from a trusted network.
On an untrusted network, it is mandatory to authenticate with user/password.

Of course the user should know if his connection is secure or not, but unfortunately, he has not so much choice, but I agree that he should be warned.

I suggest the status of this bug cannot be set as resolved with no proof that setting authentication in SMTP is an error of the user.

Comment 6

[rsx11m]

This specific bug was resolved, but not because the issue was considered resolved, rather because your main point

> use user/password (correctly set)
> but after migration in SM 2.0 this does not work

> I set no user/pass
> and this work

was already filed as bug 524868, hence it's a duplicate. Thus, you should add further comments on not considering having a user name and password set for a server which doesn't require it to that bug instead, to avoid that arguments are spread across multiple bugs on the same issue. Authentication security is the subject of bug 522633, and I've summarized your comment #3 there. The rest will be up for the module owners and release drivers to decide.