I often hear comments like “it’s no big deal”, and “just hit delete” while obsessing over tracking down and blocking spammers.
I stumbled across an interesting perspective that I wanted to share:
I think it’s worth noting that the largest cost of spam (and other forms of Internet-borne abuse) is not financial.
It’s time — irreplaceable, precious time. Do the math: construct an estimate for how many seconds it takes someone to realize that a message is spam and Just Hit Delete (TM); now multiply by all the someones doing that for the same spam message; now multiply by all the spam messages send in a day or a week or a year.
Then divide by the average human lifespan. The results are disturbing.
Luckily, MDaemon includes many tools that help you combat spam. Life’s too short to waste on deleting garbage that shouldn’t exist in the first place.
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.