Microsoft Exchange Server 2010 includes a number of technologies to help administrators combat spam. Like any technology, there are times when you might need to troubleshoot these anti-spam measures, and in this new series for AllSpammedUp.com, we’re going to take a look at how to effectively diagnose and resolve issues that can come up with these technologies.
The IP Allow List allows you to whitelist the IP addresses that should always be allowed to deliver email with no further filtering. You can add other servers in your enterprise, or your key partner or customer systems. CIDR notation is supported, and so is IPv6. The IP Allow List is more of a “get passed other spam filter solutions” solution than it is an anti-spam solution, but it is still a critical component of the protections you may enable on the Exchange Edge Transport server role, or the Hub Transport server role.
It is also an IP address based list, not a domain name based list. This means that you must enter the specific host’s IP address in dotted decimal notation, or CIDR notation, or if you are already using IPv6, in IPv6 notation. You don’t enter fully qualified domain names in this; just ip.addrs. As such, you can run into problems with typographical errors, changing IP assignments, and NAT. All of these can result in a bypass entry not working the way you want it too.
Unless you really have a good reason not to, you should probably enter your entire internal address space into the IP Allow List. If you are using RFC 1918 private addresses, you can safely enter the three CIDR networks since these addresses are not routed on the Internet, and no external connections will source from one of these ranges. Those ranges in CIDR notation are
If you are using registered address space internally, enter all your internal network ranges.
There are many reasons why an organization might change the ip.addrs they use for sending email. Perhaps they move capacity to a new datacenter, or go with a new service provider. They might have to implement a disaster recovery scenario, or perhaps they choose to upgrade and the new servers are in a different datacenter. Since as an industry we always talk about how important it is to use DNS, you cannot count on your partners, vendors, and customers to give you advanced warning about changes in their IP address space. You can use the DIG or NSLOOKUP command to query DNS for the ip.addrs of a domain’s mail servers, and also to view their SPF records which should include the IP address space they might use for sending email. But you will probably also need to contact the admins of the other system directly if you cannot determine their addresses on your own.
Network Address Translation normally works at layer 3, and is used to extend network ranges or hide internal ranges from external ones. You may also run into NAT when you reverse proxy connections to the Internet through a product like Microsoft TMG Server 2010. Where I have seen this specifically cause problems is when to organizations establish a LAN to LAN VPN tunnel between them to route mail between Exchange organizations, but the use of NAT by one party’s network team to prevent having to make routing table entries is not something they informed the larger team about, and the source addresses on the IP Allow List did not match the source addresses in the IP header. Make sure that when you are working with VPN tunnels or reverse proxies you involve both the messaging and network teams when troubleshooting any issues, and have a good drawing on hand so everyone can understand what is happening on the network.
Troubleshooting IP Allow Lists
You can use the Exchange Management Shell (EMS) to query the configuration of the IP Allow List, and to make changes. Here are the basic commands you use.
The get-ipallowlistconfig command will dump the configuration of the IP Allow List.
The set-ipallowlistconfig command allows you to modify the settings for the IP Allow List.
The add-ipallowlistentry command adds ip.addrs to the list.
The remove-ipallowlistentry command removes ip.addrs from the list.
You can also use the DIG command or NSLOOKUP command to query DNS for relevant records. Here’s how to query for the MX and SPF records for example.com using DIG and a publicly accessible DNS server.
dig @22.214.171.124 –t MX example.com [enter]
dig @126.96.36.199 –t TXT example.com [enter]
Compare the addresses on your IP Allow List to those returned by the DIG command to make sure things match up. You can download a Win32 port of DIG from http://members.shaw.ca/nicholas.fong/dig/
With a better understanding of how IP Allow Lists work and the commands you can use to diagnose and configure them, you should be in a good position to quickly resolve any issues that might come up.