Did look through the files to see if any issues. Also had the ISP setup an outer perimeter spam filter in hoping it catches one of these emails that are getting bounced. My understanding is that the sender will not get any return errors or message so that might be an option for hints
I just talked with a support tech at our domain host. He was able to see some of the messages coming in without a date header but said they can't do anything about it. His understanding is that the sending SMTP server should be adding a date header to any message submitted without one. The organizations from which I receive these messages are huge companies running their own SMTP servers do there isn't any hope of me initiating a resolution.
Not sure I really understand your setup, but regardless of that I assume the question is if a list subscriber can send a message to the list but only have it distributed to one specific subscriber. Short answer no, long answer maybe, but it would be very complicated. One would need to create a daemon to intercept such messages in Mercury and bypass normal list handling, and the sender would need to manually include the address of the intended recipient somewhere in his message, as a unique header or similar. Any tiny error could result in the message being distributed to the entire list.
You have posted in the Mercury support forum but reference a Pegasus Mail version number. Perhaps you meant to post in the Pegasus Mail support forum? It will be important to include reference to what tool you are using to detect spam.
Since Mercury32 moved to using OpenSSL, I've never had any problem updating to the latest compatible version of OpenSSL. I am currently using OpenSSL 1.0.2t released in 10-Sep-2019. I just make sure I use a 32-bit build without external dependencies to the Microsoft Visual Studio Runtime DLLs, except for the system provided msvcrt.dll. I don't build OpenSSL myself. I download it from one of the Windows 32/64 precompiled binaries sites listed on the OpenSSL wiki. Before I made the switch, a few years ago, I did verify that every function exported in the version that came with Mercury was available in the one I was switching too. Now I just shut down Mercury, update the affected fields and restart. Hoping that the next version of Mercury updates to use Open SSL 1.1.1 since 1.0.2 which was a LTS release is approaching EOL.