Do you have a secondary MX? If so, we are happy to save you a few bucks today.

How? Well, here is some food for thought! Let’s see a few disadvantages of running a backup MX.

• It costs money. More often than not spam and virus protection will cost you extra for your secondary MX.
• They are spam magnets. Spammers love going straight to your secondary MX, even when primary is up. And when that happens…
• …you will backscatter. Secondary MXs are typically lame relays that happily swallow emails for non-existent recipients. When your primary MX refuses to accept the undeliverable email, the secondary MX will send an NDR to the original and obviously fake sender. At very least you will be NDR-bombing innocent people, or end up on backscatterer.org.
  Be a good netizen, do not backscatter.

Of course, secondary MXs have benefits as well, such us… well, nothing I can think of.

Backup MXs were invented to accept and queue email when your primary MX is down. So if you do not have a backup MX, you will lose email when the primary goes down, right? Well, not quite. Most modern MTAs will recognize your only MX is down and will queue the emails for a few days. What you really gain by a secondary MX is the ability to set your own queue timeout. If it takes a week to fix your primary MX, you surely can make good use of the redundancy.

Is it worth it? Only your situtation justifies it. If you do not find a reasonable excuse, though, drop your secondary MX. Or, buy another copy of ORF for the backup server. We love that option as well :)

The current trial version of ORF (4.3) supports Exchange 2010 after installing a patch, but you may receive an error if you try to install the registered build on top of this patched trial version. That is because the installer of 4.3 registered does not incorporate the Exchange 2010 patch by default.

To solve this problem, you should simply ignore the installation error during the conversion process, install the patch again for the registered build, then issue the following command in the ORF installation directory:

orfainst -install

This will be addressed by the upcoming 4.4 version, which includes the patch by default.

Good news for people who want to use ORF on Windows Server 2008 or 2008 R2 with IIS SMTP (without Exchange): the wait will soon be over :)

We decided to release a new version before ORF 5 (which is expected to be released within a few months).

This interim release will incorporate the following improvements compared to 4.3:

• Support for Exchange 2010 by default (no patch is required)
• Support for IIS SMTP on Windows Server 2008 and Windows Server 2008 R2
• Some bugfixes

The new version will be available within two weeks for everyone with a valid Software Maintenance Agreement.

Lately, we have received many inquiries regarding the filtering of display names in emails. The display name in your email client (e.g. Outlook) is actually the From: field of the MIME email header. The MIME headers can be retrieved by selecting View | Options in Outlook (”Internet Headers”). To check the MIME headers in other clients, please visit this page). Example:

[...]
From: “VIAGRA \(c\) Best Supplier” (email@address)
[...]

You can filter this MIME From: field using the Keyword Blacklist of ORF:

1. Download the filter expression by right-clicking this link and selecting “Save link as…” (XML file)
1. Start the ORF Administration Tool
2. Expand Configuration / Tests / Tests in the left navigation tree and make sure the Keyword Blacklist test is enabled
3. Select Configuration | Import | Keyword blacklist… from the main menu, or navigate to Configuration / Filtering – On Arrival / Keyword Blacklist, right-click in the expressions box and select “Import list…”
4. Select the XML file you downloaded and click Open
5. If you already have some expressions in the list, you will be prompted “Do you want to overwrite…?”. Click “No” (otherwise your current expressions will be wiped out)
6. Press Ctrl + S to save and apply the configuration changes (pre-4.3 users should press Ctrl + U)

And that’s it: the expression above will block any emails, which have “Viagra” in their MIME From: email header line.

However, I should point out that we suggest relying on automated tests of ORF (like DNS and URL blacklists) as much as possible instead of adding keyword filtering expressions every time you receive a new type of spam (and instead of adding the sender to the Sender or IP Blacklists), so you should probably read our best practices guide regarding the recommended configuration if you have received such spam we mentioned above (”viagra” in the display name).

Our own ORF instance at Vamsoft (which is configured according to the guide) caught all of these using automated tests ;)

UPDATE: some of you guys reported that the regex doesn’t work: that’s because the expression above is altered by our blog engine, Wordpress (it replaces the double quote characters with left double quotation marks). To work this around, download this XML file from the link and import it to your Keyword Blacklist.

Following a server meltdown our new computer serving vamsoft.com was set up with Windows Server 2008 R2 (after running on 2003 for years). The installation itself went smoothly. The IIS 7 included in 2k8 is quite different from the previous version so I had to make a few adjustments – and learn a few new things -, but the real challenge begun when I started registering the smtp event sinks.

Started with the usual registering commands in a batch file, but the result was not familiar:

cscript smtpreg.vbs /add 1 onarrival NoreplyHandler CDO.SS_SMTPOnArrivalSink “rcpt to=noreply@*”
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

Binding Display Name Specified: NoreplyHandler
** Registration Failed **
Err.Number (HRESULT) = 0×46
Err.Description = Permission denied
ProgID = CDO.SS_SMTPOnArrivalSink
COM Category = {FF3CAA23-00B9-11d2-9DFB-00C04FA322BA}
Corresponding Event = onarrival
** Have you registered your sink COM class on this machine?

The error I got is “Permission denied” – of course, I have to run it with administrative privileges. But wait, I _am_ running it with such privileges!
Had no clue on what is happening. Checked if the mentioned class (CDO.SS_SMTPOnArrivalSink) is registered or not – it was. Checked NTFS permissions on cdosys.dll – seemed OK (I even granted full access to Everyone with no luck). That was time for… wait for it… Process Monitor! (great tool, indeed)

And there it was: cscript.exe (the process running smtpreg.vbs) is failed to get write access to the registry for the entry HKCR\CLSID\{CD000005-8B95-11D1-82DB-00C04FB1625D}, which is the CLSID of “SMTP OnArrival Script Host Sink Class”. Since smtpreg.vbs is something I do not want to mess with, I decided to go with the easier solution: give write permissions to admins for the forementioned registry key.

We all know the drill: regedit, search for the CLSID, right click, Permissions, check “Full Control” for the Administrators group, Apply… and got “Cannot set permissions … – access is denied”. This is because only the TrustedInstaller user has “Full Control” permissions over these registry keys, others only has “Read” access.

The solution: take ownership of this registry entry (right click on the entry / Permissions / Advanced / Owner tab / Change ownership to administrators). After applying the changes I was able to give Full Control to Administrators and run smtpreg.vbs successfully.

cscript smtpreg.vbs /add 1 onarrival NoreplyHandler CDO.SS_SMTPOnArrivalSink “rcpt to=noreply@*”
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

Binding Display Name Specified: NoreplyHandler
Assigning priority (24575 in 32767)
** SUCCESS **
Registered Binding:
Event Name :SMTP Transport OnSubmission
Display Name:NoreplyHandler
Binding GUID:{8CA00335-FF90-47E6-A1F2-BAA29926EFDC}
ProgID :CDO.SS_SMTPOnArrivalSink
Rule :rcpt to=noreply@*
Priority :24575 (0 – 32767, default: 24575)
ComCatID :{FF3CAA23-00B9-11d2-9DFB-00C04FA322BA}

cscript smtpreg.vbs /setprop 1 onarrival NoreplyHandler Sink ScriptName “c:\smtp_ext\noreply\noreply.js”
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

Binding Display Name Specified: NoreplyHandler
set property ScriptName to c:\smtp_ext\noreply\noreply.js

The sink quoted above is a simple SMTP event sink that consumes emails sent to a given address, as we do not want to deal with emails arriving to noreply@ addresses. There are many other things that event sinks are usable for. If you are interested in this powerful technique we have a few sample event sinks on our web site to start with:
Simple Attachment Filtering
Remove Read Receipt Requests on The Server

Yesterday, an Avast! anti-virus database update came with a serious bug. We (and others) suspect that by VPS version 091203-0, all applications written in Delphi were being marked as “Win32:Delf-MZG (Trj)”.

ORF was written in Delphi as well, so Avast! might have prevented ORF from filtering emails, or it might have moved ORF the executable(s) to the virus Chest. If you use Avast! and ORF on the same server, please make sure you restore these files as follows:

1. Right click the Avast! icon near your clock and choose Start Avast!
2. Cancel any scans Avast! tries to start
3. Click on the Chest icon: a list of quarantined files will appear
4. Right clicking on any file and select “Refresh all files” to make sure all files in the chest are listed
5. Right click on the files of ORF, select “Restore file” to restored them to their original location and at removed them from the Chest.

The bug has been fixed since by VPS version 091203-1, so make sure you use the latest definition file.

We are happy to announce that Exchange 2010 is now officially supported by ORF.

If you want to use ORF with Exchange 2010, all you have to do is download and install a patch for ORF 4.3, which is available at

http://vamsoft.com/r?mex14p

Please note that earlier versions are not supported, you will need either the registered or the trial version of ORF 4.3 installed. For installation instructions, please consult the readme.txt file.

If you have any questions, feel free to contact us.

The so-called “negative lookarounds” are a lesser known and rather useful feature of regular expressions—for instance, you can use these to construct an expression matching on any text, but “dog” or “cat”. Or, in ORF’s context, match on any email address, but those ending in “@mydomain.org”.

This comes very handy with ORF’s exception lists. For instance, let’s assume you want to turn on Greylisting for just a few selected local recipients. It makes sense, some mailboxes are just too important to suffer the delay that normally comes with the technology. As ORF has a Recipient Exception List for Greylisting, this is something you can do right away—yet I doubt you’d love adding 990 excepted local recipients to the list, just for the sake of enabling Greylisting for 10 non-excepted recipients (and then keep that list up to date, for a 1000-mailbox company). Of course, there is a better solution and yes, it is negative lookarounds.

In this particular case, a negative lookbehind regex will help. This is what it looks like for one email address (a@example.com):

.*(?<!^a@example\.com)$

Both a@example.com and b@example.com:

.*(?<!^a@example\.com)(?<!^b@example\.com)$

a@example.com, b@example.com and c@example.com:

.*(?<!^a@example\.com)(?<!^b@example\.com)(?<!^c@example\.com)$

The first regex will match anything, but a@example.com. The second regex will match anything, but a@example.com or b@example.com. The third one—you already figured it out.

The logic around exception lists gets a little complicated, but how this would translate to human language is: “Make an exception if the recipient address is anything, but a@example.com”. Note that all addresses must be listed in the same regex: if you tell ORF to “Make an exception if the recipient address is anything, but a@example.com”, ORF will look no further, because it already knows the zzz@example.com is excepted, regardless if you have a second similar statement about b@example.com. What you really need to tell ORF is “Make an exception if the recipient address is anything, but a@example.com or b@example.com or c@example.com”, in a single step, using the combination technique above.

Just a few ideas what can be done with the help of this trick:

• To enable certain tests for specific domains or recipents only.
• To disable Recipient Validation for all domains, but one or a few.
• To blacklist all .dat attachments except winmail.dat.
• To blacklist all attachments, except .pdf and .doc ones.

And the list goes on. You can learn more about lookaround assertions at regular-expressions.info and in the PCRE manual.

In case you missed the news, Windows Server 2008 R2 became generally available on October 22. Good news for early adopters: ORF 4.3 + Exchange 2007 2010 works wonderfully on 2008 R2, so if you plan upgrading, ORF 4.3 will be there for you. To recap, the Exchange 2010 RC is supported by a patch and ORF 5 will support the entire line of Windows Servers (up to 2008 R2) in IIS SMTP-only mode as well.

We are on Facebook now! Become a fan of ORF, get your dose of ORF news delivered right to your wall and show us how you are! :)

    Visit our Facebook Page