Spam filter blacklists and ISP DNS

This is something that i discovered a long time ago, however every once in a while i forget it's an issue and it bites me in the ass. If you implement a DNS Blacklist (DNSBL/RBL) or URL Blacklist (URIBL/URLBL), you better make sure that the DNS servers your mail server and/or spam software use are not trying to be smarter than they are.

I had a client where we recently deployed an exchange server on-site. Everything was tested and working fine, then the next day they inform us that all of their emails are going to their junk folders. So i pull up the logs, and sure enough every email is either getting caught in the DNS Blacklist or URI DNS Blacklist. The culprit in this case was Roadrunner's DNS servers.

During my investigation i sent a mostly blank email from Outlook through my Gmail account to see what it would do. Based on the debug logs, i found that (as it should) the spam filter (GFI MailEssentials in this case) extracted multiple URLs from my email. Most of them were nonsense (references to Microsoft classes), but one of them was causing the issue. The spam software had found that www.w3.org is listed on a SPAM URI Blacklist (multi.surbl.org) and so the message was deemed to be spam.

A little closer investigation found the following when looking it up:

> www.w3.org.multi.surbl.org
Server:  UnKnown
Address:  ::1

Non-authoritative answer:
Name:    www.w3.org.multi.surbl.org
Address:  204.232.137.207

As some of you may know w3.org are the people in charge of the standards for the web, so obviously their site is legitimate. As some of you may also note, DNS Blacklists are supposed to respond with localhost IPs (127.0.0.0/8), not a routable address. Sure enough, if you browse to that IP returned, you get a Roadrunner search page. This could be considered partially the fault of GFI for accepting it even though it's not a localhost address, but i'll blame Roadrunner in this case.

The solution for the client was of course to change their DNS servers to something else and clear the cache. I don't know how Roadrunner (and i know they're not the only one) can be so naive to think that they can just send people to a search page when they're being stupid, but hopefully this will save someone a headache.

Adtran Total Access Console Wiring

So Adtran has a series of CSUs and Channel banks under the Total Access line that do not have the "modern" DB9 for accessing the console. As far as i can tell, this involves anything under the Total Access 600 series (600R, 604, 608, 612, 616, 624). I needed to get into one today but found that it only has an RJ45 "Craft" port, and none of my DB9/RJ45 adapters and cable combinations worked. I also found that the internet is plain wrong, and none of their solutions worked correctly, so i took it upon myself to figure it out. Note that the manual indicates that this is a proprietary adapter, however they were kind enough to give the pinouts of the unit itself.

Basically if you don't care about flow control, you can set it up pretty easily with just 3 wires. To make my life easy, i did this with a section of Cat5e and two RJ45 keystones, but you can easily adapt this to be an inline cable or something else.

The first thing i did was map out how my RJ45 to DB9 adapter was wired. I believe this is pretty standard (i checked a few of mine), but you may have to pull yours apart to make sure. In the table NC means not connected and i'm assuming that you are using EIA/TIA-568B for wiring.

DB9 Pin	RJ45 Pin	Cat5e Color
1	NC
2	3	Green/White
3	6	Green
4	8	Brown/White
5	5	Blue/White
6	NC
7	7	Brown
8	1	Orange/White
9	NC

The next step was to make the adapter to work for this proprietary Craft port. I took the two keystones and a small length of Cat5e and did the following:

1. Punch in one end as EIA/TIA-568B (Orange/White, Orange, Green/White, etc.)
2. Punch in the other end as follows:
   

   Keystone Pin	Keystone Color	Cable Color
   1	Orange/White	Blue/White
   3	Green/White	Green/White
   5	Blue/White	Green

At this point use any straight-thru cable to go from the keystone to your adapter, and to the unit, and you should be done. Note that this is a basic implementation and does not provide flow control, so you will need to disable that. The settings you would want to use are 9600/1/none/none (baud/stop/parity/flow). Also note that this cable can't be reversed, the side terminated normally should plug into the Adtran.

In case anybody is interested, Pin 1 is the Ground, and Pins 3/5 are Transmit and Receive. In this case, the RJ45 Craft port on the Adtran uses 3 for RX and 5 for TX, so you have to swap those around for the sending side. Pins 2 and 8 are used for Flow Control which i did not wire in. Pins 4 and 6 are DTR (Data Terminal Ready) and CD (Carrier Detect) which i also left unattached.


Update: Here is how you would make it if you want to use a pre-made Cisco console cable (one of the teal RJ45 to DB9 ones). Still terminate the first keystone with EIA/TIA-568B, then use this pinout for the second one:

Keystone Pin	Keystone Color	Cable Color
1	Green/White	Blue/White
3	Green	Green/White
5	Blue	Orange/White

Exchange 2007 and 2010 Public Folder Oddities

Was working with migrating an Exchange 2007 environment up to Exchange 2010, and ran into some strange issues with Public Folders (don't they always have the fun problems?).  For this migration I was going to add a replica to the 2010 server and then once the mailboxes were migrated remove the replica from the old server.  Seems simple enough, right?

If you go to the Public Folder Management Console on the 2007 server, you can easily go to the properties of a folder and add the replica right there.  That seems pretty easy, and for a small environment it certainly is.  However when you need to migrate hundreds of folders, that's not practical.  You might think "well i can just pipe a few powershell commands together and get it added" and you are right.

However, there is a handy script that is bundled with Exchange 2007/2010 in the Scripts directory (in the Program Files directory for Exchange) called AddReplicaToPFRecursive.ps1.  This is supposed to go through every public folder and add the new server to the list of replicas so it will replicate.

Here is what they expect you to run on the 2007 server (for all examples, EX2010 and EX2007 refer to your Exchange 2010 and 2007 servers respectively):

> .\AddReplicaToPFRecursive.ps1 -TopPublicFolder "\" -ServerToAdd EX2010

This command will run and probably not give any errors.  However, if you do a quick check you will see that nothing has happened:

> Get-PublicFolder "\Test1" | Select-Object Replicas

Replicas
--------
{EX2007\Second Storage Group\Public Folder Database}

Well clearly that isn't right, where is the 2010 server?  The issue is that it will not error out or give you any indication that you should have actually been running this on the 2010 server, not the 2007 server.  So at this point you need to switch to the 2010 server and run:

> .\AddReplicaToPFRecursive.ps1 -TopPublicFolder "\" -ServerToAdd EX2010 -Server EX2007

Note that there is an extra parameter in here now (which is suspiciously missing from most of Microsoft's examples, as they expect you to run this on the 2007 server).  After running this command if you want instant satisfaction you may want to run Update-PublicFolderHierarchy -Server EX2007, or wait for the replication interval.

Now if you go and look, the folders should start appearing and being replicating items.  You can tell with the original test command:

> Get-PublicFolder "\Test1" | Select-Object Replicas

Replicas
--------
{Public Folder Database 2,EX2007\Second Storage Group\Public Folder Database}

You can also check the current progress for replication with something like this (run on both servers to compare):

> Get-PublicFolderStatistics | Measure-Object -Property ItemCount -Sum

This will show the total items that have been replicated so far (look at the Sum).

Nortel BCM and T1s from an Adtran TA 908e

I recently had a customer with a "dynamic T1" where the voice is being carried over VoIP and handed off using an ADTRAN Total Access 908e via T1.  The customer's PBX was a Nortel BCM-200 with an older software version.

The issue that was run into is that the BCM does not support In-band ANI (Caller ID).  In-band is where the Caller ID is sent during the rings, so nothing special is required.  If this is not supported, then you have to do some extra work to get it going.  The easiest solution to this is to just switch to a PRI, so then everything is done on the D channel and there are no issues.  The problem here was that the software version of the BCM did not support the feature to add a synthetic dial tone when making a call, which the customer was not able to live without.

With this specific customer, they previously had a Voice T1 directly from the phone company.  This was configured the "old way" so when a new call came in it would send *ANI*DNIS* to the PBX.  For those unfamiliar with this, I'll explain.  Basically on a T1 trunk, the phone company will send digits to the PBX indicating what number was called.  These are usually used for DIDs (Direct Inward Dialing).  In this case, the customer was receiving 4 digits (the last 4 digits of the number).  So if I'm calling from (800) 444-4444 to (888) 555-1212, the PBX will receive *8004444444*1212*.  It knows based on the asterisks which numbers are which, and routes accordingly.

The original Adtran config looked like this (I added comments with ! to explain commands):

voice trunk T02 type t1-rbs supervision wink role network
  !any calls received on this trunk should use this caller id
  caller-id-override number-inbound 8885551212

  !send 4 digits of the called number to the PBX
  did digits-transferred 4

  !provide dialtone whenever a line is seized on this trunk
  dialtone

  !connect this trunk to a T1 interface
  connect t1 0/3 tdm-group 3

Likewise, this is the original PBX config:

The issue with this configuration is that outbound calls work fine, however inbound calls receive a fast busy.  The reason is because the ANI Number option is set to Y in the BCM configuration, but the Adtran is not sending *ANI*DNIS*, it's only sending DNIS.  But don't worry, there is a solution!

The following Adtran config works to send *ANI*DNIS* for incoming calls, but not expect it for outgoing calls, which is the desired configuration.

voice trunk T02 type t1-rbs supervision fgd role network
  caller-id-override number-inbound 8885551212
  dialtone

  !same as the did line before, just a different syntax
  dnis-digits 4 prefix ""

  connect t1 0/3 tdm-group 3

Two additional notes here:

1. There is also a command under this context fgd inbound-address which causes this trunk to expect *ANI*DNIS* on outgoing calls.
2. If you already have your trunk configured for wink supervision (type t1-rbs supervision wink), you will have to remove the trunk (no voice trunk T02), then add it in again, and then add it back to the voice grouped-trunk that it should belong to.

Oh look, another blog...

This blog basically will serve as a place for me to post technical issues i run across on a day to day basis.  These usually will fall into the sysadmin realm (networking, Microsoft server products, Linux/BSD, etc.).  Occasionally i expect to get angry and complain, you can ignore those posts. Hopefully those obscure issues that nobody seems to have an answer to will lead you here, and you will leave with some of your hair still attached to your scalp.