We use the Pegasus public folders for archiving and filing. Since e.g. appointments sent from Outlook are not displayed in Pegasus, some colleagues use Outlook and Pegasus in parallel as mail programs. Unfortunately, simultaneous access to an account (with Pegasus directly and with Outlook via the Mercury IMAP interface) is not possible.
Mercury will prevent IMAP access to the account while Pegasus is open. Is it possible to change this way of working, especially since there should be no problems with Pegasus > 4.0 (see note when installing Mercury)?
If you use both the IMAP server and locally installed copies of Pegasus v3.x to access maiboxes, you must ensure that you never access the same mailbox using both at the some time.
So, you must not start a copy of Pegasus Mail accessing a mailbox that is currently being accessed by the IMAP server. Equally, you must not login via IMAP to a mailbox that is currently being accessed by a copy of Pegasus Mail.
Failure to observe this requirement may result in damaged folders and loss of data!!
Note that it is OK for multiple IMAP connections to exist to the same mailbox. The prohibition only applies to simultaneous access by MercuryI and Pegasus Mail. This problem was addressed in Pegasus v4.0, and only applies if you are using an earlier version of Pegasus Mail to access your IMAP mailboxes.
Maybe for the last month or so, when viewing mail in the New Mail folder, I have been receiving emails where the From field and/or the Subject field are blank.
When I examine a regular email using the Raw View, I see that those fields are plain text (appropriate email addresses or subject text). When I examine an email where the From field or Subject field are blank, I see something like this:
From: =?UTF-8?B?4oCq4oCq4oCq4oCq4oCqTmV1cm9wYXRoeVRyZWF0bWVudEdyb3Vw4oCq4oCq4oCq4oCq4oCq?= <deleted for privacy>
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.