WinDeveloper O365 Mailer FREE for 1 Year

WinDeveloper IMF Tune
WinDeveloper IMF Tune
  • Home
  • Anti-Spam
  • Connection Filtering IP Accept List in Exchange SP2

Connection Filtering IP Accept List in Exchange SP2

Alexander Zammit

Alexander Zammit Photo

Software Development Consultant. Involved in the development of various Enterprise software solutions. Today focused on Blockchain and DLT technologies.

  • Published: Jan 24, 2006
  • Category: Anti-Spam
  • Votes: 4.9 out of 5 - 9 Votes
Cast your Vote
Poor Excellent

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.

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.

Accept Lists Won't Work When...

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 Accept List Configuration 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.

Identifying Local IPs

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

  1. From the Exchange System Manager open the properties for Global Settings | Message Delivery.

  2. Select the General property page

    Message Delivery General Property Page

  3. Click the Add button to bring up the IP list.

    Organization IPs

  4. In the dialog that opens click Add again to specify single IPs and IP ranges for the organization.

Conflicts with Connection Filtering

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.

Solving the Conflict

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.

User Comments - Page 1 of 1

Alexander Zammit 27 Sep 2010 01:06
The simple answer to 1) is that you shouldn’t do that.

There is no need to enter all local IPs to the Perimeter IP List, even though the MS documentation tells you to do so.

This list only truly needs the list of IPs involved in routing emails inbound.

Point 2) is fine. The Accept List is a whitelist so of course you only want to whitelist Organizations you trust. As for duplication, you normally won’t have any duplication if you do as I said in the 1st point.
Stephen White 26 Sep 2010 18:29
Can we please just clarify that, in short, what you are saying it this:
(1) All local network IPs and ranges, including any public IP addresses assigned to the external interface of a firewall, should be entered into the "Perimeter IP List and Internal IP Range Configuration" section.
(2) You should only use the 'Accept' list in the Connection filtering section for allowing external organisations you trust, and you must not duplicate any of the IPs previously entered in (1).
Elizabeth 12 May 2010 11:21
Please clarify 1) adding a second IP to Exchange server without adding a second NIC - can it be from the same subnet?

2) Once the second Virtual SMTP server is set up, how to set it to route internal email only and how to set up the original default SMTP server with IMF to not route email originating from local network.

I think I know the answers to the above questions, but when I tried to implement it it did not work so I thought I would get clarification. Thanks.
Alexander Zammit 5 Oct 2009 12:18
1. You need a unique IP/Port pair i.e. the combination has to be unique. So if the IP is unique than the port can be 25 like for other SMTP Virtual server.

2. Of course you have to assign an IP which one of the NICs is listening.
Steve 5 Oct 2009 11:03
When creating an additional vitual smtp, you mention using a unique IP/Port and everything will work.

So, from my subnet, I can just take any IP# and throw it in there, or do I have to have an associate NIC to go along with it? If I use an alternate IP# for the secondary SMTP, why would I need to use a different port than 25?

Alexander Zammit 2 Jul 2009 02:52
The solutions I know of, are listed in the article.

That list should only include the hosts that are involved in the routing of internet email to the first Exchange Server in your organization.

Normally you will only have very few machines involved in this routing and only those should be listed.
SimonG 2 Jul 2009 02:12
Thanks for this article - it's certainly allowed me to understand why our internal devices are being processed by the IMF and hence categorised as potential spam.
In the article you mention that the 'trivial solution' to solving this issue is by ensuring the device IP's are not inserted in the local IP list - our list contains a subnet which contains the IP's of these devices - how do we handle this?
Copyright © 2005 - 2024 All rights reserved. is not affiliated with Microsoft Corporation