User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 Build Identifier: Thunderbird 3.0.1 20100111100551 The SMPT server of my SPI provider requires: 1) identifation of username and password 2) secure authentication with TLS 3) specifies the port 25 and not any else With TB2 it work but with TB3 the server can't be accesed anymore Reproducible: Always Steps to Reproduce: 1.set up the outgoing mail SMTP server 2. specify port 25 3. mark "SSL/TLS" althouhg the ISP only wants TLS Actual Results: TB connects to the server but stays in the waiting loop, it would never send the message. When you abort, a message saying "sending of message failed. please chech the account settings". Expected Results: Send the message with exactly the the SAME smpt settings as TB2 does actually.

Note that the options have been relabeled (bug 350314): - former SSL is now SSL/TLS - former TLS is now STARTTLS Thus, try STARTTLS with port 25 as directed and see if it works.

Already tried that before a lot of times: There always appears: Login on smtp server failed. (three buttons: new password,retry, abort). Seems that the smtp server does not accept STARTTLS

Did you disable the "Use secure authentication" box if it was checked? You shouldn't use plain authentication without SSL/TLS or STARTTLS line encryption though as this would expose your password in clear text. If nothing works, an SMTP log can be created as follows (assuming bash): $ export NSPR_LOG_MODULES=SMTP:5 $ export NSPR_LOG_FILE=/tmp/smtp.log $ thunderbird This would provide a protocol of what's going on and how the server responds, thus may help to isolate the problem. With a simple text editor you can edit ('x'-over) any information you don't want to post publicly, then use the "Add an attachment" link above the description and comments to upload the log.

Already tried that before a lot of times: There always appears: Login on smtp server failed. (three buttons: new password,retry, abort). Seems that the smtp server does not accept STARTTLS

Thanks, unchecking "Use secure authentication" did the job, it works now. (In reply to comment #3) > Did you disable the "Use secure authentication" box if it was checked? > > You shouldn't use plain authentication without SSL/TLS or STARTTLS line > encryption though as this would expose your password in clear text. > > If nothing works, an SMTP log can be created as follows (assuming bash): > > $ export NSPR_LOG_MODULES=SMTP:5 > $ export NSPR_LOG_FILE=/tmp/smtp.log > $ thunderbird > > This would provide a protocol of what's going on and how the server responds, > thus may help to isolate the problem. With a simple text editor you can edit > ('x'-over) any information you don't want to post publicly, then use the "Add > an attachment" link above the description and comments to upload the log.

Ok, so it doesn't like either secure connections nor secure authentication. Nevertheless, the behavior of just getting "stuck" during authentication is definitely not right, thus I'm reluctant to just dupe this against bug 522633 though it matches the symptoms. Can you either create an SMTP log anyway (with the stalling setting), or execute the following to probe for the capabilities of your ISP's server: Enter on command prompt: $ telnet my.server.com 25 Response from server: 220 my.server.com ESMTP ready (or similar) Enter greeting: EHLO just.testing.com Multi-line response: 250-... Close connection: QUIT Response from server: 221 Bye! Connection closed by foreign host. and copy-paste the "250-" response lines into a comment posted here?

Hello rsx11m: Here it goes, just changed the server name for privacy reasons 250-myserver.com 250-PIPELINING 250-SIZE 6291456 250-ETRN 250-STARTTLS 250-AUTH GSSAPI NTLM LOGIN PLAIN DIGEST-MD5 CRAM-MD5 250-AUTH=GSSAPI NTLM LOGIN PLAIN DIGEST-MD5 CRAM-MD5 250 8BITMIME (In reply to comment #6) > Ok, so it doesn't like either secure connections nor secure authentication. > Nevertheless, the behavior of just getting "stuck" during authentication is > definitely not right, thus I'm reluctant to just dupe this against bug 522633 > though it matches the symptoms. > > Can you either create an SMTP log anyway (with the stalling setting), or > execute the following to probe for the capabilities of your ISP's server: > > Enter on command prompt: $ telnet my.server.com 25 > Response from server: 220 my.server.com ESMTP ready (or similar) > Enter greeting: EHLO just.testing.com > Multi-line response: 250-... > Close connection: QUIT > Response from server: 221 Bye! > Connection closed by foreign host. > > and copy-paste the "250-" response lines into a comment posted here?

Thanks, this helps. GSSAPI indeed would be bug 522633, but the other secure authentication methods should correctly trigger the box to be checked, thus something went wrong in the secure protocol later and caused the stalling. David, this is similar to what ovidiu reported (initially as bug 523153). Do you want this bug to be handled separately from the general trySecAuth issue of bug 522633, or just be duped for a broader solution there?

(In reply to comment #8) > Thanks, this helps. GSSAPI indeed would be bug 522633, but the other secure > authentication methods should correctly trigger the box to be checked, thus > something went wrong in the secure protocol later and caused the stalling. > > David, this is similar to what ovidiu reported (initially as bug 523153). > Do you want this bug to be handled separately from the general trySecAuth > issue of bug 522633, or just be duped for a broader solution there? Indeed, the profile I use with TB3.0.1 is a migrated Thunderbird 2.0.0.23 profile

rsx11m, when in doubt, I think more specific bugs are better. If we end up fixing it in a general way, then we can mark several bugs fixed at once, which is better than marking one bug partially fixed. And I'm not sure that autoconfig does a verifylogon on the smtp server, so it might get horked by this as well.

Ok, confirming and making dependent to 522633. Based on another discussion in bug 538809, autoconfig indeed doesn't verify the logon during setup, but this issue here is a migration case and thus closer to 522633.