Matt, I had a difficult job sending that email with log to you. The workarunds I'd found did not work this time. Eventually, I had to re-boot the PC, start TB with clean sheet, open the saved draft and send - and that worked.

Bloody irritating, this is.

Matt, Tested with the address you gave, an smtp log file should be in your unicorn box now.

This send issue is pretty repeatable - normally works first send only about 20% of time, all others need one of the workarounds I've found. If you need a specific test with captured log let me know.

I am still slogging through the original SMTP log you sent. But a though has occurred to me. Assuming you are connecting via iprimus which would be the normal thing. Try changing your SMTP setting to use no authentication at all. Their web site says not authentication unless you using another provider to access the internet, like an optus or telstra phone I assume.

Hi Matt, You suggested that once before, I did it, and there was no difference in the send failures. However, this time I took screen shots of the smtp settings (for convenience, I assume you are familiar with them), reset them to no connection security, and sent a test message (test3) to the devils address with that revised setting. The send result for test3 was no different to test2, which generated the log file you made this prior comment on: it failed the same way, and was ultimately sent the same way. The smtp log file for test3 should now be in your inbox.

Normally, I have been using a STARTTLS setting for an encrypted password exchange: a screenshot of that attached. For this no connection security test, a screenshot of the smtp settings also attached.

Re the comment you pass on about the remarks from iprimus - not sure what they are on about. The settings for the IMAP/POP/SMTP components of TB all refer to their servers, so just what sort of transit via another network they have in mind is not apparent. Probably some clarification of the local reality needed here: - the end -to-end broadband network is physically provided by the NBN, capacity by firbre, copper or wireless. Capacity on it is re-sold by retail ISP vendors to connect customers to their own servers. And as you know my ISP is iPrimus. - the physical network from my home is via copper phone lines for about 400metres to a Fibre-to-the-Node (FTTN) street cabinet. That FTTN cabinet supplies the connectivity for all ISP's serving about 300 homes in the radial area around it, and from the FTTN cabinet the connection into the backhaul network is via single mode fibre connection. - the modem at my home is a Huawei HG659 integrated modem: it carries everything - data and phone via VoIP over the copper cables to the FTTN street cabinet.

My ISP broadband connection is a nominal 50mbps service, when I tested it just now, via speedtest.net, the results to the local ISP server were ping 5ms, download speed 31.99mbps and upload 11.25mpbs. In the midst of coronavirus lockdown, school went back for the autumn term today with overwhelmingly (90% of students?) on-line learning: the schools website crashed at 0930, so this result at 1210 is probably pretty good considering.

Matt, test 4 sent to devilsgate, normally. The log file and settings image, sent to your email, normally. I have reservations about this - a server login with no security at all seems very risky, given all the mail server hacks that seem to be around.

I think I need to point out I do not need instructions on what is happening with KRudds folly, or the mess it became while Mr Turnbull spend most of his time as communications minister basically lying about NBN. I would forgive the usual idiot minister, but Turnbull was a principle of OzEmail, being a cofounder. So he knew exactly what he was selling. Outright lies and half truths basically. Fortunately I am remote enough that the useless wireless technology will not appear until some time late this year, or next. There has been a lonely tower with nothing attached to it for about a year now. I suppose they are waiting for another round of government grants to bring the NBN to remote areas. They did it under Ziggy when he was at telstra, so now NBN are doing it, also under Ziggy. It will only be a few years and they will be able to sell off NBN ala Telstra. Then a few years latter they can build another network and force everyone to use it like they are doing with NBN and sell that. It might help pay for the current largesse.

The use or otherwise of a username and password is something you would need to take up with iprimus. you think it might be risky for the legitimate person to send mail like this, but iprimus already know who you are as they allocated an IP address to you when you connected to the internet. As long as the email is coming from the IP address they allocated to you, they are happy apparently. Your use of a password or not is somewhat academic as they permit it. As to how they prevent others from using your credentials, I gave you my guess. But it has nothing to do with Thunderbird. It is all iPrimus.

Something you really need to appreciate is NBN is basically in the position Telstra was in for the last 20 years, a monopoly holder of backhaul, but the provider still has to provide the network infrastructure for things like email, accounting and even the governments logging of everything that rose to prominence and then quietly sank because no one outside the industry understood what was being done. Just be assured our government knows exactly who you ring and when and where you go on the internet. We are one of the most regulated countries in the world when it comes to digital communications and financial matters. Like NBN however it is not germane to your issues with iPrimus or Thunderbird. Nor are most of the security issues that anti virus vendors promote actually as serious as they would like you to believe. The internet is not a friendly place, and there is always someone wanting to make money off you. Anti virus vendors are no exception they are selling fear. The more fear they engender the more welded to "security" software the general person becomes. For instance, most people never question outgoing mail scanning by an anti virus products. The A/V product can not find any infection, it has certified the device clear as far as it is capable. Then it scans outgoing mail looking for the bug it can not find. But it does usually do a very good job of slowing down the assembly of the mail through it's temp folder scanning and then the send because it scans the assembled mail on it's way out the door (for your security of course).

You are obviously from the great south land. And as a network pro/architect before I retired, I know exactly how and why the current nbn situation arose. Nevertheless, I did think that the network infrastructure/performance may have had some influence on what is happening with smtp sends, which is why I mentioned what it currently is/was.

The interesting para from your response is the 2nd. Yes, iprimus knows me and my connection. But - supposedly - a login with security credentials is to confirm that the user requesting service is actually the one for whom the service is provided, and to prevent a man in the middle attack yielding enough info for a hack. The hearbleed bug I mentioned in an early post did just that - got a motza full of user data that was sold all over, and part of that impacted me. Some one was sending broadcast emails purporting to come from me, and the only way I found out about it was a few of them bounced - right back to me. Took a while to get that sorted out, and it made me sensitive to these sort of issues. Heartbleed was a server OS bug that most admins had not patched, which is a bit different to case here, but it was a security penetration. But to the issue.

Clearly the two sends with no auth/pwd that worked normally versus what was happening with the security connection/configuration that TB provides is a reasonably clear indication that my assertion that something in TB was a cause. From the various things I found, the smtp send is the result of a handshaking exchange in a recognised protocol. It should have worked: and did - sometimes. And while while I'm not privy to the protocol details, a processing (encrypt the password and assemble the packet in accordance with the protocol selected) delay plus any variable transmission delay (congested networks) may well have exceeded the response timeouts that are usually a part of the specs.

For years, the AV security suite has had email scan of send OFF, but the scan of receive was on. And the send problems kept recurring. From the time you outlined your concerns about what the AV software may have been doing, the whole email suite of the AV system has been OFF. And yet that intermittent send fail, then OK as a result of workarounds as outlined persisted with the selected starttls/normal password configuration kept recurring. That is what is in the first 2 send logs I mailed you.

Since you pointed me to an smtp configuration that works - at least on the 2 emails I've sent outbound since using it - I've done a bit of local testing in both directions within my account, with the following results: - a mix of no auth/pwd and starrttls/pwd locked up a read on the inbox for the account using the starttls configuration. Makes no sense since reads use imap, but that's what it did; - making both accounts the same configuration got the same "normal' send result between them. - turning the AV suite email scan back on - no smtp scan, but receive scan - and the sends are still normal.

Which still points to something that's in either TB with a secure smtp connection setting or the ISP or both that causes that most-of-the-time send error. That changing the focus of the software (save as draft, read something different, then send the draft OK is bothersome. And it's not just me - the posts on this topic in various thunderbird threads are fairly numerous, and it seems like the root cause has never been isolated. If you can identify it from the logs, I envisage - whatever is in TB - would be passed to the devs to fix, or provide for relevant amelioration such as timeout adjustments in the expected response to the server if that can be done - whatever is in the ISP's mail servers - with adequate documentary evidence from you and I would take it up with iprimus.

You've been pretty helpful so far - don't stop now until we know just what it is that's doing this. Since this is pretty repeatable on my PC, if you want me to do extra testing please advise.

One thing I've noticed with the no auth/no password smtp settings as outlined, is that when a mail sends, TB closes down after the send.

is that correct? is there any way I can stop it closing down after the send and be ready further reads/sends?

One thing I've noticed with the no auth/no password smtp settings as outlined, is that when a mail sends, TB closes down after the send. is that correct?

No it is not. But applications simply disappearing on Windows usually is an issue with an invalid memory read. They can also be related to writes to a failing hard disk.

is there any way I can stop it closing down after the send and be ready further reads/sends?

I suggest you use windows tools to scan the physical device for errors, either logical or physical. Undertaking a drive defragment is also indicated as that makes the disk work and can show up errors.

IT is also probably worth trying safe mode with those settings to ensure the issues is not some of Thunderbirds advanced features;

• Restart Thunderbird with add-ons disabled (Thunderbird Safe Mode). On the Help menu, click on "Restart with Add-ons Disabled". If Thunderbird works like normal, there is an Add-on or Theme interfering with normal operations. You will need to re-enable add-ons one at a time until you locate the offender.
• Restart the operating system in safe mode with Networking. This loads only the very basics needed to start your computer while enabling an Internet connection. Click on your operating system for instructions on how to start in safe mode: Windows 10, Windows 8, Windows 7, Windows Vista, Windows XP, OSX

If safe mode for the operating system fixes the issue, there's other software in your computer that's causing problems. Possibilities include but not limited to: AV scanning, virus/malware, background downloads such as program updates.

Hi Matt, Thanks for the help. The thunderbird application and message data are on 2 separate, not C:\, drives on the PC. C: is an SSD, and I've turned off defragment for it. As an SSD, defrag for it is more a hindrance than a help. The other drives are on HDD, each one considerably less that 75% used, and as it turns out despite a windows schedule for them, they haven't been defrag'd for over a year. So I did that, not just for these 2 drives, but all of the others as well. The nett result was good: TB responds better and doesn't close after the send. David

I have a similar problem. After running for (literally) years my Thunderbird setup has suddenly over the last two days started (a) not delivered incoming e-mail as it arrives, & (b) failed to send output messages, claiming that the output server "was lost in the middle of the transaction". My internet provider is Primus Canada. In discussion with technical support it appears that the handling of both incoming and outgoing emails by the servers is working as expected. In addition, webmail applications as run on Firefox, my i-pad, and my i-phone all seem fine (although inconvenient as a long-term working backup). The problem therefore seems to reside with Thunderbird, whose settings have not been changed at all for some time now. I am running Windows 10 Home 64 bit (v1909, build 18393.900), Thunderbird (68.9.0 - 32 bit), Firefox (77.0.1 - 64 bit) all of which are up to date versions. Has anyone any suggestions as to what may be happening, or further lines of investigation? [P.S. I should add that from time to time Thunderbird will perform a "batch" load of queued incoming e-mails, following a reload of the program and/or a system restart.]

I have a similar problem. After running for (literally) years my Thunderbird setup has suddenly over the last two days started (a) not delivered incoming e-mail as it arrives, & (b) failed to send output messages, claiming that the output server "was lost in the middle of the transaction". My internet provider is Primus Canada. In discussion with technical support it appears that the handling of both incoming and outgoing emails by the servers is working as expected. In addition, webmail applications as run on Firefox, my i-pad, and my i-phone all seem fine (although inconvenient as a long-term working backup). The problem therefore seems to reside with Thunderbird, whose settings have not been changed at all for some time now. I am running Windows 10 Home 64 bit (v1909, build 18393.900), Thunderbird (68.9.0 - 32 bit), Firefox (77.0.1 - 64 bit) all of which are up to date versions. Has anyone any suggestions as to what may be happening, or further lines of investigation? [P.S. I should add that from time to time Thunderbird will perform a "batch" load of queued incoming e-mails, following a reload of the program and/or a system restart.]

I suggest you keep to your topic here https://support.mozilla.org/en-US/questions/1291624

Your issue is not even vaguely similar what is under discussion here being half a world apart and involving some really rather weird provisions by iprimus as a mail provider.