1219527 - Thunderbird Fails to send first email " connection to Outgoing server (SMTP)" "server timed out" after startup , then succeeds

Status: RESOLVED WORKSFORME

(Thunderbird :: Security, defect)

Description

[gg48gg]

Attachment: 2015-10-28 19_29_24- Mozilla Thunderbird.jpg

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36

Steps to reproduce:

It appears that when the first email is sent after a restart of Thunderbird, a timeout error is returned immediately.  

The text of the error is...
Sending of the message failed.
The message could not be sent because the connection to Outgoing server (SMTP) my.email.server timed out. Try again.
<OK>

In the status bar at the bottom of the Thunderbird window, a message reads:
Connected to my.email.server...

Clicking <OK> does not change the message in the status bar.

After clicking OK. Right clicking on the outbox and selecting "Send unsent messages" succeeds.

Creating a new profile, the same behavior exists with the new profile. I am using Thunderbird 38.3.0


Actual results:

After clicking OK. Right clicking on the outbox and selecting "Send unsent messages" succeeds.



Expected results:

Message should be sent the first time.  A Timeout error should not occur immediately when sending the first message after startup.

Comment 1

[gg48gg]

I tried to enable smtp logging and got the following.  Some notes within the logs are entered <like this>...

<hit send on email>
0[5511140]: SMTP Connecting to: my.email.server
<got error message, then hit ok>
0[5511140]: SMTP Connecting to: my.email.server
0[5511140]: SMTP entering state: 0
0[5511140]: SMTP Response: 220-ehub48.webhostinghub.com ESMTP Exim 4.85 #2 Wed, 28 Oct 2015 23:13:30 -0400 
0[5511140]: SMTP entering state: 0
0[5511140]: SMTP Response: 220-We do not authorize the use of this system to transport unsolicited, 
0[5511140]: SMTP entering state: 0
0[5511140]: SMTP Response: 220 and/or bulk e-mail.
0[5511140]: SMTP entering state: 14
0[5511140]: SMTP Send: EHLO [192.168.0.88]

0[5511140]: SMTP entering state: 0
0[5511140]: SMTP Response: 250-ehub48.webhostinghub.com Hello c-50-183-9-108.hsd1.co.comcast.net [50.183.9.108]
0[5511140]: SMTP entering state: 0
0[5511140]: SMTP Response: 250-SIZE 52428800
0[5511140]: SMTP entering state: 0
0[5511140]: SMTP Response: 250-8BITMIME
0[5511140]: SMTP entering state: 0
0[5511140]: SMTP Response: 250-PIPELINING
0[5511140]: SMTP entering state: 0
0[5511140]: SMTP Response: 250-AUTH PLAIN LOGIN
0[5511140]: SMTP entering state: 0
0[5511140]: SMTP Response: 250 HELP
0[5511140]: SMTP entering state: 4
0[5511140]: SMTP entering state: 21
0[5511140]: SMTP auth: server caps 0x20310, pref 0x300, failed 0x0, avail caps 0x300
0[5511140]: (GSSAPI = 0x800, CRAM = 0x2000, NTLM = 0x4000, MSN =  0x8000, PLAIN = 0x200, LOGIN = 0x100, EXTERNAL = 0x400)
0[5511140]: trying auth method 0x200
0[5511140]: SMTP entering state: 16
0[5511140]: SMTP AuthLoginStep1() for [e-mail]@¯t¯
0[5511140]: PLAIN auth
0[5511140]: Logging suppressed for this command (it probably contained authentication information)
0[5511140]: SMTP entering state: 0
0[5511140]: SMTP Response: 235 Authentication succeeded
0[5511140]: SMTP entering state: 18
0[5511140]: SMTP Login response, code 235
0[5511140]: SMTP entering state: 3
0[5511140]: SMTP Send: MAIL FROM:<[e-mail]> SIZE=422

0[5511140]: SMTP entering state: 0
0[5511140]: SMTP Response: 250 OK
0[5511140]: SMTP entering state: 5
0[5511140]: SMTP Send: RCPT TO:<name@other_email.com>

0[5511140]: SMTP entering state: 0
0[5511140]: SMTP Response: 250 Accepted
0[5511140]: SMTP entering state: 6
0[5511140]: SMTP Send: DATA

0[5511140]: SMTP entering state: 0
0[5511140]: SMTP Response: 354 Enter message, ending with "." on a line by itself
0[5511140]: SMTP entering state: 7
0[5511140]: SMTP entering state: 8
0[5511140]: SMTP Send: .

0[5511140]: SMTP entering state: 0
0[5511140]: SMTP Response: 250 OK id=1Zrded-00050D-32
0[5511140]: SMTP entering state: 9
0[5511140]: SMTP Send: QUIT

0[5511140]: SMTP entering state: 0
0[5511140]: SMTP entering state: 0
0[5511140]: SMTP Response: 221 ehub48.webhostinghub.com closing connection
0[5511140]: SMTP entering state: 10
0[5511140]: SMTP entering state: 12
0[5511140]: SMTP connection error quitting 804b0002, ignoring 
<message sent successfully>

Comment 2

[gg48gg]

Mistake above...
<got error message, then hit ok>
should read...
<got error message, then hit ok, then righ clicked outbox and clicked "send unsent messages">

Comment 3

[gg48gg]

Thunderbird 42.0 has the same behavior as well.

Comment 4

[Bill Z.]

This bug also occurs on every flavor of Ubuntu Linux I have (Ubuntu/Kubuntu/Xubuntu), and with every network connection. It happens 100% of the time.

It may help to note that I have never directed Thunderbird to save my password, preferring to enter it anew with each Thunderbird session. The error occurs upstream of the password challenge.

I'd say it's behaving as if some timeout counter is not properly initialized.

Comment 5

[gg48gg]

(In reply to Bill Z. from comment #4)

> I'd say it's behaving as if some timeout counter is not properly initialized.

I agree.  Thanks for chiming in Bill.  It sure would be nice if a developer would pick up this bug.  Seems like it may be an easy one to address, but I'm sure that's what everyone says about their bugs.

Comment 6

[gg48gg]

FYI...
The same behavior exists in "safe mode" with all add ons disabled.

Comment 7

[cathect]

I've been having this issue for months now on my Linux machine. It started after an update. The problem still exists in 38.5.1 which was just pushed out to Ubuntu users this morning.

Comment 8

[gg48gg]

Crickets chirping and this seems to affect all versions and operating systems.  Is there any other way to escalate this issue?

Comment 9

[Kent James (:rkent)]

gg48hh, cathect: Are you also configured to not save the password?

Also, if you are seeing this, are you using gmail to send?

Comment 10

[cathect]

@gg48hh,

Nope. I'm set to remember password. I am able to use gmail's smtp without issue. However, sending to my ISP fails on send, as described above.

I will note, however, that I just got a new computer and transferred my .thunderbird folder over to the new machine. I'm able to send email normally now to all of my accounts. I'm not sure if there was an update that fixed this or if my transfer to a new installation solved the issue.

Comment 11

[Bill Z.]

Update: the bug just stopped happening on my primary Ubuntu machine. I'm still running 38.5.1 Thunderbird, so it seems unlikely that that's it, but I did update Ubuntu itself last night.

I don't know how much sense that makes. If the problem was a broken API to the O/S, the bug wouldn't also have manifested on Windows. Perhaps an intermediate layer that's common across Operating Systems? Some Java layer, maybe?

Comment 12

[Josh]

Still Happening for me in 38.6.0. Moved to a new computer recently and the problem followed me.

Comment 13

[Bill Z.]

The problem went away on all my machines at once, both Linux and Windows. Since there were no proximate updates to those Thunderbird installations, I have to assume that this issue has something to do with the protocol at the server end. So my e-mail host's protocol used to cause problems, but now it does not.

It's unclear whether that would be a deficiency in Thunderbird or the IMAP server. One of them must either be off-protocol or the protocol is vague in that use case, so designers on both sides believe and can defend that their implementation is fully adherent, and yet the result is this incompatibility.

Someone who's versed in the protocols enough to intercept and take apart the handshakes in a misbehaving pair might spot the problem quickly.

Comment 14

[cathect]

I have the same experience as Bill. The problem suddenly stopped for me.

Comment 15

[Josh]

So on the server side they see this error:
2016-03-07 16:06:57 TLS error on connection from ([<my lan ip>]) [<my wan ip>]:50881 (SSL_accept): error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher

they said that it looks like thunderbird tries tls on the first attempt (and the server doesn't support it - only ssl currently) but the second attempt must try both ssl/tls?

Comment 16

[Wayne Mery (:wsmwk)]

> It's unclear whether that would be a deficiency in Thunderbird or the IMAP server.

Note, this bug is about sending which is smtp, not imap

Comment 17

[Kai Engert (:KaiE:)]

I wonder if this bug is related to a specific configuration used by some servers.
It might help to have a test account on one of the related servers.

Comment 18

[Josh]

I think its worth noting that I haven't observed this behavior in years.

Comment 19

[Wayne Mery (:wsmwk)]

(In reply to Josh from comment #18)

I think its worth noting that I haven't observed this behavior in years.

Thanks for the update.

I could be missing something but I don't see any useful matches in the list of currently open bugs https://mzl.la/2B2TftA (from query https://mzl.la/2ZOG6if ). So let's close this out.