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

We started to receive reports of Blackholes.us blocking all incoming emails.

This DNS Blacklist does not operate for some time now: the IP address space that they used for name servers now belongs to another, unrelated entity. Since many email administrators forgot to disable Blackholes.us in their anti-spam applications, the new owner continued to receive a huge amount of DNS queries. Due to this, they decided to return a 127.0.0.2 response for all queries, which means if you have Blackholes.us enabled, all incoming email will be rejected. (Similar thing happened to ORDB a while back)

To solve this, you should disable and/or remove Blackholes.us from your DNS Blacklist definition set (ORF Administration Tool: Configuration / Tests / DNS Blacklists). Finally, save your configuration to apply the configuration changes by pressing Ctrl + S. (Pre-4.3 versions also require a restart of the ORF Service: if you have such version, press Ctrl + U instead).

The recommended DNS Blacklists are listed in our best practices guide. We would recommend updating your whole definition set, as Spamhaus has also released an update recently. To wipe out Blackholes.us and to update Spamhaus at once, follow these steps.

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.

Spamhaus has recently announced a new list called Composite Snow Shoe List (CSS), which is now included in Spamhaus SBL and ZEN. To learn more about the new list and to download the updated definition file, please visit

http://www.vamsoft.com/zen.asp

The goal of the Composite Snow Shoe List is to spam the so called “snow shoe” spammers, who send only moderate amount of junk from a single IP to stay under the radar. They spread the load between multiple IP addresses and domains to dilute reputation metrics and evade filters (just like a snow shoe spreads the weight, hence the name).

Hopefully, the new list will improve your current filtering efficiency even further.

It is now official: ORF 5 will support the IIS6 SMTP Service of Windows Server 2008 R2. We just have finished testing an early build of ORF 5 on the above platform and everything seems to work great. We will also revisit the question of the now-unsupported Windows Server 2008 IIS6 SMTP Service – that platform was broken multiple ways the last time we checked, but that was a long ago and service packs may have fixed the problems.

We just have released a compatibility update for ORF 4.3 that enables using ORF with the Exchange 2010 Release Candidate. The update is available for testing purposes at:

http://vamsoft.com/r?mex14-rc-update (10kB ZIP download)

Installation instructions for the update are available in the ZIP file (readme.txt).

Without this update, you may experience the following problems:

• An error is displayed when querying the ORF Transport Agent status: ‘ERROR: Could not get the status of the “Vamsoft ORF SMTP Receive Agent” transport agent. Unexpected transport agent member type Microsoft.Exchange.Management.AgentTasks. TransportAgentObjectId for property Identity. Type expected: System.String.’,
• ORF cannot be uninstalled.

Installing the update fixes the above issues with Exchange 2010 RC. Please report any problems that you may experience to our technical support. Thank you.