Deployment Guide

Introduction

This guide helps deploying ORF seamlessly to your network. The intended audience of this document are system administrators.

---

Table of Contents

---

A Brief Introduction to ORF

This guide assumes that this is your first ORF deployment and you are not yet familiar with some basic concepts of our product. Skip to the next section if you already experienced with ORF.

The rest of this section briefly explains a few basic ORF technical concepts. These will gain significance later in the guide.

Email filtering basics

ORF filters your email traffic in real time, while emails are being transmitted using the SMTP protocol. This low-level monitoring of email flow enables ORF to stop spam right on its tracks, offering a number of benefits such as SMTP-level email rejection.

Exchange integration

By hooking into Microsoft® Exchange or IIS SMTP using the integration interfaces provided by Microsoft, ORF monitors your email traffic without introducing another hop in the email delivery chain.

The Filtering Points of ORF

The integration with Exchange/IIS is event-based: ORF gets notified of certain events that occur during the SMTP email transmission and also gets a chance to intervene in the delivery. ORF calls these events Filtering Points and there are two of them.

The Before Arrival Filtering Point occurs when the sending server just specified the recipient email address (RCPT TO command) and waits for your server to acknowledge. At this point, the email contents are not transmitted yet, but ORF is already very capable of making decisions about the email: for instance, if the sending server is known to distribute spam, ORF can turn down the offer.

A little later in the delivery process comes the On Arrival Filtering Point, when the sender server transmits the email and waits for acknowledgment. As the email contents are now available, ORF can perform a more in-depth analysis of the email and also carry out more actions than at Before Arrival, such as redirecting the email or moving it the Junk Email folder of the end-users.

From the above description it might appear to you that On Arrival is sort of "better", but in fact both filtering points have their merits.

---

Choosing Deployment Location

Deployment on the network perimeter

ORF is best deployed on the network perimeter, on your primary mail exchanger servers (primary MX) and optionally on all of the secondary MXs.

• Deployment with Microsoft® Exchange 2019 or 2016

  Install ORF on the server with Edge Transport role, or if you have no such server in your organization, install it on the Mailbox Server role.

• Deployment with Microsoft® Exchange 2013

  Install ORF on the server with Edge Transport role, introduced in Exchange 2013 SP1. Note that SP1 was shipped with a defect which should be addressed first by installing a hotfix. If you do not use edge servers, install on the server having both the Client Access and Mailbox server roles. If these roles are installed on separate servers, install ORF on both servers in order to use all ORF features.

  Installing ORF on a Client Access server or a Mailbox server alone will work as well, but some features will not be available.

  See the related Knowledge Base article and our Multi-Server Usage Guide for more information.

• Deployment with Microsoft® Exchange 2010 or 2007

  Install ORF on the server with Edge Transport role. If you do not use edge servers, install on the Hub Transport role server.

  Installing ORF on a Hub Transport role server in an Edge Transport-Hub Transport setup will work as well.

Deployment behind the network perimeter

ORF will also work behind the network perimeter, e.g. behind SMTP front-ends, non-transparent firewalls, anti-virus proxies or cloud email filtering services. However, ORF may take more time to set up and maintain in such setup. Find a summary of limitations below.

• Increased Intermediate Host List (IHL) maintenance cost

  This list of ORF contains the IP addresses of the servers between your network perimeter and your ORF server. IHL is crucial for ORF to work reliably.

  Compiling and maintaining this list could be challenging if your network is complex or if your network perimeter is provided by a third-party (e.g. your ISP or a cloud email filtering service).

• Increased chance of DKIM/DMARC false-positives

  Mail transfer agents, including Microsoft® Exchange, often times make changes to the message header and body when forwarding the email to the next hop, which can break the digital signatures used by the DKIM and DMARC tests to verify the origin and integrity of messages. If you install ORF behind the network perimeter, you may not be able to use these tests to reliably filter out phishing and fraudulent emails.

• Before Arrival filtering will not work

  The On Arrival filtering point will work without any limitations, though. Lack of Before Arrival filtering will result in the following limitations:

  • The Greylisting feature will not be available: Greylisting is a rarely used, rather aggressive spam filtering technique, so it is no big loss unless you specifically want to use this feature.
  • Backscattering: Spam is usually sent in the name of innocent third-parties. In this setup, rejecting spam at On Arrival will cause your perimeter servers to generate bounce reports (also known as NDRs or DSNs) and bomb the innocent party with them. This phenomenon is called backscattering. To avoid this, we recommended using email tagging instead of rejection in this setup.
  • No bounce on invalid recipients: When using the Recipient Validation Test of ORF to bounce emails sent to non-existent local recipients, ORF will be unable to trigger a bounce report in certain cases—that is, the sender might not get notified about the failed delivery. This is due to a technical limitation of the SMTP protocol.

Before choosing to deploy ORF behind the perimeter, make sure the above limitations are acceptable for you.

Deployment with secondary MXs

Secondary mail exchangers (MXs) are ironically the primary targets of spammers—often they will skip the primary MX and turn to the secondary MXs directly. Make sure that emails from your secondary MXs are relayed through your ORF server so that it can filter them.

Ideally, ORF should be deployed on all of the secondary MXs as well as the primary MX. If this is not possible, you will be facing the same challenges as outlined in the previous section, but the limitations will apply only to the emails arriving via the secondary MXs.

Outbound email traffic

The Auto Sender Whitelist of ORF is a self-learning feature that automatically builds a list of your trusted email partners by monitoring your outbound email traffic. This feature greatly reduces the administration costs and significantly decreases the chance for mistaking legitimate emails as spam.

If possible, route your outbound emails via your ORF server. This will allow ORF to populate data for the Auto Sender Whitelist.

Deployment on multiple servers

ORF features Configuration Synchronization, a service which allows distributing configuration changes in a "publisher-subscriber" model. The administration typically appoints a central repository server (publisher) and carries out any change on that server which then get automatically distributed to subscriber servers.

This feature should be used alongside with the External Databases feature for data sharing between ORF instances.

Please consult the Multi-Server Usage Guide on setting up and using ORF on multiple servers.

System requirements

The minimum system requirements for ORF servers are the following:

	Requirements
Operating System	Microsoft® Windows® Server 2019 Microsoft® Windows® Server 2016 Microsoft® Windows® Server 2012 R2 Microsoft® Windows® Server 2012 Microsoft® Windows® Server 2008 R2 (Service Pack 1 required) Microsoft® Windows® Server 2008 (Service Pack 2 required) Windows® Server Essentials 2016 Windows® Server Essentials 2012 R2 Windows® Server Essentials 2012 Windows® Small Business Server 2011 Standard (Service Pack 1 required) Windows® Small Business Server 2008 (Service Pack 2 required)
Email Server	Microsoft® Exchange 2019 Microsoft® Exchange 2016 Microsoft® Exchange 2013 (see [2] for Service Pack 1 compatibility) Microsoft® Exchange 2010 Microsoft® Exchange 2007 (64-bit release version only [1]) Microsoft® IIS SMTP Service 10.0 Microsoft® IIS SMTP Service 8.5 Microsoft® IIS SMTP Service 8.0 Microsoft® IIS SMTP Service 7.5 Microsoft® IIS SMTP Service 7.0
Platform	Both 32-bit and 64-bit [1] OS platforms are supported
Internet Explorer®	Microsoft® Internet Explorer® 6 or later
CPU	As required by the operating system
Storage	Varies, at least 100Mb
RAM	Varies, at least 50Mb

The recommended system configuration is that of Microsoft® Exchange. In overall, introducing ORF to a system that is already capable of running Exchange or IIS SMTP smoothly does not add significant further load to the system. However, estimating the load generated by ORF is very difficult, because it depends much on the features and configuration used.

ORF requires considerable disk space for logs, about 500 bytes per log entry on average. This results in the following average disk space requirements:

Email Traffic	Logs for 1 day	Logs for 30 days
1,000 / day	488 kB	14 Mb
10,000 / day	4.5 Mb	143 Mb
50,000 / day	24 Mb	715 Mb
100,000 / day	48 Mb	1.4 Gb
500,000 / day	238 Mb	7 Gb

Log retention can be configured in ORF (defaults to 30 days).

Performance and sizing

ORF is not particularly resource-intensive software: even under heavy stress testing, an average setup will use negligible or low amount of memory and CPU due its design and optimizations.

The heavy reliance of DNS-based information of ORF limits its throughput, however. The major factors influencing throughput are your settings and DNS response time. Unfortunately, both factors vary greatly, which makes it hard to come up with estimations that fit all sizes and setups.

By our experience, the average ORF configuration that sticks to our Best Practices recommendations can process 250,000 emails per day per server without any issues and ORF installations with up to 750,000-1,000,000 emails per day per server have been reported.

As a general rule of thumb, if your network processes less than 100,000 emails per day per server, performance is not likely to require extra attention. For 100,000 or more emails, we recommend the following:

• When using external DNS servers, use only one, local server
• Keep the DNS timeout low (no more than 5 seconds)
• Gradually enable DNS-based ORF tests and watch for the number of concurrent SMTP connections in Exchange (it should stay below 10)
• Review DNSBL/SURBL usage restrictions: DNS zone transfers or using premium services may be required if your traffic exceeds a certain level

---

Preparation for Deployment

Compiling the Intermediate Host List

The Intermediate Host List contains the IP addresses of the servers between your network perimeter and your ORF server. ORF uses this list to "look behind" any intermediate delivery hops in the email delivery history to find the original IP that connected to your network. This list is crucial for ORF to work reliably.

This list will be empty if you deploy ORF on the perimeter and you have no secondary MXs. However, if you have secondary MXs, or ORF is deployed behind other servers, you need to compile this list.

View examples

Checking DNS compliance

ORF relies on DNS in many ways. It features a built-in, recursive DNS resolver and also supports using external DNS servers as resolvers. While the built-in resolver is recommended in almost all cases, using external DNS server may be needed if:

• ORF is ran on multiple servers and a shared DNS cache (as provided by a shared DNS server) is preferred
• network policy restricts DNS traffic to the appointed DNS server only

In case external DNS servers are used, follow the requirements and recommendations for all DNS servers:

• The server must support recursion (enabled by default in Microsoft® DNS)
• The server should be on the local network or on the ORF computer. Using ISP DNS servers and third-party DNS resolution services (such as OpenDNS or Google Public DNS) is discouraged.
• The server should not use forwarders (e.g. ISP DNS servers), but rely on root hints instead.
• The server should not be the same DNS server that supports your Active Directory

The easiest way to comply with the above is to install Microsoft® DNS Server on the computer where ORF is deployed. This software is part of Windows® Server and can be added as a server role. Consult this KB article on setting up Microsoft® DNS Server with ORF.

Network security setup

ORF requires the ports below to be opened for communication.

Port	Description
UDP/53 and TCP/53	DNS traffic. When using the default built-in resolver, these ports have to be opened to any internet hosts. When using external DNS servers, DNS ports can be restricted to the specific servers.
TCP/6242	Default port for remote ORF management and configuration synchronization between your ORF servers. Optional (if Remote Access is disabled in ORF).
TCP/80 and TCP/443	HTTP communication between ORF management tools and our servers (HTTP proxies are supported).
TCP/389 or TCP/3268	Default ports for Active Directory LDAP or GC communication if the Recipient Validation Test is enabled in ORF with the Active Directory source. Optional (if the above test is disabled).
(Varies)	Communication with External Databases (e.g. Microsoft® SQL Server) if ORF is configured to use these. Please consult the database manual for port information.

The Remote Access feature of ORF can be secured further by employing VPN or similar solutions.

Setting up External Databases

Certain features, such as the Auto Sender Whitelist and the Directory Harvest Attack Protection Test store their data in databases. These databases can be either Private Local Databases (an embedded, no-setup solution in ORF) or External Databases (e.g. Microsoft® SQL Server). Setting up External Databases is required if:

• ...your email traffic reaches or exceeds 50,000 email per day
• ...if you are setting up multiple ORF servers (allows sharing data between servers)

A broad range of database solutions are supported by ORF, please check the Database Guides page for the complete list and database setup instructions.

Preparing for service outages

When planning deployment, consider that under Microsoft® Exchange 2019, 2016, 2013, 2010 and 2007, the ORF setup restarts the transport service(s) of Exchange to finalize the installation. Depending on your Exchange version and setup, this could be the MSExchangeTransport service (Exchange 2019 Edge Transport, Exchange 2016 Edge Transport, Exchange 2013 Edge or Mailbox, Exchange 2010 and 2007 all roles), the MSExchangeFrontEndTransport (Exchange 2013 Client Access server role) or both (Exchange 2019 Mailbox role or Exchange 2016 Mailbox role or Exchange 2013 Client Access server and Mailbox roles on the same server). SMTP email transmission will be down while these services are restarting. This usually takes less than a minute (differences may occur). It is recommended to schedule the installation to a time when the service outage causes the least problems.

There is no service outage under IIS SMTP.

---

Next Step: Installing ORF

Please follow the instructions in the Installation Guide to install ORF on your network.