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.2 Beta: What’s in it for me? (Part 2)

Now that the beta of ORF 5.2 has arrived, 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
  2. Part 2: Log Event Explanations from Email Notifications (this article)
  3. Part 3: Configuration Snapshots 

Log Event Explanations from Email Notifications

We do everything to make our log messages self-explanatory, but the log is just not the medium for thorough education on the subject. Twitter posts are full of those URL shortener bit.ly links, because there’s little wisdom besides “lol”  you can share in 140 characters.

Recognizing how logs will always fall short of giving you all the information you need, we developed this special knowledge base for ORF 5 that gives you detailed explanations for the most common events in ORF based on the event message. We are periodically expanding the range of articles available using the search logs generated by your event lookups. Also, for every new feature, we add articles for every new log message.

Have you noticed the “Explain” button in the ORF Log Viewer? If you didn’t, we’re with you: it’s not the most emphasized functionality there is. Also, we figure you have better things to do in the morning than starting the ORF Log Viewer, you know, just for the fun of it.*

But then if you don’t use the Log Viewer and prefer to ignore the hundreds of engineering hours we put into it (ahem!), how do you know if something important has happened to ORF? That’s right, you enable administrator email notifications about ORF errors!

In ORF 5.2, we made event explanations available from email notifications by adding an “Find event explanation online…” link to each email. This will bring you to our website where we’ll give you the same event explanation as the one you’d get from the ORF Log Viewer. That’s it, you no longer get denied one of the best features of ORF just because you prefer to ignore the hundreds of engineering hours we put into the Log Viewer.

* Although you may find some fun things there. The SMTP Module around ORF 1.0 had a code branch that was never to be called: the logic allowed for it, but we found no circumstances when this code could be ever executed. Accordingly, we put an error condition there that logged “This error never happens.” It turned out we were not entirely right (ok, maybe outright wrong), but sure there were a few fun moments between our tech support and dev teams.

Subscribe to our blog to get notified when in the next article we talk about the new Configuration Snapshots feature.

 

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.

ANN: ORF 5.1 Beta R1

We are happy to announce the first public preview of ORF 5.1, the first update to the highly appraised next generation of ORF.

The latest version features numerous improvements and tweaks, including

Learn more and experience ORF 5.1 first-hand at http://vamsoft.com/beta.

Join the beta community and share your questions and thoughts with fellow forum members in the Beta forum.

Thank you for testing ORF.

ORF 5.1 and Exchange 2013: ORF changes (3/3)

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.

ORF 5.1 and Exchange 2013

Part 1: Exchange Changes
Part 2: Deployment
Part 3: ORF changes (this article)

This finishing article of the series describes how ORF has changed to meet the challenges of Exchange 2013.

ORF changes that may directly affect you

  • The Replay Directory of Exchange is not available under standalone Exchange 2013 Client Access Server (CAS) installations. In a CAS-only setup, ORF will use SMTP as fallback option for sending emails. By default, emails will be sent to 127.0.0.1:25. If you have no receive connector listening at that address and port, make sure to point ORF toward a working SMTP server on the System / Microsoft Exchange page of the Administration Tool.
  • To prevent the new Exchange Health Monitoring email probes from clogging up the ORF logs, the ORF Transport Agents skip reporting emails sent to the system Health Monitoring mailboxes. The email addresses for these mailboxes are retrieved during ORF installation and upgrades. The addresses might change over time — introducing new mailbox databases and similar changes may require updating this address list. If it comes to that, just run “orfmexhelper” (see next bullet point) with the “-updatehealtmonitoring” switch.
  • The ORF Transport Agent Installer (orfainst.exe) has been renamed to “ORF Exchange Helper” (orfmexhelper.exe) and requires two further binaries to work (orfmexhelper2.exe and orfmexhelper4.exe), depending on the Exchange platform.

Changes under the hood

  • ORF Transport Agents now adapt to the locally available Exchange roles and hook the appropriate events only. This means you will receive only Before Arrival events in the log under Exchange 2013 CAS and only On Arrival ones under Exchange 2013 Mailbox Server.
  • The Administration Tool will show “N/A” for the status of the ORF Routing Agent under Exchange 2013 CAS, because routing agents cannot be installed under CAS.
  • The Transport Agent health status shown under a single-server (mixed) CAS and Mailbox Server installation by the Administration Tool is now a compound one, because you actually have two SMTP Receive Agents, one under CAS and one under Mailbox Server. The status will be “healthy” only if both SMTP Receive Agents are in healthy status. The same compund status is returned by the “-status” switch of the Exchange Helper.
  • The ORF Exchange Helper now detects the local Exchange platform and performs agent installation, uninstallation and status query according to the available roles and Exchange version installed.
  • The list of Exchange services to be restarted upon Transport Agent operations now depend on the Exchange 2013 roles you have installed locally. All components in ORF have been updated to deal with this change. The ORF Exchange Helper will specifically tell you what services to restart e.g. on reinstalling agents.
  • We have extended the ORF Setup, the Administration Tool and the ORF logs with notices to be displayed if the available Exchange roles limit ORF’s functionality in any way. You may receive such notification under standalone Exchange 2013 CAS and Mailbox Server installations.
  • Different Transport Agent binaries are used under Exchange 2013 (orftagent15.dll) and previous Exchange versions (orftagent.dll).

The first beta release of ORF 5.1 is just around the corner: stay tuned for more ORF 5.1 goodies!