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 18.104.22.168/8, so if your IP lands in this range (22.214.171.124-126.96.36.199), 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.
If you happen to be using an external mail filtering service or appliance, one of the critical setup steps is to ensure that MDaemon is configured to not accept messages that attempt to bypass your mail filtering service as spammers look ways to bypass filtering gateways.
There are multiple ways to accomplish this in MDaemon, but one of the easiest ones is often overlooked: IP Shield. IP Shield is a very simple feature, it provides an administrator a simple way to tell MDaemon to only accept mail from a particular domain if it matches one of the listed IP addresses. Once upon a time, this was used to prevent spammers and others from forging one’s own domain, but there are better ways to accomplish this in MDaemon now, so today, we’ll use IP Shielding in another way: By using wildcards. With a wildcarded sender domain, you can use IP Shield to ensure that MDaemon will only accept mail if it’s from a pre-defined IP address or uses authentication.
Open the Security menu
Click on Security Settings
Under Sender Authentication, open the IP Shield dialog
Uncheck Do not apply IP Shield to messages sent to valid local users
Check Do not apply IP Shield to authenticated sessions
Check Do not apply IP Shield to Trusted IPs
Check IP Shield honours aliases
Uncheck Check FROM header against IP Shield
In the Domain field, enter *
In the IP field, the IP address of your mail filtering gateway
Repeat these steps to add any other IPs that should be allowed to send mail without authentication.
Note that you can use wildcards and CIDR notation for IP addresses here.
Since users should be configured to use authentication, this will not impact normal user traffic, but it will block any unauthenticated attempt to send mail unless the IP matches one of the entries.