Exchange 2013 migration options are opening soon and ORF 5.1 with support for the next-generation Exchange platform will arrive just in time to fill in your need for spam protection.

In our three-part series, we talk about the changes the new Exchange version brings to ORF.

The next ORF version will support deployment on any of the Exchange 2013 roles, but not all deployment scenarios are made equal. In this article, we outline five different deployment scenarios and check their benefits and drawbacks.

Scenario #1: Exchange 2010 SP3 Edge Transport + Exchange 2013

Exchange 2010 SP3 Edge Transport in the DMZ + ORF => your Exchange 2013 Mailbox Server.

This a great setup for both Exchange and ORF, with a few minor trade-offs. If your existing Exchange 2010 setup features Edge Transport, this is the way to go.

• Pros: ORF performs best and requires the least maintenance when deployed on the network perimeter (that is, on Edge Transport).
• Pros: All previous functionality of ORF is available.
• Pros: You do not even need ORF 5.1 for this – ORF 5.0 and even 4.4 will install and work fine.
• Pros: Exchange 2010 Edge Transport is designed for DMZ use and a compromised Edge Transport server does not automatically allow an attacker access to your company network. Without Edge Transport, you would have to expose your Exchange 2013 Client Access Server (CAS) to the internet. CAS must be part of your network, so just by having Edge Transport you mitigated a security risk.
• Cons: 2010 Edge Transport must be linked with your 2013 Mailbox Server, which bypasses your Client Access Server.
• Cons: The Recipient Validation feature of ORF is not available under Edge Transport. This affects the DHA Protection feature as well, because it cannot receive data from the Recipient Validation feature.

Scenario #2: Exchange 2013 CAS + Mailbox Server (mixed)

Both roles of Exchange 2013 installed on the same server + ORF.

• Pros: No additional maintenance and configuration (if CAS is exposed directly to the Internet — otherwise, you should set up and maintain the Intermediate Host List).
• Pros: All previous functionality of ORF is available.
• Cons: Exchange 2013 CAS (a domain member server) must be exposed to the Internet, which may be a security concern ranging from “Oh, it’s OK” to “No. No. Over my dead body. No.”, depending on which school of IT security you subscribe to.

Scenario #3: Exchange 2013 Client Access Server

Separate Exchange 2013 Client Access Server + ORF => separate Mailbox Server.

• Pros: None that we know of, but it works.
• Cons: Only Before Arrival filtering is available and outbound email monitoring (for collecting data for Auto Sender Whitelist) is not supported.
• Cons: For the complete range of ORF features to be available, ORF must be deployed on the Mailbox Server as well. Configuration Synchronization must be set up between the Mailbox Server, the CAS or other CAS instances in the CAS array.
• Cons: CAS security concerns (see previous scenarios).
• Cons: The Replay Directory is not available. SMTP fallback must be configured (see previous article).

Scenario #4: Exchange 2013 Mailbox Server

Separate Exchange 2013 Client Access Server => separate Mailbox Server + ORF.

• Pros: None that we know of, but it works.
• Cons: Only On Arrival filtering and outbound email monitoring (for collecting data for the Auto Sender Whitelist) are available.
• Cons: CAS security concerns (see previous scenarios).
• Cons: Your CAS server IPs must be added to the Intermediate Host List of ORF and need to be maintained.
• Cons: If you need Before Arrival filtering, ORF must be deployed on the CAS server as well. Configuration Synchronization must be set up between the Mailbox Server and the CAS.

Scenario #5: IIS SMTP front-end with Exchange 2013

Any Windows Server edition with the IIS 5 or 6 SMTP Service feature installed, Exchange 2013 CAS configured as smart host + ORF => Exchange 2013 Client Access Server.

• Pros: You do not even need ORF 5.1 for this – any previous ORF version will do, as long as it supports the operating system.
• Pros: ORF performs best and requires the least maintenance when deployed on the network perimeter (that is, on the IIS front-end).
• Pros: All previous functionality of ORF is available.
• Pros: Can be safe for DMZ use.
• Cons: The IIS SMTP 5/6 Service is a legacy technology.
• Cons: CAS should be configured to relay outbound emails via the front-end server for the Auto Sender Whitelist to work.

To sum things up, ORF 5.1 will work the best on the network perimeter. Your network perimeter is ideally an Exchange 2010 SP3 Edge Transport server or an IIS SMTP front-end, but if you accept considerably more work, you can get ORF to work on any of the Exchange 2013 roles.

A friendly reminder for distributed setups: ORF Fusion licensing enables deployment on an unlimited number of servers without any extra fees and charges, as long as all servers belong to your organization or its subsidiaries. If you decide you need a CAS array and a range of mailbox servers, Fusion has your back.

Exchange 2013 migration options are opening soon and ORF 5.1 with support for the next-generation Exchange platform will arrive just in time to fill in your need for spam protection.

In our three-part series, we talk about the changes the new Exchange version brings to ORF.

This first article in the series discusses a few important changes introduced by Exchange 2013 from ORF’s pespective.

Architectural changes

The Exchange team has significantly reduced the number of roles in Exchange 2013: in the preceeding two Exchange versions, you had Edge Transport, Hub Transport, Mailbox, Client Access and Unified Messaging roles. What you get now are Client Access Server and Mailbox Server (with Edge Transport to be introduced later). A great introduction to the new roles is available in the Exchange Team Blog.

A few things to note:

• In Exchange 2013, Internet email is processed by Client Access Server (CAS). In fact, all client communications have been delegated to CAS, from SMTP to Outlook connectivity.
• Mailbox Servers never talk to clients directly, so any Exchange 2013 organization will have both CAS and Mailbox Servers.
• The new roles may be deployed on different servers, but they can also co-exist on a single server (we guess this will be a common setup for SMB deployments).
• Mailbox and CAS must reside in the same Active Directory site.
• If your current Exchange setup involves Edge Transport servers, you may wonder what should be deployed in the DMZ. The answer is “Your current Edge Transport server”, because Exchange 2007/2010 Edge Transport will happily work with Exchange 2013. However, emails will have to be routed to Exchange 2013 Mailbox directly, bypassing CAS entirely.

Transport Agent changes

Along with the new roles, significant changes were introduced to the transport pipeline and the Transport Agents technology. ORF relies on this latter to hook into specific email delivery events of Exchange.

The Exchange 2013 Client Access Server – unlike the previous Hub Transport or Edge Transport roles – now offers only a reduced set of delivery events. In ORF terms, this means that only the Before Arrival filtering point is available under this role. On Arrival email filtering and monitoring outbound emails for the Auto Sender Whitelist are no longer available.

Mailbox Server does not impose such limits and all events that were hookable in previous Exchange versions can be still hooked. Alas, Mailbox Server is not suitable for Before Arrival filtering, because emails are always received via Client Access Server (or other front-end) and thus would be whitelisted by ORF.

Health Monitoring

One particular aspect of Exchange 2013 Managed Availability that affects ORF is the introduction of Health Monitoring services, now built right into Exchange without SCOM or third-party monitoring solutions.

Health Monitoring means that Exchange will now frequently send email probes to check the health of the components. These emails would be normally “seen” by the ORF, so 5.1 will do everything to “unsee” them, so as to prevent clogging the logs with these internal emails.

Other notable changes

• Transport Agents now run under different services under different roles: CAS loads agents into MSExchangeFrontendTransport and Mailbox uses the MSExchangeTransport service (which may be familiar to you from earlier Exchange versions). This means different services will have to be restarted to apply any agent configuration changes.
• Using the Exchange PowerShell Transport Agent management cmdlets is a bit trickier now. You may need these e.g. for adjusting the priority of the ORF Transport Agents. You will need to specify the -TransportService switch with Set-TransportAgent and under CAS, you will not be able to use the Exchange Management Shell (see the “TransportAgent cmdlets on Client Access servers require local Windows PowerShell” section in the Exchange 2013 Release Notes).
• The Client Access Server role is now a lightweight, stateless proxy component that does not do email queuing. Due to this, the Replay Directory is no longer available under this role. ORF relies on this feature in a number of situations, so we will employ SMTP as fallback for CAS.
• Exchange 2013 Administration Shell now runs on PowerShell 3.0, which is .NET 4.0-based. For legacy reasons, ORF 5.1 will provide both NET 2.0 and 4.0 versions of the Agent Installer (orfainst.exe).
• Transport Agents are also .NET 4.0 now, so we will ship different transport agent binaries for legacy Exchange versions and Exchange 2013.
• The native Edge Transport of Exchange 2013 (when released) will likely lack sufficient event support to run ORF.

Stay tuned for our next article about Exchange 2013 and ORF deployment scenarios.

After several years of providing high quality spam source information for the community, the NJABL DNS Blacklist is now shutting down.

NJABL was among the most recommended blacklists in ORF, so there is a good chance you are using it: make sure to disable and remove this DNSBL from ORF configuration (listed under the name “Not Just Another Bogus List (NJABL Combined List)”).
Find more information about the removal in our Knowledge Base article.

Vamsoft would like to say thank you on behalf of thousands of ORF administrators worldwide for the NJABL’s hard work in the past years.

Now that the world did not end after all (not in our timezone anyway!), I thought I’d share two piece of news with you. Let’s start with the bad one:

• You will still receive spam in 2013.
• On the bright side, you will be better equipped against them.

We are working on a massive overhaul of the URL Harvester engine in ORF, the component responsible for detecting, decoding, prioritizing and sorting URL payloads in spam, such as web links and email address domains. The domain names harvested from URLs are checked in URIBLs such as Spamhaus DBL or surlb.org to see if they are associated with spam.

Among others, the ORF URL Harvester is receiving Internationalized Domain Name support in ORF 5.1. IDN(A) is a set of standards which enables writing domain names in alphabets and scripts like Cyrillic, Japanese or Hebrew, so with the new IDN support, ORF will be able to discover and lookup links like http://русский.idn.icann.org. The significance of this new feature is explained by the statistics below, but it should also be noted that IDNs can be abused in phishing emails for IDN homograph attacks so this feature also adds an extra bit of security to your email systems.

Lab tests with the new URL harvester resulted in a number of interesting statistics.

• Total spam emails tested: 16232 (spam age between 48 and 2 hours)
• Emails with URL payload: 88.55%
• Emails with IDN URL payload: 4.37%
• Total IDNs discovered: 26 (all from the .рф ccTLD)
• Percentage of IDNs blacklisted in Spamhaus DBL: 84.62%

While the sample is too small to draw conclusions of scientific quality, the 4.37% figure and Spamhaus’ high
detection rate shows that IDN support in ORF 5.1 can be a significant contributor toward a better spam detection.

We have rolled out a few updates to vamsoft.com recently to improve the overall experience. A quick summary is available below:

• Website speed improvements: The average page load time was reduced by 40%, thanks to several optimizations, like combining a CSS files and JS files, using CDNs, GZIP’ing and caching content and moving small images to CSS. The optimized site works best in IE9+ and other modern web browsers.

• New Feature Requests RSS feed: The new feed publishes changes in a daily digest, significantly reducing the noise from votes and other minor events. See the Feature Requests page for the new RSS.

• Forum navigation bar: Navigating back to vamsoft.com from the Community Forums was quite frustrating, as no obvious links were pointing back to the site—now it’s a lot easier using the recently introduced navigation bar for the forum.

Missing something? Send your improvement ideas to us.