Thanks for the quick reply, Till. I really appreciate your help.
I did think to inspect the message headers for some evidence of "X-Mailer: PHP" or similar, and I see no evidence whatsoever of PHP in the message headers. (I do realize that this observation does not necessarily mean that the messages were not sent with PHP.)
When I first noticed this, I saw one website (PHP process) in particular with higher-than-normal CPU usage. I placed "sendmail_path = /dev/null" in that site's "Custom php.ini settings" field and the problem seemed to stop. I didn't see any further activity for a couple of days.
But I wasn't satisfied with "hoping" that the problem was resolved. Also, I can't have PHP mail capability disabled for the vhost in question in the long-term. In effort to confirm that the problem was in fact coming from this one vhost, I removed the sendmail_path override to see if the problem recurred.
The problem did not recur immediately. But after a few days, I returned to find 8000 emails in the deferred queue.
The problem is that once those emails are in the deferred queue, a lot of the activity that I see in mail.log seems related to Postfix trying to re-send those messages, which creates a cascading effect and way too much log traffic to sift through without a meaningful strategy.
I have been clearing the queue of all messages with recipients @hotmail.com each time this happens. I am doing this because Hotmail is blacklisting my server due to the abuse, and I have legitimate clients who need to be able to send mail to @hotmail.com recipients. I want to drop-off Hotmail's blacklist as soon as possible.
I have again removed "sendmail_path = /dev/null" from the suspect vhost. I guess I'll wait to see if the problem occurs a third time. And this time, I'll try to capture a large sample of messages from the deferred queue before I clear it.
Thanks again. I'm all ears if you have any other ideas.