Try disabling email scanning and on access scanning of the temp folder. And make sure most of all McAfee is not in the mix at all.

Place Thunderbird in Offline mode click the two monitors in the bottom left corner on the status bar. or File menu (ALT+F) > offline > work offline

Going back on line is the reversal of that process.

At a wild guess I am assuming events are simply falling over one another. Unlike outlook Thunderbird is trying to actually send the mails as it gets them. Taking it offline will defer that action until you are online. So each mail will be written to the outbox folder only until Thunderbird is online.

The three options I mention are all designed to remove road blocks to the process.

Hi Matt,

Just got this from the person who uses QB and TB who i told to try taking TB offline:

Tried taking TB offline. It's working better than last time. It ties up TB for a day to send 125 emails, though, so doing a whole batch of 500 seems impossible. I also think about 20 emails failed but there's no way to find them save picking through the sent folder, ugh. I'll definitely do smaller batches in the future, but QB doesn't make it easy.

So taking TB offline is not a total solution.

Will remind them to try turning off email scanning in whatever virus protection they use, and if McAfee, replace with other virus software.

Any other thoughts?

If your person is at all able, opening the task manager and seeing what other processes are active while the send happens would probably provide good clues. (sort by CPU so the list keeps changing)

They should also try restarting Thunderbird with add-ons disabled and try the process with the operating system in safe mode with networking (I assume quick books will run.

Both safe modes can help illuminate the actual problem, as can looking at the active processes.. In one case, it was some security software a bank had issued causing Thunderbird to crawl.

Hi Matt,

With TB in offline mode, and QB running, did the following tests:

1. Generated in QB 75 emails to clients. TB sucked them down quickly with absolutely no problem. This of course was surprising since i had been told otherwise, but upon further testing, it became clear that my user had not actually counted all the emails in the outbox waiting to be sent to see that QB to TB worked just fine. So with that part of the process clarified, moved on to sending emails out from TB.

2. So took TB back on online and it wanted to send the emails and clicked yes. TB would then send 6 emails and then hang on trying to send the 7th email. Retrying wouldn't help, you would have to quit/start TB and it would then send another 6 emails before hanging. The message was something about losing connection with the server. My stupidity, under tight timeline, i didn't write down the exact message, but it was pretty general message. Had Task Manager running sorted by processor %, but couldn't see anything that was taking up time.

3. Turned off Avast virus scanning and Malbytes malware. Tried TB sending and still same problem, sends a small number of emails and then hangs.

4. Rebooted in Safe with Networking mode (hitting F8 repeatably after startup sound). Started up TB and it would do still hang after a few emails (about 6).

To recap, it appears that there is NO issue from QB to TB. Only issue TB sending out to mail server and hanging after 6 or fewer emails with the error message (which i don't have but can get again of course) roughly saying lost connection with server.

Internet works fine otherwise on computer. TB has no other issues that we have seen. Things i have thought to try since writing this (ran out of time at my user's computer):

1. Put TB in offline mode. Write 8 emails to people so they are in outbox. Take TB online and see if same thing happens with emails that are not from QB.

2. Double check with virtual hose provider about some sort of outgoing spam prevention where drops connection if email subjects in sequential emails are the same? Have already confirmed that volume of emails is no issue.

3. Double check no TB add ons (which you mentioned above), but my user said they didn't add any and neither did i.

Any other ideas?

Peace, Dan

Thunderbird comes with an add-on... so everyone has one unless they removed it.

These emails? do they have attachments? PDF files perhaps?

I like your suggestions 1- 3 as thing to check, I would also suggest trying another SMTP server. Gmail might be a good place to try sending a batch of qb mails through, as it does allow for you to setup our account there so it appears that the sent mail come from the original host. (Relatively short setup time for a test)

If it is a business environments, what sort of edge firewall is there. Just wondering if a router is guaranteeing bandwidth for IP Telephony by slowing the connection to the point it times out (but that should produce a timeout error

Thanks about the add-ons. Will try with it disabled.

Yes, these emails have PDFs attached - customer balance statements last time, sometimes invoices.

Ok, after my tests will add emailing through another server.

Network connection is business cable so high speed. A new router has just replaced the old one and no difference in this issue, so doesn't look like router is an issue. But actually there is another router upstream, yet this didn't happen with Outlook before switch to TB so i'm thinking router can't be issue.

I'll report back after tests. Thanks for quick response!

Just reading this again and wondering. Wondering if the PC has loads of free disk space and a tidy temp folder.

Sounds silly, but I have seen occasions there the sheer volume of orphaned rubbish in the temp folder leaves the machine struggling. Probably in combination with a RAM shortage, but in one instance I removed 10,000 files from the temp folder to clear a mail merge issue. I never worked out what was struggling, but I guessed that at some point the file list becomes unmanageable for the software.

Both of those things are fairly common in business, especially with packages like quickbooks which really require more than a standard office PC to run and rarely get it. They usually also have a good bookkeeper that is technically hopeless with computers driving in my experience.

Simply running the disk clean up utility might improve things.

Your thoughts about it being an overloaded computer/os are interesting. If that was the case one might think it wouldn't make a difference with TB versus Outlook. But How TB deals with temp files/folders might be different. In any case, running disk clean up utility makes sense as it can't hurt.

This makes me think about what other system resource use aspects might be different between TB and Outlook and open file handles could be another. Or since it is during an email communication with the server, TB could be using more ports or something. Wait… while watching TB send the batch of 75 emails it looked like TB opens a new connection for each email. Do you know about the internals of TB?

logging might be an answer to that question. https://wiki.mozilla.org/MailNews:Logging

I've had the same problem. QB can't send more than 5 emails to T-bird and the rest get dumped into the cosmic bit bucket. FWIW, I had the same problem sending emails via the Intuit remailer from within QB.

If TB is trying to open up too many connections with the SMTP server then the server should, and probably does, send back an appropriate error message and TB should back off and wait until it can close one or more existing connections and then try again. Dumping mail on the floor is NOT ACCEPTABLE for any component, MTU, MUA or otherwise in the mail transmission chain!

I solved this problem on my installation by taking TB offline and sending invoices from QB to it (thanks, Matt!!). All of them showed up in the outbox in TB, and when I went back online with TB I could send ALL of these emails out successfully. Granted that my test sample consisted of only 13 invoices to a dummy account, but without doing this only 5 of them would go out and the rest got dumped on the floor and lost. There was no hang.

I had turned off Avast! monitoring of SMTP so there shouldn't have been anything between TB and the SMTP server.

Thanks for input fmouse. We have done the TB offline thing and get all the emails from QB. But when TB goes back online still only 6 emails or so at a time go out. Have still to try turing on the log to see why that is happening.

Try disabling outgoing email scanning in your anti virus package. The connection is probably timing out while the anti virus verifies your previously clean computer has not yet invented the capacity to create infected emails out of thin air.

The design of the protocols for email from the sending MUA to the receiving MUA, inclusive, is designed specifically to insure that nothing gets dropped into the cosmic bit bucket. If a server times out during a SMTP transaction the sending MUA must retain the message and try again later. Notifications of failure which would result in the loss of an email must be sent to the envelope sender as a non-delivery report.

Failure of a mail user agent, i.e. Thunderbird, to behave according to these principles and standards is a bug and should be address by the Mozilla Thunderbird team.

I hear you fmouse. I'm a software, systems and network engineer and TB choking after sending 6 emails such that you have quit TB and start it back up shows something is wrong. But then again we are talking running under windows… not unix. So the logging feature of TB i was told about earlier in thread should show me where in the smtp protocol exchange the 7th email is getting hung up which might give a clue. If pointing to TB then i can hand off to TB folk as bug report. Or maybe there is something at the virtual host provider?

And Matt, have already tried turning off the virus scanning. No help.

Actually, the more serious problem isn't one of choking and needing a restart, but of emails being simply dropped into the void and never seen again, with no NDR being returned to the sender. If one doesn't take TB offline before posting from QuickBooks then this is what we're seeing happen. A hang requiring a restart is an order of magnitude less serious a problem than completely losing emails, requiring an inventory of sent copies to be matched against the QB inventory of generated invoices or statements prior to the send. Once forms are passed off to TB for emailing the inventory of forms to be sent is cleared in QB, so recovering this list isn't simple.

Yes, you are correct about the seriousness of dropping emails. But that never happened for us. TB sucked them all down even when online. But TB only sending out 6 at a time had the operator thinking that they were lost cause they didn't look in the "outbox" in TB. Once i got involved hands on versus via phone, i showed the operator that they were there.

So the only problem we are looking at is the TB to smtp server issue. Though i sympathize with your loss from QB to TB… that just plain old sucks.

Matt has been very helpful with things to do. I better get over there soon and turn on the mail logging in TB already… so many things to do...

Since I run my own mail server my bottom line check was inspecting the mail server logs, which indeed showed that TB failed to even attempt to send some of the emails which had been passed to it by QuickBooks. They simply disappeared.

Have you disabled your anti virus before making these sweeping statements about MUAs and what is an is not acceptable per standards or even what is in your logs?

Thunderbird is standards compliant, so probably is your mail server software and the developers of both would be trying hard to keep it that way. It is the primary reason that send in the background has not been enabled by default, because in some special circumstances mail can be lost during transmission.

The same however can not be said for your anti virus program and they regularly drop mails,  mess up the connection with poorly conceived proxies with no user interface to fix them and make a total mess of attachments and destroy traffic on SSL connections.  They also maintain their own password cache and mess that up as well, sending a different password to the one Thunderbird sends.  So in any text make sure the connection that occurs is Thunderbird to the mail server, without a third party silent assistant.  

Symantec now claim to be able to scan traffic on SSL connections. How does that work? Technically they are not a party to the certificate that is exchanged for SSL. So just what is their software doing?