How can I trust a CA that fraudulently issued certificates that it is not responsible for?
I think you don't need a certificate for a transport-encrypted connection. But if I already pay for a certificate, then it should also be a trustworthy one. The next question would be whether my provider would accept a certificate with a bad reputation or just reject it like a self-signed certificate. The answer to this question doesn't matter to me because I am blacklisted behind a DSL connection. As I wrote earlier, I prefer Stunnel for the secure connection to my provider's smart host. Simply because I miss some configuration options in Mercury (blocking older/insecure ciphers etc) and without documentation... This is my personal opinion. Maybe some thoughts are not fully considered yet.
<p>I experienced an issue that prevented MercuryC from being able to access the SMTP server. During troubleshooting I moved all of the QCF & QDF file out of the queue directory. Once I got MercuryC working I moved the files back to the queue but they haven't been processed. I there a way to make that happen?</p><p> </p>
We would need something to work with to try to figure it out, like a CNM file and a screen dump how the date displays in the email client. If you prefer not to post it here I can give you an email address to send it to.
Now, in the evening, when all staff has left the office, I was able to restart the entire Windows Server 2016, not only Mercury. And now Mercury I is working again as expected [:D][:D][:D]. But still have no idea why it failed.
The OpenSSL team publishes source code only, and expects that operating system maintainers (mainly Linux but also the communities for Apple and Windows) to compile it themselves into executable code and redistribute those compiled copies in the usual fashion.
While there's and some random person on the Internet who do the compilation work and provide executables as a service for the Windows community, the rule with security-sensitive software like this is that it's only trustworthy if you compile it yourself from source code that you've confirmed matches the official release's source code, using a compiler that you know to be good and trustworthy. David's tried to do that a few times, and I appreciate him putting in the effort to make sure we're safe, but the last we heard he couldn't get the resulting executable to say it was compiled correctly.
On a side note, I don't recommend using the binaries I've linked above with the current versions of Pegasus and Mercury. The 1.1.1 releases refuse to work at all. The 1.0.2 releases do work, to a point. And then someone using Outlook Mail for iPhone tries to connect over IMAPS and pull a few thousand messages and a mismatch in memory allocation causes Mercury to crash. But using 1.0.2 and dealing with the constant crashes is better, for me in my situation, than using the copy that came with Mercury that doesn't support TLS 1.2. That said, I eagerly await an official Mercury update with up-to-date OpenSSL.
I already have my own smtp server, which is the one I'm trying to use. I also have SPF, DKIM, and DMARC fully set up. I also run my own DNS server. I've actually already left Gmail now. I'm switching my users over to Thunderbird as an email client, and using Mercury as the server. So far so good. By the way, across different Gmai laccounts, the exactly same settings are garnering different results. Something in Gmail's sending is truly broken right now. It's intermittent at best.