Brief DBL false positive


Spamhaus are rolling out a new subzone of the DBL, for domains whose webservers have been compromised and used to host spam landing pages, often via mass compromises of their management control panels. There was a brief mistake that caused all of .net to be listed in the new subzone, meaning that mail sent with URLs in it that used hostnames in .net may have been rejected or spam-foldered by early adopters or careless users of the DBL.
If you’re using one of the reputation services that wraps many different sorts of listing in a single zone, differentiating between different listing reasons by return code, you should be aware of what all the subzones are and what listings of each type mean. Unless the blacklist operator has a published policy about what sort of sublists might be added in the future, you should never configure your mailservers to take action on any returned value, rather you should check for specific return values and ignore any response that you don’t explicitly intend to use.
If your MTA supports it, logging unrecognized responses and alerting based on them is a good idea – both so you know when a new category is added, and so you know if you’ve been blocked from accessing the blacklist, or the blacklist has been shut down and is listing the entire Internet. It’s not unusual for blacklists to see very high query volumes for months or years after they’ve been shut down, presumably from users who are using the data as part of  a scoring system and who haven’t noticed that it’s no longer providing any useful data.
 

Related Posts

IP Reputation

A throwback post from a few years ago on IP reputation.

Read More

Spamhaus on ESPs

Promoted from yesterday’s comments, Spamhaus comments on my discussion of filtering companies getting tired of ESPs.
You hit the nail square on, Laura.
As Laura knows but many here might not, I am with the Spamhaus project. At one time I was leading efforts to clean up ESP spam. I am not deeply involved with ESP listings any longer. I can however testify that ESPs ask Spamhaus volunteers for a great deal of information about their SBL listings, considerably more than most ISPs or web hosting companies. Certain team members avoid ESP listings except in extreme cases because they don’t want to spend that much time on one SBL.
Whilst I was doing many ESP listings, I attempted to provide requested information, often at great length, with mixed results. In one notable case, an ESP that I provided with a report on hits from that ESP’s IPs on our spamtraps took that report and turned around their entire business. They had been an average ESP: not worse than most ESPs, but not better either. It’s been about three years now. This ESP is now in any list of the least spam-friendly two or three ESPs in the business. I’m honored to have been able to contribute to that change, am delighted at the results, and have learned a great deal from that ESP’s abuse team, which is superb.
That hasn’t happened often, though. I’ve provided similar reports to a number of other ESPs; I try not to play favorites. It is Spamhaus policy not to treat ISPs, ESPs, web hosts, and others whose IPs are listed for spamming differently except based upon our observations of which responds to spam issues effectively and which do not. I would also rather see a spam problem fixed than a spammer terminated just to move somewhere else and continue to spam.
The spam flow from many ESP customers that I reported to the ESP dropped, then slowly rose to previous and often higher levels. There are strings of SBL listings as a spam problem is mitigated, then inexplicably (according to the ESP) comes back. I do not find most of those recurrences inexplicable. I conclude, in many cases, that the ESP is unwilling to do the proactive work necessary to catch most spam before it leaves their IPs, even when they know what needs to be done.
To make matters clear, the ESP representatives that I communicate with are not usually to blame for this problem. Their managers and the policymakers at the ESP are to blame. The decisionmakers at the ESP are not willing to require paying customers to adhere to proper bulk email practices and standards and enforce permanent sanctions against most who fail to do so.
Granted, some customers resist not because they are deliberately spamming non-opt-in email addresses, but because they think that quantity (of email) is more important than quality. Such customers don’t want to see lists shrink even when those lists are comprised largely of non-responsive deadwood email addresses. Such customers send a great deal of spam and annoy a great many of our users, who really do not care whether the spam problem is due to carelessness or deliberate action.
In other cases, of course, ESP customers resist following best practices because they cannot. They are mailing email appended and purchased lists. If they don’t maintain some sort of plausible deniability about the sources of those lists, they know that we will list their IPs (at the ESP and elsewhere) and refuse to remove those listings til they do.
In either case, an ESP that is unwilling to impose sanctions on customers whose lists persist in hitting large numbers of spamtraps after repeated mitigation attempts needs to fire those customers. Otherwise it is failing to act as a legitimate bulk emailer. Such ESPs must expect to see their IPs blocked or filtered heavily because they deliver such large quantities of spam compared to solicited email.

Read More

Domains need to be warmed, too

One thing that came out of the ISP session at M3AAWG is that domains need to be warmed up, too. I can’t remember exactly which ISP rep said it, but there was general nodding across the panel when this was said.
This isn’t just the domain in the reverse DNS of the sending IP, but also domains used in the Return Path (Envelope From) and visible from.
From the ISP’s perspective, this makes tons of sense. Some of the most prolific snowshoe spammers use new domains and new IPs for every send. They’re not trying to establish a reputation, rather they’re trying to avoid one. ISPs respond by distrusting any mail from a new IP with a new domain.

Read More