Come out and enjoy a day at Austin’s door64 Tech Fair Thursday April 30th.  OtherInbox will have a booth set up and will be giving out some T-Shirts and demos of our newest features.  This is a first-of-a-kind grassroots event with a great potential for networking and being involved in what the Austin Business Journal recently quoted as “The No.1 city for job growth potential”.

The door64 Tech Fair will be at the Goodwill Center located at 1015 Norwood Park Boulevard, Austin, Texas 78753 on Thursday April 30th, from 11am until 4pm.  There will be panel discussions and even a party following the Tech Fair.  For more information and to RSVP for this event please, visit http://door64.com/techfair.

If you follow us on twitter, please @otherinbox and let us know you will be there. We would love for some of our current users to show their support by wearing an OIB T-Shirt and would like some of you to come by our booth to speak to potential new OIB users. Please help us get the word out there about this event and RT this blog.

If you are attending and would like to speak at our booth or help us demo OtherInbox, please email door64[at]peeps.oib.com.

This post was guest-written by "Mike Subelsky":http://www.subelsky.com/, OtherInbox Co-Founder On Tuesday we had a problem with the main database server we use to power OtherInbox, which turned out to be a great demonstration of the benefits of the cloud computing infrastructure that OtherInbox uses. Our database had suddenly become unresponsive, which caused the website to stop working. Since our mail delivery system is designed to be heavily redundant and not depend on the database, message delivery was not affected (the messages just queued up until the database became available again). We spent a few minutes trying to debug what had happened to the database, but as soon as we realized there would be no immediate short-term fix, we immediately launched a new database server, something that is easy to do as our servers are hosted in "Amazon Elastic Computing Cloud":http://aws.amazon.com/ec2/ (EC2). While the server was launching, I made a new copy of the disk volume where our database is stored. Since we use "Amazon Elastic Block Store":http://aws.amazon.com/ebs/ and take frequent snapshots of that volume, I had a very recent copy to work with. These two actions allowed me to rebuild the database in about ten minutes with no data lost. It took another five or ten minutes to get the rest of our cloud talking to the new database server, and then we were back online. When everything was up and running, I was able to kill off the old database server. We'll never know exactly why it failed, but part of the philosophy of cloud computing is you never depend on any one component lasting forever. Our site is running on 25+ EC2 commodity servers which have a small failure rate. They are guaranteed to run forever. In this case, our database server lasted 133 days before crashing. We've had other servers function over 300 days without a problem. For the most critical parts of our site, like the inbound mail servers, we run multiple independent, redundant servers in different parts of EC2, so that one outage would not affect the rest of the site. In the future, as we grow our service, we plan to add that kind of redundancy to the database server so that occasional cloud hiccups like this will be imperceptible to our users. We're sorry for the inconvenience but hope this gives you confidence that we are being very careful to preserve your valuable data.

"Despite filters, tidal wave of spam bears down on e-mailers":http://www.usatoday.com/tech/news/computersecurity/2007-11-22-spam_N.htm. A recent "USA Today article":http://www.usatoday.com/tech/news/computersecurity/2007-11-22-spam_N.htm highlights the fact that spam filters just don't work and they never will. The best spam filters catch 99% of the spam but let about 1% through. And they incorrectly delete a few good messages that you really wanted to get -- about 0.1% for the best of them. It's not surprising that they have hit a brick wall. Think about what a spam filter is trying to do -- it examines each message individually and decides if you want it or not. This is really hard! Some of the best spam filters actually use artificial intelligence techniques such as "Bayesian filters":http://en.wikipedia.org/wiki/Bayesian_filter to "learn" on a personal basis what you consider to be spam. But even they have a tough time telling the difference between a promotion to refinance my house and a news article about the recent credit crunch. And even the Bayesian filters can be tricked by spammers. It is easy for a filter to stop a virus. Each virus has a "signature" and so the computer can be 100% sure it is a virus without any chance of a mistake. No one wants to get a virus email so the computer can block the email. Even an email from your mom that's got a virus should be blocked! But lots of other email messages aren't so easy to figure out. An email that some people think is spam other people actually find interesting. It's hard to believe, but the reason why mortgage refinances, prescription drugs and get-rich-quick home businesses are so commonly found in spam email is because lots of people click on those email messages and purchase those products. Until the spam filter can read your mind, it will never really know for sure which message you want and which message to trash. In the end, there is almost nothing that a spam filter can count on as reliable. Spammers change everything up to trick the filters. They insert hidden text (sometimes Shakespeare, sometimes random text) to throw off the Bayesian filters. They constantly change the From address, domain name and IP addresses so that it's futile to try and keep up with which ones to block. Of course, spam filters don't do anything to discourage spammers. They actually encourage spammers to send more spam. Some spam always gets through the spam filters, so the spammer sends more, then more spam will get through. There must be a better way to handle this.