Well, that is an easy question. The answer is 3.2%.

The “Real reverse DNS test”—that is, checking whether the sending server has a DNS name—is in the Top 10 requested features since years. So far we resisted adding it to ORF, due to the high false positive rate and once or twice a year I ran a test on our legitimate email sample body to see whether the false positive figures changed. My last test was performed on ORF tech support emails from the last 45 days and the false positive rate was an unacceptably high 3.2%.

Sure, we can treat this type of test a policy enforcement tool instead of a spam filter, but come on, who want to lose 3.2% or even 0,5% of the legitimate emails? Yes, we could add a big flashing warning sign telling “You will shoot yourself in the foot”, but I think it is better not to allow the user to shot herself in the foot at the first place.

What do you say?

If you ever felt awkward for not knowing how to calculate subnet masks without using a subnet mask calculator, consider that neither we could have survived without NetCalc. There are so many things in life to waste your time with, all better than learning subnet calculation, right?

When we decided to use the dotted subnet mask notation for defining network ranges in ORF (you know, like 192.168.251.1/255.255.255.0), we thought that it is only us who have troubles converting the 192.168.251.1-192.168.251.255 range in mind into a subnet masked format. As it slowly turned out, we were wrong. Good news: finally we fix this.

The next ORF release is going support various network range notations, so you can basically enter IP ranges in whatever format they come. The supported formats are:

• 192.168.251.0-192.168.251.255 (text range)
• 192.168.251.0/24 (CIDR notation)
• 192.168.251.0/255.255.255.0 (dotted IPv4 subnet mask)
• 192.168.251.* (wildcarded)

The next thing to come is the Log Viewer update – brand new, improved filtering, free-text search and updates required by the log format changes.

I just finished implementing an ORF improvement that we call Combined Actions. This allows combining specific On Arrival actions, for instance, tagging the subject plus the header plus redirecting the email.

Unrelated as it may seem, this improvement bought some changes to the ORF Text log format. The latest 3.0 log format has event classes for each type of action (14 event classes, from TagMailHeader to IgnoreMailRecipient) and so combined actions would have required to introduce new event classes for every possible combination (or, just to allow multiple event classes for a single event), causing a boom in the number of possible event classes.

This, among with other reasons, made us to re-think how logs should like and to come up with a few changes that we believe make logs easier to read and more useful.

First, we reduced the number of event classes to five: System, Pass, Whitelist, Blacklist and Intermediate. I think the first four are quite straightforward, but the Intermediate event class requires a little explanation: this is an event class that reports an intermediate action performed on the email. Currently, these are:

• Recipient removal at On Arrival. This may occur if some, but not all of the email recipients are blacklisted, e.g. by the Active Directory recipient validation.
• Recipient whitelisting at On Arrival. Again, this may occur if some, but not all of the email recipients are whitelisted.
• Attachment replacement (Attachment Filtering).

To identify the exact action performed, a new Action column has been introduced (can describe multiple actions, e.g. TagSubject+Redirect).

Another change was to eliminate the optional “Server” column, as it made little sense to log the the server name with every log message when the server name cannot be changed without rebooting the server. The local server name was moved to the ORF log header and it is no longer optional.

The next version’s log will have one more thing that I guess you will like: an optional email subject column. The subject is logged in UTF-8 encoding (ASCII letters kept human-readable), in URL Encoded format.

One of the most frequently requested features is to exclude Out Of Office autoresponses from the Auto Sender Whitelist address collection. I am happy to report that the next ORF release will take care of this problem.

In addition to the current IP-based exceptions, the next version will support making exceptions based on the subject of the outgoing email. This is specifically for filtering out Out Of Office autoresponses or any other automatic response where the subject has a distinguishing pattern.

Some automatic responses may not have a common target IP or fix subject – for example, if you run a mailing list or a challenge/response email filter – and for excluding these the next version will offer another technology, called “Auto Response Detection”. This will check if an email response is sent so fast that it is reasonable to suspect an automatic response.

For the subject-based exceptions, we’d like to provide a default list of Out Of Office subject patterns in as many languages as possible. Unfortunately, we did not find a website which collect these, so if you can extend or correct the list we have now, please drop us an email to orf-support@vamsoft.com with the subject sample.

Bulgarian: Извън офиса съм Автоматичен отговор
Chinese (simplified): 外出时的自动答复
Chinese (traditional): 郵件答錄機自動回覆
Danish (?): Autosvar – Ikke til stede
English: Out of Office AutoReply
French: Réponse automatique d’absence du bureau
German: Abwesenheitsnotiz
Hungarian: Házon kívüli automatikus válasz
Japanese: 不在時の自動応答
Portuguese (?): Resposta automática para ausência do escritório
Polish: Autoodpowiedź (poza biurem)
Russian: Автоответ при отсутствии на работе
Slovenian: Samodejni odgovor o odsotnosti iz pisarne
Spanish: Respuesta automática por ausencia de la oficina

Thanks for everyone who helped to update or extend the list!

We recently started to sign every ORF PE binaries digitally—you know, trust, integrity and all. For signing the files, we use Microsoft’s signcode that offers a command-line interface for Authenticode signing. All we need is to pass the .SPC file (Software Publisher Certificate), the .PVK file (Private Key), the binary file and maybe the public timestamp service URL of Verisign. It is quite simple:

signcode -v spc mycert.spc -v mycert.pvk -t http://timestamp.verisign.com/scripts/timstamp.dll mybinary.exe

Alas, it quickly turned out that signcode does not play very nice with build scripts. The private key is password-protected and signcode does not support specifying the password as a parameter. Instead, it prompts for the password in a dialog every time a file is signed. Apparently, I am not the only one who think it is a problem.

The best solution I found on the Microsoft newsgroups is to find the password dialog window by its title and send the password as keyboard messages. I do not know what you say, but simulating user input makes me hiccup and also anything that pops up a dialog can hardly be called ‘unattended’.

By further research, now for an API, I found that Microsoft’s CAPICOM 2 can do the signing very easily and also allows specifying the private key password. It wants a .PFX (PKCS #12 certificate) file instead of an .SPC and .PVK, but Microsoft offers another utility call pvkimprt that can combine the .SPC and .PVK into a .PFX as:

pvkimprt -pfx mycert.spc mycert.pfk

This will invoke a wizard for making the .PFX export. Once you have the .PFX, you can continue with signing. The following JScript code snippet demonstrates using CAPICOM 2 for code signing:

var Signer = new ActiveXObject("CAPICOM.Signer");
Signer.Load("mycert.pfx", "mypassword");

var SignedCode = new ActiveXObject("CAPICOM.SignedCode");
SignedCode.FileName = 'filetosign.exe';
SignedCode.Description = 'Here Be Dragons';
SignedCode.Sign(Signer);

By adding the following line the above code, you can also timestamp the file.

SignedCode.Timestamp('http://timestamp.verisign.com/scripts/timstamp.dll');

And that’s all.

SECURITY WARNING: It is quite obvious that signcode lacks the password option for security reasons. Microsoft is absolutely right about private key security—your code signing certificate and password are worth a lot more than the few hundred bucks you paid for them, so you really want to store it securely. Hardcoding the password into a script is definitely not secure, but probably you could make use of the above when you have to sign a couple of files at once.