Posted on January 16th, 2009 by Peter |
PermalinkIn 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.
Posted on January 6th, 2009 by Peter |
PermalinkMy 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:
exitCode = 0 ‘ exit code 0 means no error, no hit
If WScript.Arguments.length = 2 Then
’ get sender and recipient list parameters
strSender = WScript.Arguments(0)
strRecipientList = WScript.Arguments(1)
’ compare sender to the recipient list – if they match, we have a hit
If StrComp(strSender, strRecipientList, vbTextCompare) = 0 Then
WScript.Echo “Sender and recipient addresses are the same.”
exitCode = 1 ‘ exit code 1 means hit
Else
WScript.Echo “Sender and recipient addresses are different.”
End If
Else
’ we got less or more than two parameters
WScript.Echo “Invalid number of parameters.”
exitCode = 255 ‘ exit code 255 means error
End If
‘ set exit code
WScript.Quit exitCode
Same stuff in JavaScript:
var exitCode = 0; // exit code 0 means no error, no hit
if (WScript.Arguments.length == 2)
{
// get sender + recipient list parameters and convert them to
// lowercase for case-insensitive comparison
var strSender = new String(WScript.Arguments(0)).toLowerCase();
var strRecipientList = new String(WScript.Arguments(1)).toLowerCase();
// compare sender to the recipient list – if they match, we have a hit
if (strSender == strRecipientList)
{
WScript.Echo(“Sender and recipient addresses are the same.”);
exitCode = 1; // exit code 1 means hit
}
else
{
WScript.Echo(‘Sender and recipient addresses are different.’);
}
}
else
{
// we got less or more than two parameters
WScript.Echo(“Invalid number of parameters.”);
exitCode = 255; // exit code 255 means error
}
// set exit code
WScript.Quit(exitCode);
We can invoke these scripts using “cscript” (part of WSH) as
cscript /nologo selfspam.js sender@example.org recipient@example.org
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
/nologo C:\MyFirstAgent\selfspam.js {SENDER} {RECIPIENTS}
On the exit codes tab, add a new action for exit code 1.
And that’s all, we have a working External Agent.
Posted on January 5th, 2009 by Peter |
PermalinkOur 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.