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 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

As promised earlier, we have revisited the question of supporting the IIS 6 SMTP Service under Windows Server 2008 and found workarounds for the technical issues of the platform. I am glad to report that ORF 5 will support the complete range of IIS SMTP Service versions from Windows Server 2000 to 2008 R2, extending ORF’s already complete support for all the above platforms for Microsoft Exchange.