I'm using Smartermail for my small mailserver. We've been having a problem lately of getting waves of snowshoe spam that follow the same pattern. They come in batches of 3 or 4 at a time. The bodies are almost identical save for the domain name they link to. The source IPs tend to be from the same /24 block for awhile, then they switch to another /24. The domains tend to be brand new. They have valid PTR and SPF records and have random gibberish at the bottom of the body to spoof bayesian filters.
I'm using a dozen or so different RBLs including Barracuda, Spamhaus, SURBL and URIBL. They do a decent job catching most of them, but we still get a lot the slip through because the IPs and domains haven't been blacklisted.
Are there any strategies I can employ, including RBLs that block newly created domains or deal specifically with snoeshow spam? I'm hoping to avoid having to use a 3rd party filtering service.
Is this becoming a real problem for your users?
I'd recommend a full-on mail filtering service at this point. Bayesian isn't really that hot anymore. Reputation, RBL, header/intent-analysis and other factors seem to help more. Consider a cloud filtering service to combine multiple approaches (and collective volume) to provide better protection (I use Barracuda's ESS cloud solution for my customers).
And of course: Fighting Spam - What can I do as an: Email Administrator, Domain Owner, or User?
We haven't been affected negatively by the uptick in the Snowshoe attacks. I did see a period where mail volume tripled day-to-day with these attacks. But none of the bad stuff made it through. In 3 days, Barracuda brought volumes down to normal levels.
I think filtering solutions that have a broad view of worldwide mail activity can react to attacks better than individual mail filters.
Edit:
This was also discussed recently on the LOPSA mailing list:
My contribution: https://www.mail-archive.com/[email protected]/msg04180.html
Another opinion: https://www.mail-archive.com/[email protected]/msg04181.html
I'm a DNS Ops guy who works closely with a group who is frequently subject to these attacks. Dealing with Snowshoe attacks is primarily a process problem, and as ewwhite points out it may beyond the scope of your company to solve in-house. I'd go as far as to say that unless you have a sizable operation and several commercial RBL feeds, you probably shouldn't be trying to solve this yourself over using a commercial filtering service.
That said, we do have some experience with this and it's more interesting to share than not. Some touch points are:
UDP-MIB::udpInErrors
via SNMP, because mail platforms are very capable of overflowing the receive queues of UDP listeners when a Snowshoe attack is in progress. If they aren't, a quick way to tell under Linux is to runnetstat -s | grep 'packet receive errors'
on the DNS servers in question; a large count indicates that they need to get off their duffs and start paying attention. They will need to add capacity or increase the size of the receive buffers if frequent spillage is occurring. (which means lost DNS queries, and lost opportunities for spam prevention)Full disclosure: Farsight Security was founded by Paul Vixie, who I have a bad habit of venting at when people violate DNS standards.
I installed Declude (which is free) and Message Sniffer (which isn't) and over the past 4 days I've seen one spam message come in my test email account, as opposed to the dozens it was getting per day. As far as I can tell, we haven't had good email filtered out. Spamassassin would probably also be a good solution although I didn't have any luck with it when I tried Spam Assassin in a Box..
A lot of the answers here are for general anti-spam. To a degree, this makes sense since spammers seem to be heading towards snowshoe as a preferred delivery method.
Snowshoe was originally always sent from datacenters in low volume (on a per-IP basis) and always included an unsubscribe link (to say nothing about whether it works). Nowadays, snowshoe almost never has unsubscribe information and is sent in high volume from its IPs, but is sent in a burst so that by the time the IP gets blacklisted, it's already done sending mail. This is called hailstorm spam.
Because of this, DNSBLs and even tight pattern-based signatures are horrible at catching snowshoe spam. There are some exceptions, such as the Spamhaus CSS list (which is specifically aimed at snowshoe networks and is a part of both SBL and ZEN), but in general you'll need greylisting/tarpitting (which can delay delivery until the DNSBLs catch up) and, most importantly, a token-driven machine learning system like Bayesian spam filtering. Bayes is particularly good at detecting snowshoe.
Andrew B's answer mentions Farsight Security's Newly Owned Domains and Hostnames (NOD), which tries to anticipate snowshoe networks as they're spun up but before they start spamming. Spamhaus CSS likely does something similar. CSS is ready for use in a blocking environment, while NOD is really designed to be a feed to a custom system rather than a standalone/blocking system.