What happened with the CBL false listings?

The CBL issued a statement and explanation for the false positives. Copying it here because there doesn’t seem to be a way to link directly to the statement on the CBL front page.

November 24, 2015 Widespread false positives
Earlier today, a very large scale Kelihos botnet event occured – by large scale, many email installations will be seeing in excess of 20% kelihos spam, and some will see their inbound email volume jump by a volume of as much as 500%. This isn’t an unusual thing normally, the CBL/XBL has been successfully dealing with large scale Kelihos spam spikes like this, often daily, for years.
The email was allegedly from the US Federal Reserve, saying something about restrictions in “U.S. Federal Wire and ACH online payments.” Not only was the notice itself fraudulent, the attached Excel spreadsheet (.xls) contained macro instructions (a downloader) to download a Windows executable virus, most likely Dyreza or Dridex malware.
The detection rules initially deployed by the CBL unfortunately were insufficiently detailed, and listed a number of IP addresses in error.
As per our policy, all entries of this type were purged (by about 19:05 UTC), and the detection heuristic removed.
If you were listed up to around 19:00 UTC, and the CBL lookup page appears to indicate that the IP is no longer listed, this is likely the explanation, and no further action is required on your part.

Out of curiosity I checked my own mailboxes. Since the first “Federal Reserve Spam” delivered at around 3:45 this morning, I’ve received 252 spams. 124 of those were the Kelihos bot spam. So it’s a good half of today’s spam volume. Yesterday’s total spam volume was around 328. A noticeable increase here.
 

Related Posts

Dealing with blocklists, deliverability and abuse people

There are a lot of things all of us in the deliverability, abuse and blocklist space have heard, over and over and over again. They’re so common they’re running jokes in the industry. These phrases are used by spammers, but a lot of non-spammers seem to use them as well.
The most famous is probably “I’m sure they’ll unblock me if I can just explain my business model.” Trust me, the folks blocking your mail don’t want to hear about your business model. They just want you to stop doing whatever it is you’re doing. In fact, I’m one of the few people in the space who actually wants to hear about your business model – so I can help you reach your goals without doing things that get you blocked.
A few months ago, after getting off yet another phone call where I talked clients down from explaining their business model to Spamhaus, I put together list of phrases that senders really shouldn’t use when talking to their ESP, a blocklist provider or an abuse desk. I posted it to a closed list and one of the participants put it together into a bingo card.
bingo__email__save_1
A lot of these statements are valid marketing and business statements. But the folks responsible for blocking mail don’t really care. They just want their users to be happy with the mail they receive.

Read More

Biggest botnet takedown to date

Yesterday law enforcement officials arrested 6 people and charged them with running a massive internet fraud ring. Over 4 million PCs were part of the botnet.
According to the FBI

Read More

Email verification services

Just yesterday a group of delivery folks were discussing email verification services over IRC. We were talking about the pros and cons, when we’d suggest using them, when we wouldn’t, which ones we’ve worked with and what our experiences have been. I’ve been contemplating writing up some of my thoughts about verification services but it’s a post I wanted to spend some time on to really address the good parts and the bad parts of verification services.
Today, Spamhaus beat me to the punch and posted a long article on how they view email verification services. (I know that some Spamhaus folks are part of that IRC channel, but I don’t think anyone was around for the discussion we had yesterday.)
It’s well worth a read for anyone who wants some insight into how email verification is viewed by Spamhaus. Their viewpoints are pretty consistent with what I’ve heard from various ISP representatives as well.
In terms of my own thoughts on verification services, I think it’s important to remember that the bulk of the verification services only verify that an address is deliverable. The services do not verify that the address belongs to the person who input it into a form. The services do not verify that an address matches a purchased profile. The services do not verify that the recipient wants email from the senders.
Some of the services claim they remove spamtraps, but their knowledge of spamtraps is limited. Yes, stick around this industry long enough and you’ll identify different spamtraps, and even spamtrap domains. I could probably rattle off a few dozen traps if pressed, but that’s not going to be enough to protect any sender from significant problems.
Some services can be used for real time verification, and that is a place where I think verification can be useful. But I also know there are a number of creative ways to do verification that also check things like permission and data validity.
From an ESP perspective, verification services remove bounces. This means that ESPs have less data to apply to compliance decisions. Bounce rate, particularly for new lists, tells the ESP a lot about the health of the mailing list. Without that, they are mostly relying on complaint data to determine if a customer is following the AUP.
Spamhaus talks about what practices verification services should adopt in order to be above board. They mention actions like clearly identifying their IPs and domains, not switching IPs to avoid blocks and not using dozens or hundreds of IPs. I fully support these recommendations.
Email verification services do provide some benefit to some senders. I can’t help feeling, though, that their main benefit is simply lowering bounce rates and not actually improving the quality of their customers’ signup processes.

Read More