Spam protection tips in 2024
Hello community,
I am looking for some update on spam fighting techniques in 2024. I think we haven't touched our config for years and now as we are moving to new servers - suddenly started getting more spam (with the same config, I believe). Also have some customers, coming from other provider (with cPanel) who complains, that they were getting much less spam at previous hosting provider..
So looking for modern tips!
Cheers!
-
Hey there! Is it possible the old system just had years of training with SpamAssassin and it had just better learned what to mark as spam for your clients? That's the first thing that comes to mind as I don't have any top secret modern tricks that aren't already well-known.
There are some generic details here about what options are available, although some of the names and links could be slightly out of date: https://blog.cpanel.com/spam-filtering-on-cpanel-everything-you-need-to-know-about-spamassassin/
This guide has more specifics about ways you can block spam on your system: https://support.cpanel.net/hc/en-us/articles/1500005742201-How-to-reduce-the-amount-of-incoming-spam-on-a-cPanel-server
0 -
i see.. pretty much everything, that we are already doing.. but the learning part - can some database be transferred, shared or merged from other servers? And any simple quick way to check, that it's actually learning?
Recently gmail and microsoft tightened their policies - for a few months they really want domains to have dmarc / spf or dkim. in regards to that - we can choose to reject dkim failures. What about SPF failures? Does SPF failures are always rejected?
And question about resolving DNS - this relates to spam protection. There are rules, that check in different RBL for links in emails. Those never work, if we use resolving nameservers from our datacenter or public google or Cloudflare ones. Even though we use DNS cluster - each server will still have their own local nameserver for DNSSEC support. So the question is - can local powerdns also act as local caching resolving nameserver? Then we could instruct spamassassin to use it for dns queries. - or how safe would it be to set powerdns listen on public interface and install powerdns-recursor for local interface? Any bells ringing for you with such setup?
0 -
And how can we (or customer) train spamassassin? Especially server or multiple-server wide? After all - quite often spam campaigns produce quite similar emails. ;)
0 -
The official guide to training SpamAssassin can be found here:
If SpamAssassin was enabled on the old machine before the migration, I would expect the data to be migrated. You'll find this information in /home/username/.spamassassin - specifically the "bayes_seen" file are things that it has trained on. If that file is empty or very small, or doesn't have a recent timestamp, it may not be actively used.
0 -
Any news on using powerdns-recursor with cPanel? In big datacenters provided DNS is always blocked because RBL services receive huge queries volume from them.
Only option is using your own recursive DNS server, not provided with cPanel since Bind deprecation.
0 -
Keep in mind that with Spamhaus if you do not have your own resolvers that can be used for your spamassassin / mail queries, you can sign up for Spamhaus' DQS service (which is typically for free at the same volume of queries, I think) . So all hope is not lost when it comes to using Spamhaus.
Otherwise, just spin up a couple of $5/mo deals at Digital Ocean, configure Bind on them to only resolve for your hosting servers, and then set your hosting server resolvers to the IP addresses of the Digital Ocean droplets. For only a few more dollars a month per droplet you can have them backed up.
1 -
Thanks for your suggestion, mtindor. It's a pity cPanel doesn't provide a solution for installing PowerDNS Recursor natively. I was trying other options but seems that running my own instance of server with Bind is the way to go right now.
0 -
Ideally we'd all block emails that didn't pass SPF, DKIM or DMARC. Unfortunately, it amazing how many reputable and large companies end up not passing SPF or DKIM or DMARC. It's even worse with smaller companies that don't have IT staff. If you become a hardline blocker of email based upon SPF, DKIM and DMARC, be prepared to have angry customers telling you that their correspondents are unable to send email to them -- and then you have to go chase down and exempt them. I'm NOT saying that you shouldn't attempt to leverage SPF / DKIM / DMARC for blocking. I am saying that it will put an additional burden on you as server admin. If you don't want your customers to totally hate you and leave, you have to proactively monitor SPF / DKIM / DMARC rejections and exempt stuff before you customer even realizes that one of their correspondents was blocked.
I run a lot of mail through Barracuda Networks Cloud Control and Appliances, and I block on DMARC, DKIM and SPF failures. I am in the Cloud Control dashboard at least twice a day looking for legitimate emails that were blocked so that I can exempt those companies from the blocking before my customers realize it. It's a royal pain in the ass. But if I didn't do it, my customers would be blaming me because their correspondents can't send mail to them - rather than my customers placing the fault on the senders for not properly authenticating their emails.
It all depends on how many hours of your life you want to waste on babysitting the mailsystem to keep your customers happy. Sure, they can't stand spam / viruses / phishing emails, but they hate even more when they can't get email from somebody they are expecting email from.
Make sure you use greylisting. it is effective. Sometimes you'll have to add exemptions to greylisting after customers complain that some emails to them (like password resets and things like that) don't make it to them in a timely fashion, or at all, but you don't have to regularly babysit greylisting.
0
Please sign in to leave a comment.
Comments
8 comments