Repeated Blacklisting / IP reputation

Tom Pipes tom.pipes at
Tue Sep 8 20:58:47 UTC 2009

I am amazed with the amount of thoughtful comments I have seen, both on and off list. It really illustrates that people are willing to try to help out, but there is an overall lack of clear direction on how to improve things.  Most of us seem to adopt that which has always just worked for us. Don't get me wrong, I'm sure there are a lot of improvements/mods going on with RBL operators in terms of the technology and how they choose who to block.  I'm also certain that most of the carriers are doing their best to follow RFCs, use e-mail filtering, and perform deep packet inspection to keep themselves off of the lists. AND there seems to be some technologies that were meant to work, and cause their own sets of problems (example:  allowing the end user to choose what is considered spam and blacklisting based on that).  As was said before, it's not the "WHY" but rather how can we fix it if it's broke.

The large debate seems to revolve around responsibility, or lack thereof. In our case, we are the small operator who sits in the sidelines hoping that someone larger than us, or more influential has an opinion.  We participate in lists, hoping to make a difference and contribute, knowing that in a lot of cases, our opinion is just that:  an opinion.  I suppose that could spark a debate about joining organizations (who shall go nameless here), power to the people, etc.

It seems as though a potential solution *may* revolve around ARIN/IANA having the ability to communicate an authoritative list of reassigned IP blocks back to the carriers.  This could serve as a signal to remove a block from the RBL, but I'm sure there will be downfalls with doing this as well.

In my specific case, I am left with a legacy block that I have to accept is going to be problematic. Simply contacting RBL operators is just not doing the trick. Most of the e-mails include links or at least an error code, but some carriers just seem to be blocking without an error, or even worse, an ACL... 

We will continue to remove these blocks as necessary, reassign IPs from other blocks where absolutely necessary, and ultimately hope the problem resolves itself over time.

Thanks again for the very thoughtful and insightful comments, they are greatly appreciated.


Tom Pipes 
T6 Broadband/ 
Essex Telcom Inc 
tom.pipes at 

----- Original Message ----- 
From: "Tom Pipes" <tom.pipes at> 
To: nanog at 
Sent: Tuesday, September 8, 2009 9:57:58 AM GMT -06:00 US/Canada Central 
Subject: Repeated Blacklisting / IP reputation 


We obtained a direct assigned IP block from ARIN in 2008. This block has been cursed (for lack of a better word) since we obtained it. It seems like every customer we have added has had repeated issues with being blacklisted by DUL and the cable carriers. (AOL, AT&T, Charter, etc). I understand there is a process to getting removed, but it seems as if these IPs had been used and abused by the previous owner. We have done our best to ensure these blocks conform to RFC standards, including the proper use of reverse DNS pointers. 

I can resolve the issue very easily by moving these customers over to our other direct assigned block. In the last year I have done this numerous times and have had no further issues with them. 

My question: Is there some way to clear the reputation of these blocks up, or start over to prevent the amount of time we are spending with each customer troubleshooting unnecessary RBL and reputation blacklisting? 

I have used every opportunity to use the automated removal links from the SMTP rejections, and worked with the RBL operators directly. Most of what I get are cynical responses and promises that it will be fixed. 

If there is any question, we perform inbound and outbound scanning of all e-mail, even though we know that this appears to be something more relating to the block itself. 

Does anyone have any suggestions as to how we can clear this issue up? Comments on or off list welcome. 


Tom Pipes 
T6 Broadband/ 
Essex Telcom Inc 
tom.pipes at 

More information about the NANOG mailing list