Author Archives: Péter Karsai

About Péter Karsai

Head of product development with a special interest in IT security. Father of one two. Can ship any ORF release long after promised. Loves running even without zombies chasing him. Works with Vamsoft since 2000. Find me on LinkedIn.

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 example.com instead of example.local and example.com), your AD-supporting DNS server will act authoritative for example.com, 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 example.com, 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 example.com, 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 example.com 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 192.168.251.6 is curiously missing from the picture. You may even have started developing a vague respect for programmers, going through all that pain for turning example.com into 93.184.216.34. 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 192.168.251.6 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.

 

ORF 5.4 Sneak Peek, Part 1

The first public preview of ORF 5.4 is just around the corner and we are kicking off this blog article series to introduce you to some of the changes shipping in the new version. This first post is about the SPF update.

ORF was among the first products to add support for authenticating emails using the Sender Policy Framework (SPF) in September 2005. You can tell we got a bit early in the game, because RFC4408 — the standard that governs SPF — was published only 8 months later in April 2006. Changes between the implemented draft version and final RFC did not call for a change, though. The first update that really changed a few things is RFC7208, published last year.

We are now shipping ORF 5.4 with a fully RFC7208-compliant SPF client that can do validation as per the latest standard version. Our updated library debuted in our SPF validation services in May and has been tested by thousands of users worldwide since.

The changes introduced by RFC7208 are non-breaking, so policies published using the earlier version will be readily consumed and validated by ORF. Perhaps the most significant change is with error handling, which is more clearly defined and also more lenient than in the earlier standard version. SPF evaluation for a considerable portion of policies used to end up in errors in ORF, because they referenced non-existent DNS records, which ORF used to treat as a policy error — we argued that policy publishers would not reference non-existent DNS data intentionally, so such missing reference questions the integrity of the SPF policy. Given how common this issue is, it’s no wonder that RFC7208 now defines a clear procedure for such errors, allowing at most two such references before the evaluation ends up in an error. We have mixed feelings about this change, but we do expect it will allow the evaluation of more policies in ORF.

There have been more changes, but mostly technical — gory details are available in our earlier blog post about the SPF update.

We will be back with more on ORF 5.4 soon, stay tuned.

Exchange 2016 Preview is now available

Breaking news: the first preview version of Exchange 2016 just have been published. Head to the Exchange Team Blog to learn more or download all the 1.7GB of the latest and best from the Microsoft Download Center.

As always, we are committed to provide support in ORF for the latest Exchange version as soon as possible, so as of writing this, VMs are already firing up up and work has already started on compatibility testing. ORF 5.4 will likely arrive before Exchange 2016 goes to RTM, so we will likely dedicate a minor release solely to Exchange 2016.

Reminder: Windows Server 2003 is now officially gone

In case you missed the news, Microsoft has stopped supporting Windows Server 2003 on July 14, 2015, so if you still have an ancient server hiding somewhere on your network, be sure to migrate to a newer platform. ORF has your back with support for the most recent Windows Server and Exchange versions and we are preparing for the soon-to-be-released Windows Server 11 and Exchange 2016. Don’t worry if you are a bit behind with your ORF license, just contact our Customer Service for an upgrade offer.

Exchange 2013 CU9 Health Probe woes

You probably know the Managed Availability feature of Exchange 2013, which sends periodic health probe emails to check server health. You probably never wondered, though, why these emails are omitted from the ORF logs. And you are right of course, it just works, so why bother? That is, until it doesn’t and health probes start showing up in the logs to add a headache-inducing noise every couple of minutes.

Health probes showing up in the logs (pre-CU9, detection disabled)

Health probes showing up in the logs (pre-CU9, detection disabled)

To save you from the pain, ORF detects the list of reserved Heath Mailboxes during installation and automatically ignores any email sent to a health mailbox address. This prevents these emails from getting into the logs and your sanity is preserved.

Unfortunately, this only lasts until you upgrade to the 9th Cumulative Update of Exchange 2013 (CU9), which breaks this feature and then you get this:

Health probes in the logs after CU9, without recipient information

Health probes in the logs after CU9, without recipient information

This is due to a new Transport Agent introduced by CU9 called the System Probe Drop Smtp Agent — undocumented, but apparently responsible for dropping probe emails — which does not “drop the email” in a traditional sense, but removes all email recipients instead. Alas, this method of stopping an email from getting delivered has an adverse effect, namely the email still gets passed down the pipeline, but now with the recipient information destroyed. As ORF’s health probe detection is based on the recipient address, it also renders this feature useless.

When can I expect a fix for this?

We are still evaluating the best way to deal with this. We plan to address the issue in the next regular release. As this potentially affects other third-party Transport Agent vendors as well, we are also reaching out to Microsoft to discuss this matter.

Update July 31, 2015: The upcoming beta version of ORF 5.4 will arrive with a fix for this problem.

Is there a workaround?

You can set up a filtered view in the ORF Log Viewer for the Sender field (e.g. a regex for (HealthMailbox.*@yourdomain|inboundproxy@contoso\.com)$ with rule inversion).

Can’t I just change the agent priorities?

Unfortunately, no. The System Probe Drop Smtp Agent hooks the OnEndOfHeaders event, which always occurs before the OnEndOfData event hooked by ORF.

I don’t have CU9 and still get health probes in the log

You probably added a new Mailbox server after ORF was installed and you need to update the list of Health Mailboxes. Read more on this in our Knowledge Base article.