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.

  • 2
    I recommend editing your title to make this less pointed in the direction of "which product should I use", because shopping questions are off-topic for Stack Exchange sites. Snowshoe attack mitigation is a good topic for ServerFault though, and I'll ask a colleague of mine to comment. – Andrew B Nov 7 '14 at 16:28
  • Helpful to know what Snoeshow spam is. – ewwhite Nov 7 '14 at 16:29
  • 1
    The majority of RBLs are free services that any mail admin can use. Does that count as shopping? – pooter03 Nov 7 '14 at 16:30
  • Yeah, because whether they're free or not, the answer is only valid for a particular window of time. (which that link touches on) Companies go out of business all the time, including those which provide free services. – Andrew B Nov 7 '14 at 16:54
  • 1
    I changed the question. Please let me know if this is more appropriate. – pooter03 Nov 7 '14 at 18:27

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.


This was also discussed recently on the LOPSA mailing list:

My contribution: https://www.mail-archive.com/tech@lists.lopsa.org/msg04180.html
Another opinion: https://www.mail-archive.com/tech@lists.lopsa.org/msg04181.html

  • 1
    They are starting to complain. It's only a few dozen customers and we are offering our mail service at low cost or even free as a bundle with other services we buy, so we were hoping to avoid paid services if possible. I'll investage that product however. – pooter03 Nov 7 '14 at 16:32
  • It's around $8/user/year. – ewwhite Nov 7 '14 at 16:33
  • Thanks. Consider this a virtual upvote until I get the rep to do so. :) – pooter03 Nov 7 '14 at 16:34
  • +1 for Barrucada. – poke Nov 7 '14 at 18:11
  • 2
    I still recommend Barracuda Cloud mail filtering. It's probably the cleanest solution to your current problem. – ewwhite Feb 20 '15 at 12:17

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:

  • If possible, training your mail platform to identify the characteristics of a Snowshoe attack in progress and temporarily rejecting messages from the networks in question. Well-behaved clients will try to resend messages on a temporary failure, others tend not to.
  • Making sure your DNS admins are monitoring 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 run netstat -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)
  • If you are frequently seeing these attacks utilizing freshly created domains, RBLs that highlight these do exist. An example of one is FarSight NOD (people reading this should perform their own research), but it is not free.

Full disclosure: Farsight Security was founded by Paul Vixie, who I have a bad habit of venting at when people violate DNS standards.

  • Your second point is particularly interesting. I've suspected that we are missing DNS queries to RBLs that had already blacklisted the IP or URL, but I haven't been able to prove it. However, the mailserver is on Windows 2012 and uses the Windows DNS server. It is a pretty low volume server but I want to investigate this further. Unfortunately it doesn't explain everything because some of the things that slip through hadn't had time for their domains or IPs to be caught by major RBLs yet. – pooter03 Nov 7 '14 at 18:35
  • The average volume of the DNS server won't matter so much. The chief characteristic of a receive queue overflow is not being able to process your incoming packets fast enough to get them out of the queue, and volume based Snowshoe attack is more than capable of achieving this depending on how many DNS lookups you're performing per spam. – Andrew B Nov 7 '14 at 23:08
  • 2
    Your first suggestion is commonly known as greylisting. – Nate Eldredge Nov 7 '14 at 23:36
  • 2
    @Nate It's a form of greylisting, but using that term unqualified would suggest to most people that this action be taken in response to the IP being newly observed. The attacking networks tend to spend time establishing connections (without sending headers) in preparation for synchronized payload delivery. That trait is what you're acting on, as it allows you to predict that IPs you haven't yet seen are involved in the attack. – Andrew B Nov 8 '14 at 0:01
  • For whatever it's worth, I have (a more general) greylisting enabled on the server and the spammers are properly responding after a certain period. For all intents and purposes, the email appears to be coming from legitimate mail servers with properly configured PTR records, SPF records, etc. – pooter03 Nov 10 '14 at 14:39

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.