Are you using Let’s Encrypt with MDaemon or SecurityGateway (or anywhere else)? If so, great! But due to a bug re-validating CAA records, Let’s Encrypt will be revoking a subset of otherwise valid certificates. This bug has existed since 2019-07 and therefore could apply to any certificate issued prior to the fix which was applied 2020-02-29.
So what should you do? Well, luckily there is a tool to check your certificate, so you should check to see if your certificate is being revoked and if so, issue a new certificate as quickly as possible.
Modern browsers don’t check certificate revocations immediately or on all requests, so just because your browser works does not mean there is no impact! If your certificate is revoked you may see an impact some time in the next week or so, or you might not see it at all while users of other operation system / browser / client combinations may have a different experience.
One of the advantages of running my own MDaemon server is that I keep an eye on a lot of the spam and abuse that’s floating around on the internet.
Over the years I’ve put together a list of EHLO strings that can be used by MDaemon’s host screening tool to block inbound connections. Most of these are invalid based on their syntax, but yet are hitting a reasonable number of spam delivery attempts. Find the HostScreen.dat file \MDaemon\App directory and add the following:
all localhost refuse
all user refuse
all friend refuse
all -* refuse
all *_* refuse
all #.#.#.# refuse
all *.invalid refuse
all *# refuse
all */* refuse
all *|* refuse
all ylmf-pc refuse
Save the file, and then create a “hostscreen.sem” in the \MDaemon\App directory to reload the contents of the HostScreen.dat file.
If you haven’t used MDaemon’s semaphore (SEM) files before, the following command will do it:
echo. > C:\MDaemon\App\hostscreen.sem
I have yet to observe any false positives, although it’s not impossible, so watch your logs if you’re worried.
I do periodically update this list, and if anyone has any entries to contribute, please do so in the comments. When the post is updated, it will be promoted to the top of the list, but generally no email notifications will be sent.
There appears to be a DNSSEC issue with reverse DNS records on 188.8.131.52/8, so if your IP lands in this range (184.108.40.206-220.127.116.11), you’re probably going to find yourself unable to send much email today.
The issue is DNSSEC related, so this will only impact receivers who use DNSSEC resolvers, but as Word To The Wise points out, this is nearly every major mail server today.
Hopefully arin.net is working on the problem, but due to TTLs and caching, DNS issues can linger for a couple of days.
As a sender, what can you do? Well, mostly, nothing but wait it out. As a receiver, you could exempt rDNS checks from this IP range, or just make sure that your mail server returns a temporary (4xx) failure and not a permanent failure for DNS errors on reverse DNS queries, such that mail queues up and is re-delivered rather than refused.