A few weeks ago, we decided to test whether providing support via Skype would be a more popular (and suitable) way to contact us regarding ORF problems than our regular support lines (phone, email and our newsgroups). So I started to look for a good headset for this purpose, but surprisingly, neither of the manufacturers keep in mind that somebody will wear this thing for 8 hours straight… I read a hundred reviews but all headsets have this common problem: even the most expensive models are very uncomfortable to wear. OK, their sound is loud, clear and cool, but I do not really care if my skull is in a clamp for hours. I prefer large earpieces which are large enough to cover my (also large) ears on my large head. Maybe I am not part of the target audience, but even large headed people should use Skype sometimes :) (note to self: market gap)

Finally, we decided to buy a Sennheiser PC 135 USB headset. It has all the problems I mentioned above, but it will do.

The next step was creating a Skype account for the support calls and indicate our status on our website. It was easy to setup by following the steps described in the Skype FAQ. The final result was a link, which should indicate our status, but it does not: it shows me online even if I am offline. Great!

But at least our users could give us a call or chat with us about ORF problems, and we thought it would be a good thing none the less. So we waited for the first call and… in a couple of hours later, we solved the first problem via Skype, and some others later. Most of the callers preferred chat instead of talking, which is good, considering my terrible Hungarian accent. A couple of days later I started to see some weird things: Skype notified me about unanswered calls (from the US) from 4 days before. Why didn’t it notified me on the day after the calls took place? I have no idea… We solved these problems via email by the time Skype notified me, so it does not really matter, but still: it does not work the way it should.

As our company is located in Budapest (Hungary), at least the Skype calls are cheaper than calling us from the other side of the globe, but it cannot provide a solution for the timezone differences: if an ORF-user calls us when nobody is in the office, it doesn’t matter how he calls us… Additionally, we did not receive more calls via Skype then via phone, so it seems that the price of the call is not really a deciding factor.

I think we will keep this channel open for our users, as even the low number of calls worth it if the result is a satisfied customer. (Oh, it sounds so cheap, but that’s the way it is :))

ORF has two major issues with the Greylisting and the Auto Sender Whitelist databases:

• Sharing: databases cannot be shared between ORF instances
• Reliability: the database engine is not rock solid on some systems

Sharing is a simple case. Database sharing would be needed on networks with more inbound email servers: it is no fun when an email gets temporarily rejected two times by Greylisting, just because the left hand doesn’t know what the right hand is doing.

Reliability is a bigger issue. Only few systems are affected by engine reliability issues (namely, database corruption) and we found no common points between them, also the issue never reproduced in our lab. Under unrealistically high direct engine load, we could get some database operations to fail, but we could never achieve anything as serious as a database corruption. Still, the fact that we could drive the database into failures indicates that something is wrong with the thread safety of the database engine.

In ORF 4.0, we will address both of these issues.

To fix the reliability problems, ORF 4.0 will limit all database operations to a single thread only. The engine is proven robust with single threaded use and although this limitation reduces the throughput, the database performance will be OK for most smaller systems. Typically, ORF operations on complete well within 1 second (even on a large database), so 60 * 60 * 24 = 86.400 operations can be performed a day, enough for approx. 50.000 emails/day. It is just rough estimation, but I think the actual figures will be better and for the question of scaling, the answer will be the same as for the other major issue.

Database sharing will be implemented using external databases, with support for the following servers: Microsoft SQL Server (MSSQL) 2005 Express Edition, MSSQL 2000 and MSSQL 2005 (initially). The benefits of this model are numerous:

• allows sharing the databases between ORF instances,
• provides high performance,
• can scale well (SQL Server Express -> SQL Server),
• allows programmatic access to Auto Sender Whitelist data.

The price of choosing SQL servers is that the databases have to be created manually. We will provide downloadable guides with setup instructions and the necessary SQL statements, but running database servers requires some field-specific knowledge (e.g. adding users, configuring network access, etc.) that we cannot fully eliminate by guides.