>>>Any ideas?
>>
>>A guess, but might it be limitations set by the SMTP server or ISP? Some have limitations such as:
>>
>>- Total # of messages per hour and per day
>>- Total # of recipients per hour and per day
>>- Total size of messages per hour and per day
>>
>>If you hit such a limitation you typically don't get any sort of error message or warning. I don't know how an SMTP server or ISP might respond to a perceived violation, but it's not impossible whatever they do could hang a SEND().
>>
>>If you have a good relationship with the server owner or ISP you could ask them if they've logged any unusual events around the times you're seeing these intermittent errors.
>
>
>Thanks Al. We're actually sending to smtp.gmail.com as we use Google Apps for Business.
>
>There should never be a circumstance that .send() completely hangs. What's the point of a timeout if there are scenarios that never time out?
>
>If I can't resolve this issue I'll be forced to dump CDO and use a commercial alternative.
>
>When the black box behaves, it's awesome. When the blackbox misbehaves, you're screwed.

Another thing that might be worth looking at - antivirus.

I've seen Trend Micro WFBS incoming mail scanning component (for Exchange) throw occasional errors in the Windows Application event logs, if it takes more than 90 seconds to process an incoming message. This doesn't directly apply to your case because you're sending rather than receiving, but it shows that AV can get in the way.

If you know reasonably closely when you've encountered these errors, you could take a look at the event logs to see if there are any funky entries.

As for the CDO 2000 class, it's been a while since I looked at it in detail. I can't remember if you make a connection, send messages, then disconnect or whether that's all wrapped in the Send() method. If the former, some SMTP servers also impose limits on # of messages sent per connection. So, in that case you would get best reliability by sending only a small number, or even just one, message per SMTP connection/conversation.

Yet another limit sometimes set is simultaneous # of connections from a given IP address. This could come into play if you have a number of machines on an office LAN simultaneously sending messages. Each would count as one SMTP connection to the server, all from the public IP of the office LAN.

These may be edge cases and may not apply to you, but I thought I'd point them out. If it turns out they actually are in play, then you'll still see the problem regardless of what method you use to send, so moving to Chilkat etc. would not help.