Category Archives: ORF

ORF-related posts.

SPF Policy Tester Updated

Thanks to the kind feedback that we have received from all of you, we were able to locate and fix several technical issues in our web-based SPF Policy Tester. The following is a short summary of changes, in no particular order:

  • DNS lookup limit counters for SPF terms (“include”, “a”, “mx”, “ptr”, “exists” and “redirect”) and for void lookups now propagate out from recursive evaluations and are tracked in global counters, limiting the maximum number of queries caused by terms to ten, and the number of void lookups to two – as specified in RFC 7208 (Section 4.6.4).
  • The status of the DNS lookup limit counters (for SPF terms and DNS void lookups) is now displayed at the end of each DNS lookup, as well as at the end of the SPF evaluation.
  • Similarly to ORF Fusion, the SPF Policy Tester is now capable of retrieving oversized TXT records using the TCP protocol.

ORF 5.4 + Exchange 2016 = it just works!

This is just in from our test labs: ORF 5.4 passed all Microsoft Exchange 2016 compatibility tests with flying colors and it is now officially compatible with the latest from Microsoft.

Transport Agent status on Exchange 2016

Architecture-wise, Exchange 2016 has reduced the number of roles further from Exchange 2013’s three roles (Edge Transport Server, Client Access Server, Mailbox Server) to just two roles, Edge Transport Server and Mailbox Server. Both roles are supported by ORF 5.4. In fact, from a technical perspective, the new Mailbox Server role is just a unified Client Access Server and Mailbox Server role, which makes Mailbox Server a prime installation site for ORF. However, when Edge Transport Server is available, we still recommend deploying ORF on that.

As ORF 5.4 pre-dates Exchange 2016 RTM, it still detects the new platform as Exchange 2013, but don’t be confused by that — every process and documentation we have for Exchange 2013 still applies to Exchange 2016. If you look behind the scenes, you will find that Exchange 2016 is arguably more like Exchange 2013 SP2, which is underlined by the fact that the Exchange internal version progressed from 15.0 to 15.1 with a minor version change only.

In the coming days we will update our documentation and materials to reflect the above. Meanwhile, feel free to head out and experiment with Exchange 2016 — we have your back! Just remember the following:

  • Exchange 2016 is fully supported by ORF 5.4 (not by previous versions, though).
  • Exchange 2016 Mailbox = Exchange 2013 Client Access Server + Mailbox Server
  • ORF detects Exchange 2016 as Exchange 2013, but there’s no need to worry about that.

If you have any questions, leave a comment or contact our Customer Service.

ORF 5.4 is now available

We are excited to announce the latest 5.4 version of ORF. Some of the highlighted changes in this release:

  • Built-in recursive DNS resolver
    The new DNS resolver can obtain DNS data without the help of a dedicated DNS resolver server. This greatly simplifies the DNS setup in ORF and eliminates common DNS configuration problems that lead to a diminished spam filtering performance.
  • Updated DNSBL definition set and recommendations
    The new set is compiled based on comprehensive true positive, false positive and overlap analysis to maximize the spam catch rate without risking the loss of legitimate emails.

Download ORF 5.4 from the Client Portal after logging in and learn more about the new release in the Change Log.


ORF 5.4 Sneak Peek, Part 2

Our second article looks into the new built-in DNS resolver feature of ORF 5.4.

Let’s begin with an excerpt from the ORF Deployment Guide about the requirements for DNS servers used with ORF:

  •  The server must support recursion
  • 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)
  • The server should not be the same DNS server that supports your Active Directory

As odd the last three requirements might sound, we have good reasons for them.

  • ISP DNS servers and third-party DNS resolution services and accumulate traffic from lots of clients, so they can get occassionally banned by DNSBLs and SURBLs for violating their fair use policy. This results in diminished spam filtering performance, or worse, false positives. Note that using these services as forwarders poses the very same problem, but now with one more server involved.
  • When your AD domain is the same as the public name (e.g. both are instead of example.local and, your AD-supporting DNS server will act authoritative for, resulting in all sorts of funny split-horizon DNS problems, like when your domain actually has an MX record, but your AD DNS doesn’t think so.

Issues arising from not meeting the above requirements are more common than you’d think. And it’s for a simple reason: the DNS server on your network is likely configured almost the opposite way than ORF needs it to be. It makes sense, because you may only have the AD DNS server. It may use the ISP DNS server as forwarder, so you can enjoy resilient, low-latency DNS access with a decent sized DNS cache to speed up lookups. It may use a third-party service and you get all that + security by blocking access to botnets, malware sites, phishing sites + more resilience + enormous cache + super-low latency anycast DNS access, so thank you, ORF does not get a dedicated server for its weird and unusual requirements.

Choosing resolvers in ORF 5.4

Choosing resolvers in ORF 5.4

This is where 5.4’s new built-in DNS resolver enters to save the day. To understand how it helps, we need to take a brief glimpse at how DNS data is resolved.

DNS name resolution is an iterative process. When looking up the DNS “A” record of, a DNS resolver first contacts one of the well-known root DNS servers which provide a starting point for all DNS lookups. The root DNS server will not have the DNS data for, but it knows which DNS servers service the .com zone and responds with a referral to these servers. The DNS resolver then contacts one of these referred servers, which in turn provides a referral to DNS servers. This cycle of referrals continues until the DNS resolver reaches a name server in the hierarchy which has the answer. This latest server in the chain is called an authoritative name server.

Now if you take a look at that process, it looks quite complicated. Also, you might have noticed that your DNS server at is curiously missing from the picture. You may even have started developing a vague respect for programmers, going through all that pain for turning into Nah, worry not, we’re a lazy bunch and that’s not how we do it. Almost always, we use something called a “stub resolver”, which asks your DNS server at to do all the above and pretty please send the result back to us. This is called recursion, which is effectively delegating the task of obtaining DNS data to an external DNS server.

So as demonstrated above, the custom is that programs rely on a recursive DNS server for name resolution, but there’s nothing really that stops them from cutting the middleman. The new resolver in ORF does exactly this and by doing its own stunts, the whole issue around the DNS server configuration is eliminated and the day is saved.

From ORF 5.4, the new resolver will be the default way to perform lookups in ORF, but you will be free to continue using external DNS servers (in fact, when you are upgrading, you will need to manually switch resolvers, because by policy ORF does not change your earlier settings on upgrade). If you choose the built-in resolver, you are in good hands: we know that properly implementing a recursive resolver is no small feat, so ORF 5.4 relies on libunbound, a part of NLnet Lab’s excellent Unbound resolver for this purpose. The library is very reliable and offers extensive caching.

We recommend using the built-in resolver in all cases when you don’t have a good reason to use external servers. Some of those reasons might be:

  • You have multiple servers handling a high volume of emails and you want to take advantage of the shared DNS data caching provided by a central DNS server,
  • You can allow DNS traffic only to specific DNS servers (why would you do that?).

If you need those external servers, just please be absolutely, positively, double definitely, cross-my-heart sure that all servers meet the requirements. Otherwise, stick to the new resolver.

Ready to give it a try? The first public preview of ORF 5.4 is coming next week, so stay tuned.