Connection Filtering IP Accept List in Exchange SP2

[LEFT][CODE]http://exchangeinbox.com/article.aspx?i=44[/CODE]

[B]Getting the Connection Filtering IP Accept List to work became trickier since Exchange SP2. IPs configured to bypass the Intelligent Message Filter, sometimes have no effect. Luckily the solution is around the corner.[/B]

FirstPreviousPage 1[URL="http://exchangeinbox.com/article.aspx?i=44&t=3&p=2"]Page 2[/URL][URL="http://exchangeinbox.com/article.aspx?i=44&t=3&p=2"]Next[/URL][URL="http://exchangeinbox.com/article.aspx?i=44&t=3&p=2"]Last[/URL] [URL="http://exchangeinbox.com/article.aspx?i=44&t=3&all=1"]All Pages[/URL]
Exchange 2003 Connection Filtering enables trapping spam through Block List services. It also provides a means to configure IP Accept/Deny lists to allow/block emails originating from specific hosts. This functionality was available since the first Exchange 2003 release.
Accepted IPs enable emails to skip both Block List processing and the Intelligent Message Filter. Nevertheless, since Exchange SP2, complaints that IMF was not observing the IP Accept list started surfacing. A consistent number of problem reports at the public newsgroups indicated that indeed something changed in this area.
Newsgroups are a great place where peers share solutions and this is what happened in this case. Today's article highlights a problem that was reported and solved in this manner. Credits go to Shawn Beckers who posted the solution.
[B]Accept Lists Won't Work When...[/B]

I will now jump straight to the main point of this article. Those configuring Accept Lists for the first time may want to first check the [URL="http://exchangeinbox.com/articles/018/ipacceptlist2.htm"]Accept List Configuration[/URL] section. You will find this at the end of the article.
Connection and Sender ID Filtering both require the originating host IP in order to function. This information is directly available to internet facing email servers. On the other hand, if Exchange does not directly receive incoming emails, retrieving the IP address requires digging through the email headers. In this case Exchange must consider a number of IPs and pick the correct one. This requires determining which IPs belong to the local organization and which IPs belong to external hosts.
This became possible as from Exchange SP2. The Message Delivery object at the Exchange System Manager now enables configuring the set of IPs identifying local hosts. Armed with this information, Exchange can by elimination pinpoint the last external host IP before the email entered the organization.
Unfortunately this configuration may cause the IP Accept list not to work as expected. Thus we now look at how to setup this without running into problems.
[B]Identifying Local IPs[/B]

The set of perimeter IPs and the internal IP range are configurable as follows:

[LIST=1][*]From the Exchange System Manager open the properties for Global Settings | Message Delivery.[*] Select the General property page
[IMG]http://exchangeinbox.com/image.aspx?i=91[/IMG][*] Click the Add button to bring up the IP list.
[IMG]http://exchangeinbox.com/image.aspx?i=92[/IMG][*]In the dialog that opens click Add again to specify single IPs and IP ranges for the organization.[/LIST]
[B]Conflicts with Connection Filtering[/B]

It should already be quite clear where this is leading. Sender ID and Connection Filtering will scan an email for IPs. The search goes on until an IP not identified as local is found. This also means that emails originating from local servers skip Sender ID/Connection Filter processing altogether.
IMF relies on Connection Filtering to let through emails from hosts under the IP Accept list. Still emails skipping Connection Filtering also miss the possibility to be flagged as matching the IP Accept list. Thus IMF scans these email for spam detection regardlessly.
Today many applications have the ability to generate emails. Some examples include fax servers, reporting and monitoring tools. Being internally generated, filtering these emails is unnecessary. Indeed filtering only introduces the risk of false detection. Thus a solution is necessary.
[B]Solving the Conflict[/B]

Luckily solving this problem is not that difficult. The trivial solution is that of making sure that IPs under the Accept list are not inserted into the Local IP list. In this manner Connection Filtering is not skipped. This solution is fine in most cases.
A better solution is that to setup a new SMTP Virtual server. This would then handle emails from local hosts. IMF enablement is done per virtual server. Thus it is now just a matter to keep IMF disabled on the new server. Setting up Virtual Servers is easy. You will just need a unique IP/port pair. Applications may then be redirected to the new server avoiding IMF altogether
[/LEFT]