2050206 - Failure to send emails via smtpout.secureserver.net on first attempt after 15 mins idle. Send is successful on second attempt. Other SMTP servers seem to work and outlook works with this smtp server.

Status: UNCONFIRMED

(MailNews Core :: Networking: SMTP, defect)

Description

[Owen Williams]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36 Edg/149.0.0.0

Steps to reproduce:

New install of Thunderbird on new PC, new profile from scratch. Problem persists.

Multiple SMTP connectors configured for different services. The others all work.
Tried outlook with the problem service and it works.
Extensive diganostic chat and action using chatgpt, concluding with likely a Thunderbird bug.

Actual results:

Chatgpt concludes as follows

This is where I think we genuinely are

We've eliminated:

VMware
Storage performance
Windows
HP Wolf
Firewall
DNS
IPv6
Thunderbird profile corruption
Message filters
GoDaddy account credentials
The mailbox itself (because Outlook works)

So the remaining problem is simply:

Thunderbird 152.0 + GoDaddy Workspace SMTP (smtpout.secureserver.net)

Expected results:

The e-mail should simply send successully.

Comment 1

[Magnus Melin [:mkmelin]]

Please provide an SMTP log. See https://wiki.mozilla.org/MailNews:Logging

Comment 2

[Owen Williams]

Attachment: Zip file containing SMTP LOG

Comment 3

[Magnus Melin [:mkmelin]]

That's not an SMTP log. Please check the wiki for how.

Can't really say from the log, but it does log some socket errors. Perhaps you have the wrong settings. https://www.godaddy.com/en-ph/help/set-up-third-party-plugins-or-websites-using-smtp-settings-42788

Comment 4

[Owen Williams]

The settings are correct. When an e-mail fails to send, a resend or a different e-mail within 15 mins succeeds. But after a long idle time with no sending the next e-mail send fails.

I will provide the SMTP log when I have a moment.

Comment 5

[Max Emig]

Is it configured as SSL/TLS (port 456) or STARTTLS (port 587)? I suggest you try the other variant.

Comment 6

[Max Emig]

Also, do you remember what the last known working version was?

Comment 7

[Max Emig]

I assume bug 1965690 is the root cause along with a situation where either due to GoDaddy or firewall/ISP middleboxes the TCP session is logically closed but a TCP socket left open and Thunderbird treats it as a still valid connection and does not attempt to validate in any way.

It landed in 142 without an uplift to ESR 140, so this might be why you have seen it working before.

There has been further work in this area since then which might have changed the situation to the worse.

Comment 8

[Max Emig]

If we have the SMTP log and my assumption holds accurate, I would put a NOOP as a check in per RFC 772:

            NOOP (NOOP)

            This command does not affect any parameters or previously
            entered commands.  It specifies no action other than that
            the receiver send an OK reply.

Yeah, I know there are much newer RFC duplicating that, but where is the fun in that? The expected answer is 250 OK in most cases.

Comment 9

[Max Emig]

For context:

The old C++ SMTP code never re-used a connection: https://searchfox.org/comm-esr91/source/mailnews/compose/src/nsSmtpService.cpp#207
The current POP3 implementation extensively uses NOOP: https://searchfox.org/comm-central/source/mailnews/local/src/Pop3Client.sys.mjs#618-630

I feel the direction is clear :).