We just launched a new community feature of vamsoft.com, the Feature Requests section. This is a community-powered feature request tracker that allows browsing, voting and submitting ORF feature requests.

In the tracker, you have 10 votes and it is up to you how you distribute your votes – let’s say you really want us to implement “Configuration Synchronization“, so you cast 6 of your votes on it and only 1 vote to “SCL Scoring“, because you consider it as just a nice-to-have feature. Of course, when “Configuration Synchronization” gets implemented, you get your 6 votes back (and anyway, you can change your mind anytime).

Visit the Feature Requests section at http://www.vamsoft.com/features

We are collecting feature requests since Day 1 and have recorded more than 150+ so far, but only the top requests were added to the tracker. This is intentional: what you might have needed two years ago may no longer what you want now. In any case, please feel free to submit your request via the tracker and convince others to vote.

Happy voting!

In the recent months, we received multiple reports about MSExchangeIS 9967 event IDs in the Windows Event Log—our clients were wondering if ORF is involved in the issue. Well, it is not, but this Exchange 2007 problem is worth telling a few words about.

If you find warnings with event ID 9666 or errors with ID 9667, you are soon reaching/reached the quota on the number of Named Properties (you did not know you have anything called that, did you? :) The error message is something like this:

Failed to create a new named property for database “First Storage Group\Mailbox Store (server)”, because the number of named properties reached the quote limit (8250). User attempting to create the named property: “username“. Named property GUID: GUID. Named property name/id: “X-whatever“.

The issue is caused by the so-called X-headers. Emails have a well-defined set of standard headers, like From: which stores the sender or Subject: which stores the email subject. When email software wants to add something non-standard to the header, it adds them as X-headers, e.g. X-My-Special-Header: Is-Awesome.

Now, for every new X-header type seen, Exchange 2007 adds a new Named Property to the database, so X-My-Special-Header and X-Your-Special-Header take two entries, but X-My-Special-Header: Is-Cool and X-MySpecial-Header: Is-Awesome take only one, because they are of the same type, X-My-Special-Header.

Ok, but here comes trouble: there are awful lot of different software on the Internet and they simply love adding X-headers. The more the better. Given sufficient time and email traffic, you can actually reach the default quota of 8192 (or 16,384, but the max quota is 32,766). All those X-Spam-Status:, X-SpamInfo:, X-MIBTO:, X-Quarantine-ID:, X-DSPAM-Probability:, X-SEF-Processed:, X-LID:, X-My-Special: headers add up. I am subscribed to a newsletter where emails have a X-SEF-9ED26101-DDA5-4A4D-8030-449F502FF2BC header – even though this header is the same for every mailing, a quick search on the Internet shows that the GUID after X-SEF- varies, probably from installation to installation. Receive 8192 emails from various sites like that and you are out of luck. Sure, adding any X-headers is not wrong per se, it is just your Exchange that has hard time with these emails.

In case the quota is reached, Microsoft has solution on TechNet which basically recommends to set the quota higher and recover the database.

As a preventive measure, you can also remove unwanted X-headers— the HeaderFilterAgent does exactly that (disclaimer: we are not affiliated with the agent author). Before installing the agent, make sure that you have a good whitelist of X-headers you need: as can be seen in the comments, software sometimes relies on X-headers for communication.

My previous article outlined two solutions against the recent spam breakout: blacklisting your own domain and using SPF. This article will introduce a third one: an External Agent for ORF. If you are not interested in the mechanics of a simple External Agent, here is a direct link for the package download (then follow instructions of readme.txt). If you stay with me, I will show you how you can extend ORF by scripts.

External Agents are command-line programs that ORF starts with a few parameters, waits for them to finish and takes action based on the program exit code (a.k.a. “ERRORLEVEL” from the DOS times). Otherwise there is nothing special about them, so agents can be written in any programming language, from C++ to PHP. Thus, with the help of the Windows Scripting Host (WSH, shipped with Windows), you can make use of your existing VBScript or JavaScript knowledge for extending ORF.

The agent we need is not particularly algorithm-heavy, all we need is to compare the sender address to the recipient address. If they match, we have self-sending spam. If they don’t, it’s not self-sending spam.
ORF can pass the addresses as command-line parameters, wait for the script and assuming exit code 1 means a hit, blacklist the email on exit code 1.

So let’s see how our script looks like in VBScript:

Same stuff in JavaScript:

We can invoke these scripts using “cscript” (part of WSH) as

When testing from command-line, “echo %ERRORLEVEL%” will tell the (last) exit code.

To turn this whole thing into an External Agent, we create a new agent definition. On the Run tab, point the Agent Executable field to C:\Windows\System32\cscript.exe (make sure the file is there) and in the Parameters box enter

On the exit codes tab, add a new action for exit code 1.

And that’s all, we have a working External Agent.

Our website recently started receiving hits for the search keyword “vamsoft.exe“, so here comes a little background info for that file name: if you have a file called vamsoft.exe on your system, you are probably infected with a virus/malware. Of course, the file has nothing to do with us, we are actually the vendor of an anti-spam software called ORF Enterprise Edition and never released any binaries under the name vamsoft.exe.

The file is part of a malware, so you are recommended to get an anti-virus if you do not have one installed, or if you already have one, either update the definitions or contact the vendor. There are excellent anti-virus products that are free for personal use like Avast! Home Edition or the AVG Anti-Virus Free Edition.

Various sources name different malware as the host of vamsoft.exe, such as Win32/Sality.AM, Win32/Rungbu.A and Trojan.FakeAlert.H
(a few alternative names for the above: W32.Sality.AE, Virus.Win32.Sality.aa, W32/Sality.ao, W32/Sality-AM, PE_RUNGBU.A, W32/Rungbu-A, W32.Rungbu, Worm.Win32.VB.du, Generic VB.b).

You can make sure a binary is from us by checking the digital signature on the file. In Explorer, right-click on the binary, select Properties. In the dialog displayed, there should be a Digital Signature tab and the name of the signer should be “Vamsoft Ltd.” (certificate is from Thawte Code Signing CA). Our .NET binaries are not signed for reasons outlined earlier (thus there is no Digital Signature tab), however these should still include vendor information on the Details tab. When in doubt, check the file with our tech support.

UPDATE: Check out the second part of this article.

In the past few days, new spam campaigns launched that use the ages old trick called “self-sending spam”, which is about sending spam to you in your name. Spammers probably hope to circumvent your spam filtering with this, and, surprisingly, they often succeed, because people tend to put their own email domain on the whitelist.

What we want to suggest in this article is doing the opposite: blacklisting your own domain. If you add *@example.com to the Sender Blacklist, you are defeating spammers easily by turning their own weapon against them. If we assume that all emails legitimately sent in your name are whitelisted in ORF, we can also tell that the rest is not legitimate and thus shall be considered spam.

So how do we know that all legitimate emails are whitelisted in ORF? Here are few things to be considered.

ORF only “sees” emails arriving via incoming SMTP connections. A legitimate scenario when email is sent in your name is when it is outbound. If ORF is installed on the Exchange server, you have probably Outlook clients. These use MAPI to submit outbound emails to Exchange, so there is no incoming SMTP connection and ORF will surely not blacklist these emails, because they are not “seen”. So, if you have a single Exchange server only, ORF runs on that Exchange server and you have Outlook clients only (in Exchange mode), you have nothing to do.

Relaying must be whitelisted. Still the outbound scenario, but with SMTP relaying. In this case, the SMTP client (Outlook in Internet mode, Outlook Express or another internal server) will use SMTP to submit an outbound email to the server where ORF runs, which in turn will deliver the email to the final, external recipient’s server. These connections are seen by ORF and must be whitelisted.
Relaying is controlled either by granting relay rights to IP addresses, or by using SMTP authentication. If you control relaying by IP address, the address of these relay-granted hosts should be added to the Intermediate Host List of ORF (Configuration / Global / Intermediate Hosts).
When using SMTP authentication, make sure that the “Exclude authenticated clients from filtering” checkbox is set on the Configuration / Global / Miscellaneous page. This is the default setting, but in any case, check it.
The above will take care of whitelisting relaying. If relaying is controlled by IP and adding the Intermediate Host List does not help, you can also try adding the IP to the IP Whitelist, although we recommend switching to SMTP authentication more.

Unauthenticated emails. Note that the above will not play well with some solutions that try to send in your name, without using your servers. Typically, websites with “Send this page to…” functionality tend to be broken by this, because they are not authorized to send in your name. When possible, reconfigure these solutions or whitelist them.

SPF. Using SPF can be a good alternative to blacklisting your domain. By publishing an SPF policy, you tell the world what hosts are authorized to send emails in the name of your domain. If you have a single inbound/outbound server only, or all your outbound servers are listed in your MX record, publishing an SPF policy is as easy as adding a TXT DNS record to your domain with “v=spf1 mx -all”. This will tell the world that only the hosts listed in your MX record may send emails in your name. As ORF has an SPF test, it can check inbound email against your policy and if it denies the sender server (in case self-sending spam, it will), the email will be blacklisted right away. You can learn more about SPF at Wikipedia or openspf.org and use our SPF Check and SPF Syntax Validator tools. Note that with SPF, you can expect the same problems as described in “Unauthenticated emails” above.

Auto Sender Whitelist issues. We got a couple of tech support requests where even though the domain was blacklisted, the incoming email was whitelisted by the Auto Sender Whitelist. In this case, you have the following options:

• Add your domain to the Auto Sender Whitelist Sender Check Exceptions (Configuration / Tests / Auto sender whitelist, click Settings, select “Check Exceptions” – from ORF 4.2 only)
• Disable the Auto Sender Whitelist
• Clear the Auto Sender Whitelist and fix the problem that led to this (see below)
• Manually remove the related ASWL entries (External Database only, using SQL administration tools) and fix the problem that led to this (see below)

Typically, internal addresses do not end up on the ASWL. When ORF is used on a front-end, in a pre-Exchange 2007 environment, configuration errors may lead to such problem, however. It is because ORF records sender/recipient data of all outgoing SMTP connections (that is, those connections initiated by the local server). When running on a front-end, these include connections used to relay incoming emails to the back-end server. ORF multiple default exception settings to prevent recording this type of relaying, but the best is still to add the back-end server address to the IP-based exceptions (Configuration / Tests / Auto sender whitelist, click Settings, select the Collection Exceptions tab and edit IP-based Exceptions).
Also, you may want to switch the ASWL into “Customized per recipient” mode, in the same dialog. This will prevent using the whitelist entries from someone else.