We are pleased to announce that ORF 5.5 is now available for download. The new release focuses on performance, usability and on request we’ve been receiving from all of you. We hope you will be pleased with the new features and improvements. Get your registered copy from the Client Portal or the evaluation version from our Trial Download page.
To share your feedback, please use our Community Forums.
For setup instruction, please consult our Upgrade Guide.
We are happy to announce that the first public preview of ORF 5.5 has finally arrived. The new release brings long-requested features and many enhancements – try it today.
For the first time in three and a half years, ORF Fusion licenses received a minor adjustment today (April 8, 2016) to reflect changes since Fusion pricing was introduced in 2012. The pricing change only affects ORF Fusion licenses, ORF Fusion for SBS prices will remain the same as before.
If you have questions about this change or our pricing and licensing in general, please contact our sales team, we are happy to answer your questions.
There is a good reason why the Recipient Validation feature of ORF is disabled on Edge Transport Servers: Exchange does a better job there. Unlike ORF, it does not require direct access to your Active Directory, so if your Edge server gets compromised, your AD data is still safe.
However, once you install CU1 on your Exchange 2016 Edge Transport Server, things will turn sour quickly. A client of us, Microsoft MVP Norbert Fehlauer from Systema Gesellschaft für angewandte Datentechnik mbH have discovered a major issue with Exchange recipient validation that results in bouncing all inbound emails. The issue is now documented in the Exchange 2016 Release Notes.
No hotfix is available for the issue at the moment. We recommend temporarily disabling Recipient Validation (see Release Notes above on how) and keeping an eye on this — as a major argument for having an Edge Transport Server is doing recipient validation on the network perimeter, we can probably expect a quick update to be released in the coming days.
Update March 29, 2016: No word on the hotfix from Microsoft (rumor has it they plan to address the issue in a subsequent Cumulative Update only), but Exchange MVP Maksim Barakin investigated the issue and came up with another workaround that temporarily fixes the issue by disabling the recipient validation cache of Exchange using the following Exchange shell command:
Get-TransportService | Set-TransportService -RecipientValidationCacheEnabled $false
Caching is normally enabled on Edge servers and disabling it may have performance implications, so we recommend keeping an eye your server for a while after the change.
Update June 24, 2016: Although the issue is not discussed in the release notes of Exchange 2016 CU2, the newest CU seems finally to fix this problem.
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.