The latest and greatest version of ORF is now available: the installer can be downloaded from the Client Portal section of our website after logging in.

ORF 5.3 adds support for the greatly anticipated Edge Transport server role introduced in Microsoft® Exchange SP1, and it also detects a Transport Agent-related defect of SP1, which prevents third-party products (like ORF) from working properly. If this defect is detected ORF will provide instructions for downloading and installing the hotfix before finalizing the installation.

For detailed information, please read our Change Log and the related Knowledge Base article.

After 11 years of operation, the FiveTen Blackhole List has retired. Please remove this DNS Blacklist from your configuration to avoid timeouts and any possible future issues (like the one many experienced with Blackholes.us):

1. Start the ORF Administration Tool
2. Navigate to the Configuration / Tests / DNS Blacklists page
3. Select FiveTen and click the Delete button.
4. Save and update your settings by pressing Ctrl + S

If you already have the marvelous ORF 5 Beta version installed:

1. Start the ORF Administration Tool
2. Navigate to the Blacklists / DNS Blacklists page
3. Select FiveTen and click the Delete button.
4. Save and update your settings by pressing Ctrl + S

We have received several reports about an increased false positive rate in ORF installations. After a brief investigation, it seems the legitimate emails were all blocked by the uribl.com URL Blacklist with the following log message:

Blacklisted by the UB-BLACK SURBL (domain:”example.com”, DNS lookup result: 127.0.0.1)

By default, the uribl.com definition in ORF is configured to consider any response form the queried server as a hit, but actually, the 127.0.0.1 response indicates that uribl.com does not accept any queries from the DNS server.

After investigating this further, it seems the affected ORF users all use Google public DNS servers for the queries (or use such servers as forwarders in their local DNS configuration). Uribl.com is known to simply ignore queries initiated by DNS servers exceeding their query limit, but all of a sudden they have started to return 127.0.0.1 instead.

In other words, these queried domains found in incoming emails are not listed in uribl.com, but if you use Googe public DNS servers, ORF thinks they are.

Quick fix

1. Start the Administration Tool
2. Navigate to the Configuration / Filtering – On Arrival / URL Blacklists page using the navigation tree on the left
3. Double-click uribl.com Blacklist
4. Click the Lookup results tab, uncheck the Blacklist if DNS record exists (regardless record data) option
5. Click New
6. Add 127.0.0.2, click OK, then OK again
7. Save your configuration to apply the changes by pressing Ctrl + S

This will ensure uribl.com will block the email only if it returns a response explicitly indicating a hit (127.0.0.2). We will also change this in the default definition file shipped with future ORF versions.

To avoid such problems in the future, make sure you local DNS server queries the root servers directly. The DNS servers configured in ORF should/must meet the following requirements:

They must support recursion
Recursion means the DNS server returns the query result in a single step instead of redirecting ORF to the root DNS servers. This feature in enabled by default in Microsoft® DNS servers.

They 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: you have no control of the configuration of such third-party party DNS servers, and these are usually banned by free DNS and URL Blacklist lookup services (i.e., they will not respond to the queries or return false data).

They should not use forwarders
Forwarders usually work with a large cache, which is usually no problem in simple name resolution, but will cause inaccurate (outdated) query results to be returned when checking online DNS and URL blacklists, causing degraded filtering performance. Also, using public DNS servers as forwarders may cause unexpected issues (see above).

They should not be the DNS server authoritative for your own domain (and supports your Active Directory)
Occasionally, ORF may need to query the records of your own domain (e.g., for the SPF test). The authoritative DNS server may not see your public MX or A/CNAME record if your internal AD domain name is the same as your public domain name (e.g., domain.com, instead of domain.local or domain.internal), resulting in false positives.

We have started to receive reports about weird error messages in the ORF logs, like the one below:

Unexpected SPF Test error. EAssertionFailed “Invalid network IP for the CIDR test.
(C:\projects\ORF\Source\ORFEnterprise\CoreService\tests\
spf\SPFCommon_un.pas, line 145)”.

Though the message seems quite disturbing, the explanation will surely calm your nerves: it simply indicates the SPF record included an invalid ip4 mechanism with a CIDR network range notation, therefore the range could not be interpreted by the SPF evaluation of ORF and the SPF test was skipped.

We will fix this in future versions, so ORF will return a more informative message in such cases.

Actually, we have not had reports about this issue in the past (despite the fact that the core SPF evaluation changed little over the past six years since its implementation), but now Microsoft changed one of their SPF policies and accidentally added an invalid dot-decimal notation (111.221.26.08/29 in the SPF policy of _spf-ssg-c.microsoft.com, which is included in policies of various Microsoft domains). The trailing .08 part is invalid, it should be simply zero or eight: unfortunately, this causes all emails from Microsoft domains (or emails spoofing any of these domains) to trigger the above mentioned error.

They will hopefully fix this soon and the policy will “wear off” in DNS caches as well, so the errors will also go away. In the meantime, you should simply ignore them, though some spoofed emails from Microsoft may leak through due to their faulty SPF record.

Update (October 5, 2011): Microsoft have fixed the SPF policy.

We have been contacted by a few people last week about a small peak in the number of legitimate emails blacklisted by SORBS, which I believe was caused by escalated listings (see the blog post of SORBS for details). Though we discourage using the escalated zone of SORBS because of the higher chance for false positives (we removed response 127.0.0.6 from the DNSBL definition shipped with ORF a long time ago), some folks still have it enabled.

In short, ISPs do not care much if a paying customers is spamming until the whole IP block gets blacklisted by a DNSBL and other (innocent) customers start to complain. I do not think it’s the ideal way of doing things (i.e. to force the ISPs to get rid of spammers by blacklisting innocent people), on the other hand, I totally understand SORBS and other DNSBLs: they simply have no other choice if the ISP ignores their reports of abuse.

What do you think?