Tag Archives: ORF 5.2

Exchange 2013 SP1 Compatibility Notes (Updated)

This post is quick summary of what you should know about Exchange 2013 Service Pack 1 and ORF compatibility.

Compatibility with SP1 Client Access or Mailbox Servers

Compatibility with the new Edge Transport of SP1

  • Edge Transport was (re)introduced to Exchange 2013 with Service Pack 1. This is an entirely new server role, so neither ORF 5.1, nor ORF 5.2 supports it. We have started researching the new role and it will likely receive support in a dedicated release after ORF 5.2.

ORF 5.2 Beta: What’s in it for me? (Part 1)

Now that the beta of ORF 5.2 is just around the corner, we thought you’d appreciate a few words on what the new version covers. In this three-part series, we’ll look into some of the new features.

  1. Part 1: The Attachment Quarantine (this article)
  2. Part 2: Log Event Explanations from Email Notifications
  3. Part 3: Configuration Snapshots 

What is the Attachment Quarantine?

One of the useful new features arriving with 5.2 is the Attachment Quarantine. The concept is simple enough: whenever an email attachment is blacklisted by the Attachment Blacklist of ORF, the original attachment is saved in the file system to a dedicated folder for administrator retrieval.

This ability to recover the original attachment can come handy in a number of ways. For example, it enables you to enforce stricter attachment rules. When you implement a policy to allow .ZIP and .DOC attachments only, you still will be able to manually recover that .PSD file the graphic designer sent to marketing 15 minutes before the print submission deadline and right before he went offline to catch his flight to The-person-you-have-called-is-not-available-land. Handy, right?

Quarantining normally happens on a per-attachment basis, i.e. only those attachments will be quarantined that were blacklisted by ORF. However, when the email gets dropped due to an attachment filter hit, all attachments will be quarantined. This enables complete recovery of the email attachments on an accidental blacklisting.

Another thing to know about this feature is that attachments may be quarantined under a different file name than the original one. I particular, a new file is generated when:

  • A file with the same name is already in the quarantine folder (think of “agreement.docx”).
  • The file name would pose a security threat. Nothing stops Dr. Evil from sending an email with an attached file like “\Windows\explorer.exe”, “LPT1” or file.txt:stream, so ORF is a bit paranoid about path components, reserved characters and reserved file names.

Due to the above, you should always check the quarantined file name when starting the recovery. This file name can be found in the ORF logs, but you can also add the quarantined file name to attachment replacement notices under Configuration / Blacklists / Attachment Filtering / Settings.

Once turned on, the quarantine can run unattended, thanks to the automatic retention control that deletes files after 30 days by default. And when I say “files”, I mean “any files older than 30 days”, so be sure to use a dedicated directory for the quarantine. While you’re at it, it is probably a good idea to exclude this folder from real-time antivirus scanning as well, because some of those quarantined files will inevitably be viruses. If you’re not into compiling a nice library of viruses, that’s OK as well, just be aware that anti-virus software may remove quarantined files or cause warnings in ORF about files cannot be written in the quarantine.

There’s more to ORF 5.2 than just this feature, stay tuned for our next article in the series.