Test Exception Design

Ever since the Active Directory-based recipient validation was implemented in ORF, we receive requests to make it exempt from whitelisting, i.e. to reject the invalid recipient even when e.g. the sender is whitelisted.

The request is perfectly reasonable, yet it does not play very well with ORF.

Here is the problem: ORF is primarily a spam filter, but some of its features have email security role more than anti-spam. These tests are the AD Test, Recipient Blacklist (for recipient validation), Attachment Filtering and External Agents (agents filtering for viruses). Regardless role, these are blacklisting tests, so whitelists take precedence over them. This results in hardly reasonable scenarios like letting a virus-infected email enter to your system, just because the sender is (auto) whitelisted.

Obviously, we have to deal with this problem somehow. We went through to quite a few possible solutions, but unfortunately none of these were without tradeoffs.

First, we cannot just re-prioritize these tests to run without whitelist control. Remember that ORF monitors all incoming SMTP connections, including SMTP connections that are used to relay outbound emails. If no whitelisting mechanism is employed, ORF filters outbound email as well. That may sound acceptable, or maybe even great for Attachment Filtering and External Agents, but I am quite confident that you do not want the recipients of your outbound emails validated as local addresses. A few would pass.

Ok, so we still need to exclude outbound emails from these tests. Good news: ORF already does this. Bad news: it does it a weird (but otherwise practical) way.

The best way to tell whether the email is inbound or outbound is to check the recipient domain and if it is a domain that your server is responsible for, the email is inbound, otherwise outbound. Cool, but you might have noticed that ORF does not keep track of the local domains.

Instead, ORF uses two whitelists which almost accidentally eliminate the need for outgoing email detection. The first is the AUTH Whitelist that whitelists emails arriving via authenticated SMTP connections, thus it covers authenticated outbound relaying. The second whitelist is the IP Whitelist, which

  • Whitelists email from the local host
  • Whitelists emails coming from Intermediate Hosts, which always includes the private intranet address ranges.

These two IP Whitelist rules cover the typical outbound relaying cases, and when not, it is enough to add relaying server’s IP address to the Intermediate Host List.

Excellent, but there is a glitch: the Intermediate Host List is not for detecting outbound emails. Typically, you add your secondary MXs and front-end servers to the IHL, allowing ORF to “look behind” these in the delivery path and check the actual source IP (DNS Blacklists, SPF Test, etc). In other words, the IHL-based IP Whitelist rule tells you whether the email is coming from a trusted source and this covers your trusted outbound relay hosts, too.

So a design decision had to be made: either (A) we require the user to list the local domains for proper
inbound/outbound email detection or (B) run the AUTH Whitelist + IP Whitelist always, even when email security tests are exempt from whitelist scope.

After long consideration, we decided to use option (B). Here are the advanteges and disadvantages:


  • No administrative overhead
  • Exceptions for email security tests can be enabled by default. This is important because many ORF users actually think that ORF already works this way, so they will not seek a configuration option to enable exceptions.


  • If you have a front-end server, you will not have recipient validation at the Before Arrival filtering point. It is not that you had that before, but technically you could have it now.
  • Your front-ends, secondary MXs and hosts listed on the IP Whitelist or anyone who successfully authenticates with your SMTP server will be able to bypass these email security tests.

We believe this is still better than requiring to list all domains and maintaining that list (sure we can detect the domain list, but eventually you would have to at least confirm that list and maintain it later).

6 thoughts on “Test Exception Design

  1. allianz


    Since ORFEE is a plug-in into the Microsoft SMTP service, one could assume that the configuration information for this service is correct and so the information you need (what is inside, what is outside) can be obtained from this service.

    Configuration information includes relay restrictions and domains. Windows initially deploys with smart choices already configured.

    Relay restrictions allow you to designate IP address ranges that are allowed to relay through the service. We set these up for internal ranges. The initial configuration looks at all adapters and allocates all non-routable ranges.

    Domains have two types, Local and Remote. Both list FQDN’s and the intent is that anything targeting any of these domains also gets delivered. If local this is to the local drop-box otherwise it gets relayed to a designated smart-host. Obviously Domains are to allow external clients to relay to your domains.

    Gaining access to this so called meta-base information is via a COM interface. In II6 they also made the metabase an XML file, but you would best be advised to use the COM interface.

    About 5 years ago I did a lot of work using this interface from a VB6 program, I think I still have a copy somewhere. I don’t have a VB6 compiler anymore but I could dummy up an example in C#. Accessing COM in Delphi might also be easy, except this interface is via service look-up (accessing another interface and requesting the one you want).

  2. Peter Post author

    Thanks Peter, I was actually aware of this, but the problem here is that you do not necessarily have all (or any) domains listed in IIS config. In some cases, you configure IIS to forward all emails to another host
    (global smarthost) or list only a few domains as exceptions and rely on the global smarthost for the rest of the emails. In this case, domains have to be listed manually, so eventually you have one more dependency and one more list to maintain (as listing domains does not eliminate the IHL).

  3. Frank Bernard

    ORF already lists (on the Server Bindings screen) all the IIS smtpsvc’s I have configured and I can checkmark/bind separate ones for Inbound and Outbound. So just have everyone do this, no?

  4. Peter Post author

    Sure, but this would not help ORF if the SMTP Virtual Server has both inbound and outbound role. Separating inbound and outbound into different SMTP Virtual Servers would work, except if ORF is installed on the Exchange server (not so rare) and it would add similar administrative overhead.

  5. Pingback: Vamsoft Insider » ORF 4.0 Changes

  6. Pingback: outbound connections

Leave a Reply

Your email address will not be published. Required fields are marked *

AlphaOmega Captcha Classica  –  Enter Security Code