Incorrect rejection messages

At least one ESP and Spamhaus are currently investigating bounce messages at a couple ISPs incorrectly pointing to Spamhaus as the reason for the block. The bounce messages are taking the form:

smtp; 554 p3plibsmtp03-07.prod.phx3.secureserver.net bizsmtp IB105. Connection refused. 192.0.2.24 is
listed on the Exploits Block List (XBL) <http://www.spamhaus.org/query/ip/192.0.2.24> Please visit http://www.spamhaus.org/xbl/ for more information.
smtp; 553 5.7.1 [BL21] Connections will not be accepted from 192.0.2.59 because the IP is Spamhaus’s list; see http://postmaster.yahoo.com/550-bl23.html
smtp; 553 5.7.1 [BL21] Connections will not be accepted from 192.0.2.136, because the ip is in
Spamhaus’s list; see http://postmaster.yahoo.com/550-bl23.html

The IPs involved are not listed on any of the Spamhaus lists. It looks like there’s some corruption somewhere. I’ve heard about this from a couple different places, so if it’s happening to you it’s not just you. It’s also being addressed by people who can fix it.

Related Posts

SMTP Level Rejections

While discussing a draft of a Deliverability BCP document the issue came up of what rejections at different phases of the email delivery transaction can mean. That’s quite a big subject, but here’s a quick cheat sheet.
At initial connection
Dropped or failed connection:

Read More

Filtering secret sauce

It seems one of the most asked questions I hear from people is about filters and what the secret sauce is.

Read More

Abuse it and lose it

Last week I blogged about the changes at ISPs that make “ISP Relations” harder for many senders. But it’s not just ISPs that are making it a little more difficult to get answers to questions, some spam filtering companies are pulling back on offering support to senders.
For instance, Cloudmark sent out an email to some ESPs late last week informing them that Cloudmark was changing their sender support policies. It’s not that they’re overwhelmed with delisting requests, but rather that many ESPs are asking for specific data about why the mail was blocked. In December, Spamcop informed some ESPs that they would stop providing data to those ESPs about specific blocks and spam trap hits.
These decisions make it harder for ESPs to identify specific customers and lists causing them to get blocked. But I understand why the filtering companies have had to take such a radical step.
Support for senders by filtering companies is a side issue. Their customers are the users of the filtering service and support teams are there to help paying customers. Many of the folks at the filtering companies are good people, though, and they’re willing to help blocked senders and ESPs to figure out the problem.
For them, providing information that helps a company clean up is a win. If an ESP has a spamming customer and the information from the filtering company is helping the ESP force the customer to stop spamming that’s a win and that’s why the filtering companies started providing that data to ESPs.
Unfortunately, there are people who take advantage of the filtering companies. I have dozens of stories about how people are taking advantage of the filtering companies. I won’t share specifics, but the summary is that some people and ESPs ask for the same data over and over and over again. The filtering company rep, in an effort to be helpful and improve the overall email ecosystem, answers their questions and sends the data. In some cases, the ESP acts on the data, the mail stream improves and everyone is happy (except maybe the spammer). In other cases, though, the filtering company sees no change in the mail stream. All the filtering company person gets is yet another request for the same data they sent yesterday.
Repetition is tedious. Repetition is frustrating. Repetition is disheartening. Repetition is annoying.
What we’re seeing from both Spamcop and Cloudmark is the logical result from their reps being tired of dealing with ESPs that aren’t visibly fixing their customer spam problems. Both companies are sending some ESPs to the back of the line when it comes to handling information requests, whether or not those ESPs have actually been part of the problem previously.
The Cloudmark letter makes it clear what they’re frustrated about.

Read More