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.
I'm posting this just to make a record of the fact that my POPFile has started crashing about once a week for the last couple of months after being rock solid for many years. Spam starts showing up in mailboxes due to popfileib.exe not running. There isn't any consistency in occurrence times; no event is logged that I can via Event Viewer.
At first I thought someone was doing a reclassification and mistakenly hitting the "Shutdown POPFile" link but it has now crashed a couple of times in the middle of the night when the office was closed (it's not accessible remotely). It runs on a Win7 PC that is dedicated to Mercury, POPFile, and online banking. Vipre Enterprise is the AV product; IBM Trusteer Rapport is also as a requirement of online banking. The machine is in a server room where it gets accessed twice a day for online banking and as needed for Windows and Firefox updates. The POPFile crashes don't coincide with any of these times. A cold boot hasn't solved the problem.
There is nothing to go on for troubleshooting, at least not that I can find. Any thoughts are welcome.
A side affect of trying to understand the SmtpEvt daemon is that I now have a better understanding of the options in the MercuryS Compliance tab and of the potential value of transaction filtering as way to immediately blacklist an IP address that has been identified as repeated trying to gain access. My "refuse" entries in Connection Control have been removed opting for transaction filtering rules instead.
I've standardized the rules as per below with only the IP address changing but welcome suggestions on a better or more appropriate way of doing this.
H, "*22.214.171.124*", BS, "554 Relaying not allowed - connection dropped"
I'm anxious to see the effects of this change in conjunction with SmtpEvt.