OK. NO TCO OR ROI HERE. WE LIED.
Posted on September 30th, 2009 by Krisztian | Permalink

We are often asked if ORF could redirect blacklisted emails to the Junk folder of users for further review instead of rejecting them. The answer is yes, it is possible: a guide for Exchange 2003 is already available. For instructions on Exchange 2007, please read on.

On Exchange 2003, we use the Custom Weighting Feature (CWF) of Intelligent Message Filtering (IMF) to increase the Spam Confident Level (SCL) score of the email if ORF tags it. (I wish I could put more three-letter abbreviations into this sentence, but I ran out :) On Exchange 2007, however, thing are much easier, since we can create a simple Transport Rule to achieve the same thing in a few steps:

I. Settings in Exchange

A. Using the GUI

1. Start the Exchange Manage Console
2. Expand Organization Configuration > Hub Transport and select the Transport Rules tab
2. Click on New Transport Rule in the Action pane
3. Name the rule (e.g. “SCL of ORF-tagged emails”). You can add a comment as well.
4. In the Conditions page, select the condition to trigger this rule: “When the subject field contains specific words”
5. Set the “specific word” to [SPAM] (the tag we will use in ORF)
6. In the Actions page, select the action “Set the spam confidence level to value”
7. In the rule description, click on the 0 link and add a value that’s above your SCLJunkThreshold, e.g. 9, and click Next
8. On the Exceptions page, click Next again
9. Click New, then click Finish.

B. Command line

If you prefer command line, issue the following commands instead of using the GUI:

$condition = Get-TransportRulePredicate SubjectContains
$condition.words = @(”[SPAM]“)
$action = Get-TransportRuleAction SetSCL
$action.SCLValue = 9
new-TransportRule “Stamp SCL” -condition @($condition) -action @($action)

II. Settings in ORF

1. Start the ORF Administration Tool
2. Expand Configuration / Tests / Tests in the left navigation pane
3. Assign all tests possible to On Arrival
4. Expand Configuration / Filtering – On Arrival / Actions
5. Click the Actions button and select “Accept email and perform further actions”
6. Check “Tag email subject with the text below” and enter [SPAM]
7. Click OK and save your settings by pressing Ctrl+S. (If you use an older version (pre-4.3), restarting the ORF Service is also required, so press Ctrl+U in this case)

And that’s it: ORF will tag spam, the Transport Rule will increase the SCL score of the tagged email to 9 and it will land in the Junk folder. Cool, isn’t it?

Some Things To Consider
Note that the above solution may not work if you run any other filtering software which may interfere (e.g. dropping the email before it would reach the Junk folder). Therefore, if you want ALL spam detected by ORF to be redirected, you may want to configure this other software not to drop these emails. This includes the Content Filter Agent of Exchange as well. You can disable the Delete, Reject, and Quarantine actions of CFA using the following command:

Set-ContentFilterConfig -SCLDeleteEnabled $false -SCLRejectEnabled $false -SCLQuarantineEnabled $false
Posted on September 21st, 2009 by Krisztian | Permalink

Last week we have received a report of a strange problem: the ORF user’s log was full of “Could not create statistics for the client. EORFStatisticsServerError/The statistics server is not initialized.” messages. We suspected a problem with the statistics, which ORF sends to our server anonymously (this data is used to feed the 24 hours statistics counters on our website, and the DNS blacklist popularity list). The statistics to be sent are stored in a file called orfstat.dat. After further examination, We have also found some “Could not load statistics. Error: EORFStatisticsServerError “Statistics file “C:\Program Files\ORF Enterprise Edition\orfstat.dat” is corrupted: XML parsing error.” messages. I asked the user to send over the above mentioned file: it was 0 Kb… Somehow, the file got corrupted beyond repair.

To solve the problem, I suggested to delete the file orfstat.dat from the ORF directory: this will not cause any trouble, since ORF will recreate the statistics file when you restart the service, so you won’t lose the statistics displayed in the Administration Tool either (Configuration / Information / Statistics).

I also suggested to disable sending anonymous statistics sending in Configuration / Global / Statistics if the corruption happens again, but it seems to be OK now. We are still investigating what might have caused this (we suspect some MSXML related problem). Though we received only a single report so far, which clearly points to a system specific problem, I thought it would be better to publish the solution if you experience similar things. Has anyone seen such messages in the ORF log recently?

Posted on September 2nd, 2009 by Peter | Permalink

We have received a few issue reports regarding Exchange 2007 SP2 installation breaking ORF to the point that only reinstallation helps – actually, you can fix the problem without reinstalling. If you are wondering what is happening, it is the good old CDOSYS vs. Exchange 2007 issue, where the Exchange 2007 installer corrupts the registration of 32-bit CDOSYS, resulting in ORF errors logged like “On Arrival error: Unexpected exception EEngineError “Error EOleSysError updating the MIME information: Library not registered”". The installer of ORF fixes the corrupted registration, but if you perform an in-place upgrade, the ORF installer will not run and thus you need to fix the problem manually. If you get the above error, check this FAQ article.