524868 - Seamonkey 2.0 SMTP Mail won't send after upgrade from 1.1.17 (authentication configured but not requested by server)

Status: RESOLVED DUPLICATE of bug 522633

(MailNews Core :: Networking: SMTP, defect)

Description

[David]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.22) Gecko/20090605 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.22) Gecko/20090605 Firefox/2.0

Previous outgoing SMTP server settings were: TLS if available. 
After loading Seamonkey 2.0, mail sending does not work. 
Setting or unsetting the "Use secure authentication" and selecting None or starttls makes no difference. 

Reproducible: Always

Steps to Reproduce:
1. Create a new message
2. Press send
3.
Actual Results:  
Get an error message, can't send, something to do with IPS can't handle security, even when it is switched off.

Expected Results:  
Send the message

Comment 1

[rsx11m]

Can you compare the Outgoing Server (SMTP) settings between 1.1.18 and 2.0?
Watch for identical port settings (25 or 587?), and also correct associations between accounts and SMTP servers in the main page of your accounts (if you have multiple SMTP servers defined).

What is the exact error message? You can remove the name of the account or server if you don't want to post those publicly, but it may help to narrow down if it's generated by SeaMonkey or the server itself.

Comment 2

[David]

From account: Use Default Server

Outgoing Server Default :
Server name: is correct
Port: 25 - is correct
Ticked: use name and password 
User Name: is correct

Tried:
Not Ticked: Use secure authentication
Connection Security: None
Send Message Error !
Sending of message failed.
An error occurred sending mail: Unable to authenticate to SMTP server smtp.xnet.co.nz. It does not support authentication (SMTP-AUTH) but you have chosen to use authentication. Uncheck 'Use name and password' for that server or contact your service provider.

Ticked: Use secure authentication
Connection Security: None
Sending of message failed.
An error occurred sending mail: Unable to establish a secure link with SMTP server smtp.xnet.co.nz using STARTTLS since it doesn't advertise that feature. Switch off STARTTLS for that server or contact your service provider.


UnTicked: use name and password 
Sending of message failed.
An error occurred sending mail: Unable to establish a secure link with SMTP server smtp.xnet.co.nz using STARTTLS since it doesn't advertise that feature. Switch off STARTTLS for that server or contact your service provider.


Ticked: use name and password 
Ticked: Use secure authentication
Connection Security: SSL/TLS
Port 25
Sending of message failed.
Please verify that your Mail & Newsgroups account settings are correct and try again.

Comment 3

[[e-mail]]

(In reply to comment #2)
> From account: Use Default Server
> 
> Outgoing Server Default :
> Server name: is correct
> Port: 25 - is correct
> Ticked: use name and password 
> User Name: is correct
> 
> Tried:
> Not Ticked: Use secure authentication
> Connection Security: None
> Send Message Error !
> Sending of message failed.
> An error occurred sending mail: Unable to authenticate to SMTP server
> smtp.xnet.co.nz. It does not support authentication (SMTP-AUTH) but you have
> chosen to use authentication. Uncheck 'Use name and password' for that server
> or contact your service provider.
So you tried a number of combinations, but unless I overlooked something, I don't think you have tried the following combination:
Not Ticked: Use username and password
Not Ticked: Use secure authentication
Connection Security: None

Comment 4

[rsx11m]

I'm unable to connect to your server as I'm coming from "outside" their network. Thus, it's likely that you don't need authentication at all when connecting from "inside" the network and unchecking the username/password box indeed should resolve the issue.

Comment 5

[David]

Correct, I thought I had tried all combinations, but obviously not as all unchecked and "none" works now Thanks.

Comment 6

[rsx11m]

Neil, Ian: Can this be closed WFM or anything that would need to be done in
the migration management to catch those cases? This is more obvious than the GSSAPI ambiguity in bug 522633 and comes with a more specific error message.

Comment 8

[rsx11m]

There was a suggestion in bug 311657 comment #46 to improve the dialog box popping up for the "user/password set but not used" case and allow the user to change the setting on the fly. Given the use case in bug 527078 comment #3 of connecting from both trusted and untrusted networks to the same server with varying requirements on authentication, another option may be to just pop up the message as a notification to the user, but to allow a connection anyway as no authentication is actually sent over the wire.

Some improvement of the NS_ERROR_COULD_NOT_LOGIN_TO_SMTP_SERVER_AUTH_NONE message #12581 may also help, but won't be possible for the current releases any more due to the string freezes.

Confirming as an SMTP core bug. There is room for improvement of the current behavior, it is unclear if bug 522633 will or will not take care of this case.

Comment 10

[Robert Kaiser]

What exactly is the phenomenon and the workaround (step-by-step, please) here?

Comment 11

[Robert Kaiser]

(And please confirm that it still happens on current nightlies or on 2.0.1)

Comment 12

[rsx11m]

There are various bugs now pending on this issue with two major flavors:

1. Users had authentication set in the old branch, but the server does not
   request is, therefore an error is reported and user has to take action
   to find the server and remove the authentication setting;

2. users needed different settings depending on whether they connect from a
   trusted or untrusted network, which after migration now requires two
   alternate configurations for both scenarios (in the old branch, given that
   authentication was ignored if not requested, the same setting could be used
   for both scenarios).

I don't see any indication that this behavior was changed, judging from the patches checked in (I don't have a server to test this with myself).

(Quoting bug 534111 comment #4)
> [workaround case #1] In Tools > Account Settings, in the list on the left, go
> all the way down to "Outgoing Server (SMTP)" and select the RoadRunner server.
> Click on Edit and uncheck "Use name and password" there. You may still need
> authentication for your incoming server to pick up your mail.

(Quoting bug 534111 comment #10, also see bug 534158)
> In essence, this is what bug 527078 comment #3 was asking for, which was duped
> against bug 524868. The underlying problem is that it is now considered a
> "hard" error if authentication is configured but not asked for by the server.
> If the server distinguishes between trusted and untrusted connections, this
> requires to specify two separate SMTP servers for the same connection and to
> switch between them as necessary. The other issue for which this bug was opened
> and which is covered in bug 524868 too is that the error message may not be
> easy to understand, and that the dialog doesn't offer a button to unset
> authentication (either for that specific connection or in general for all
> future connections for this server as well). These two cases are close and need
> a common solution anyway.

Comment 13

[rsx11m]

Attachment: Dialog for authentication during account setup

> 1. Users had authentication set in the old branch, but the server does not
>    request is, therefore an error is reported and user has to take action
>    to find the server and remove the authentication setting;

I'm trying to understand why so many users migrating from the old branch apparently have issues now migrating to the new branch and run into this.

Looking at the account wizard of the 1.8.1 branch (which is still the same in SeaMonkey 2.0), this dialog is pref-filled with incoming and outgoing user name for authentication. Thus, a user who just clicks the Next button here has set authentication for the SMTP server. Even worse, removing the user name from the outgoing server still sets it to the same name as the incoming server and has "use name and password" checked (that's a bug on its own). Consequently, *any* user migrating to the new releases with an SMTP server not requiring user name and password will receive the authentication error message now.

Comment 15

[rsx11m]

(Follow-up to comment #12)
> 
> 2. users needed different settings depending on whether they connect from a
>    trusted or untrusted network, which after migration now requires two
>    alternate configurations for both scenarios (in the old branch, given that
>    authentication was ignored if not requested, the same setting could be used
>    for both scenarios).

While a specific problem could be resolved in bug 534111, it's nevertheless a valid use scenario supported by RFC 4409 Section 4.3 (bug 534158 comment #20).

Comment 16

[Jean-François Perron]

(In reply to comment #15)
> (Follow-up to comment #12)
> > 
> > 2. users needed different settings depending on whether they connect from a
> >    trusted or untrusted network, which after migration now requires two
> >    alternate configurations for both scenarios (in the old branch, given that
> >    authentication was ignored if not requested, the same setting could be used
> >    for both scenarios).
> 
> While a specific problem could be resolved in bug 534111, it's nevertheless a
> valid use scenario supported by RFC 4409 Section 4.3 (bug 534158 comment #20).

I think this point of RFC 4409 has to be applied by the relationship between the provider and his client. Seamonkey has no responsibility in it.
If the provider means that authentication is not necessary at a specific point of the process because it has been done by other mean before, who cares ?
if auth is set but useless seamonkey should not complain, just make it with no auth if the provider does want it for now.
I can see in some forums people asking repeatedly their provider to setup authenticated links for the case of using a roaming provider, as this is going to happen more and more often.
Some of of the roaming providers restrict the use of port 25 and force us to use their own smtp, in this case with no AUTH.

Comment 17

[rsx11m]

(In reply to comment #16)
> I think this point of RFC 4409 has to be applied by the relationship between
> the provider and his client. Seamonkey has no responsibility in it.

Well, not really. It's a use case, supported by an applicable RFC, and it now has been more difficult to effectively set this up. I don't think you can put the blame on the provider's or institutions/companies using this scheme.

Since WADA has confirmed bug 534158, a solution may be found rather there.

> (In reply to comment #13) Even worse, removing the user name from the
> outgoing server still sets it to the same name as the incoming server and has
> "use name and password" checked (that's a bug on its own).

I've spun this issue off to bug 535033 for SeaMonkey.

Comment 18

[Jean-François Perron]

RFC 4409
4.3.  Require Authentication

   The MSA MUST by default issue an error response to the MAIL command
   if the session has not been authenticated using [SMTP-AUTH], unless
   it has already independently established authentication or
   authorization (such as being within a protected subnetwork).

(from introduction) SMTP is now also widely used as a message *submission*
   protocol, that is, a means for Message User Agents (MUAs) to
   introduce new messages into the MTA routing network.  The process
   that accepts message submissions from MUAs is termed a Message
   Submission Agent (MSA).

I understand MSA as the provider's side, and MUAs on users side (ie seamonkey or thunderbird)

Comment 19

[rsx11m]

Please let's not start nit-picking. Of course, it's the MSA's (provider's)
side decision whether or not to require authentication. As far as the MUA is concerned, it has to consider that the same MSA may or may not require authentication in specific circumstances, so this is a valid use case.

Comment 20

[Ludovic Hirlimann [:Usul]]

Main smtp issue tracker - nominating so it's not lost.

Comment 23

[Dan Mosedale (:dmosedale, :dmose)]

After much discussion with bienvenu and Standard8, we believe this is a duplicate of bug 522633.  Marking as such.

Comment 24

[rsx11m]

Since this has been combined with the secure-authentication bug, some pointers to issues discussed here but covered elsewhere:

Case #1: bug 542065 to better guide a user running into an authentication configured but not correctly offered issue to the respective settings.

Case #2: bug 534158 on having a server requiring different authentication settings for trusted vs. untrusted networks.