As some of you may know, software development is lots of fun and even more so is working with HTML. ORF 5 will utilize embedded IE browsers for UI purposes in more places and with lot more complex HTML code than previous versions did, so we got quite experienced with building HTML… still, we run into weird issues all the time. The best so far came up today and could be summarized as “the embedded web browser will forget to update the positioning of elements sticking to the bottom of the browser viewport if: 1) the document has XHTML 1.0 Strict DTD + 2) the parent window is resized _vertically_ (only – that is, resizing by grabbing the window bottom-right corner grip does work)”.

As I said, development is lots of fun :)

Vamsoft ORF, leading software based anti-spam solution for Microsoft® Exchange and IIS SMTP was awarded the VBSpam Verified award second time in a row.

The independent test conducted by Virus Bulletin’s Anti-spam team included 23 leading spam filtering solutions from around the world. The aim of the testing is to benchmark available spam filters in their ability to protect inboxes from the onslaught of spam e-mails. The testing and verification procedure has become an industry standard in the measuring and benchmarking the efficiency of anti-spam solutions.

Of the 23 products evaluated during the 2 week period, ORF was one of the only 2 complete solutions that achieved a 0.00% False Positive rate. Combined with the outstanding catch rate of 98.78%, ORF still stands as one of the best spam filtering solutions on the market.

“The problem of false positives in spam filtering is regularly played down…False positives frequently go by unnoticed – they may disappear among the vast amount of real spam that is blocked by a filter, so that neither the customer nor the vendor realize the extent of the problem.” said Martijn Grooten, Anti-spam Test Director at Virus Bulletin.

“False positives are an extremely important aspect of spam filtering that is regularly forgotten about. Having 1 or 2 spam emails per day is an annoying distraction from the daily workflow.

However, losing an important email because the filter wrongfully categorized it as spam can cause direct material or non- material damages to both the sender and the recipient. This is why we are proud to see that ORF is one of the best products in this respect.” explained Peter Karsai, Product Development Director of ORF.

We have been contacted by a few people last week about a small peak in the number of legitimate emails blacklisted by SORBS, which I believe was caused by escalated listings (see the blog post of SORBS for details). Though we discourage using the escalated zone of SORBS because of the higher chance for false positives (we removed response 127.0.0.6 from the DNSBL definition shipped with ORF a long time ago), some folks still have it enabled.

In short, ISPs do not care much if a paying customers is spamming until the whole IP block gets blacklisted by a DNSBL and other (innocent) customers start to complain. I do not think it’s the ideal way of doing things (i.e. to force the ISPs to get rid of spammers by blacklisting innocent people), on the other hand, I totally understand SORBS and other DNSBLs: they simply have no other choice if the ISP ignores their reports of abuse.

What do you think?

The ORF Log Viewer Tool is excellent for checking what happened to an email: by building simple filters with a few clicks, you have all the information you need. However, loading extremely huge log files (we are talking about hundreds of megabytes) may take quite a lot of time, as ORF logs of this size simply contain too much data.

For these cases, we provide a log parser tool which can parse and dump the log data into SQL databases, so you can use SQL queries to retrieve the information you seek. Moreover, you can also use this parsed data (now in SQL) for web-based reports for end-users (see the demo on the link above).

But what if a user asks you to show him all blacklisted emails sent to his address from the past week ASAP, and you simply don’t have the time or mood to setup an SQL database for this? Meet the Microsoft Log Parser.

The Microsoft Log parser is a “powerful, versatile tool that provides universal query access to text-based data”. By using it, you can

• simply search in multiple ORF log files at once
• export the query results to a CSV file, which can be then viewed in Microsoft Excel or OpenOffice.org’s Calc application

How can we do this?

1. First, download the Microsoft Log Parser from this site.
2. Install it.
3. Start it from the Start menu (it will open a command line window).

You should read the documentation about the query syntax. Basically, we need to set the input location and type, the output file (where we dump the query results), and the SQL query parameters. Here is a sample query with a single query parameter (recipient address is test@mydomain.com).

logparser -i:w3c “SELECT x-event-datetime AS Date-Time,x-event-class AS Event,x-event-severity AS Severity,x-event-msg AS Description,x-filtering-point AS Filter,x-ip AS IP-address,x-msg-id AS MsgID,x-msg-subject AS Subject,x-sender AS Sender,x-recipients AS Recipient INTO test_report.csv FROM ‘C:\Program Files\ORF Enterprise Edition\*.log’ WHERE recipient LIKE ‘%%test@mydomain.com%%'”

This command will create a file called test_report.csv in the Log Parser directory which includes all log entries for this recipient from the ORF logs (located in Program Files\ORF Enterprise Edition). Note that if you do not have the logging of the message ID in ORF Enabled (Configuration \ Global \ Log and events \ ORF Text log – Configure button \ Settings tab) you should remove the “x-msg-id AS MsgID” part.

As you can see, the query is flexible, so the possibilities are endless: feel free to experiment and share your ideas in the comments.

Quite often, our emails bounce back from our customers because of failed SPF test results. One might suspect our SPF record is broken, but actually the problem is caused by misconfigured ORF installations on the recipient’s end in all cases (our SPF record is fine):

Let’s assume the recipient has a primary MX with ORF installed, and the SPF test enabled. Also, there is a secondary MX hosted by the recipient’s ISP, but the secondary MX is not added to the Intermediate Host List of ORF. The Intermediate Host List (as the name implies) is a list of intermediate hosts through which emails are relayed to the primary MX (and ORF) from external sources. The sender server sends the email to the secondary MX, which relays it to the primary MX, finally, the recipient receives it. ORF should be aware of such hosts, otherwise it will think the secondary MX sent the email directly. This may cause spam emails allowed in, as the DNS Blacklist test will be uneffective (as ORF checks the secondary MX IP against them instead of the actual sender IP). Moreover, if you have the SPF test enabled, it will check the secondary MX IP against the SPF policy of the sender. Of course, the secondary MX is not authorized to send any emails in the name of the sender domain, so the (otherwise legitimate) email will be blacklisted.

To avoid this problem, you should add all external relaying hosts (such as secondary MXs) to your Intermediate Host List, so ORF can “look behind” your secondary MX at the On Arrival filtering point by checking the email headers. For more information, please read the Intermediate Host List and Header Analysis topics of the ORF Help.