I'm sure I've mentioned on this blog (probably a few years ago), that we spent about a year developing a very good anti-spam tool. The basis of which was using a huge number of mysql stored procedures to process email as it is accepted and forwarded using an exim mail server.

The tricks that it uses are numerous, although generally come from best practices these days.

The whole process starts off with creating a database with

• 'known' servers it has talked to before 
• 'known' domains it has dealt with before.
• 'known' email address it has dealt with before.

If an email / server / domain combo is new and not seen before, then apart from greylisting, and delaying the socket connections we also have a optional manual approval process. (using the web client).

Moving on from that we have a number of other tricks, usually involving detecting url links in the email and seeing if any of the email messages that have been greylisted (with different 'from') are also using that url.

On top of this, is a Web User interface to manage the flow and approvals of email. You can see what is in the greylist queue, set up different accounts for different levels of protection (either post-delivery approval, or pre-delivery approval etc..)

This whole system is very effective, when set up correctly. It can produce zero false negatives, and after learning for a while, is pretty transparent to the operations of a company. (email me if you want to get a quote for it, it's not that expensive...)

So after having created the best of breed anti-spam system, in typical fashion, we get asked to solve the other end.. getting large amounts emails delivered to mailing lists.

If you are looking for help with your mass email marketing systems, don't hesitate to contact us sales@roojs.com

Read on to find out how we send out far to many emails (legally and efficiently)

As we are not so crazy busy this month, I finally get time to write about one the  key tools that we developed to enhance our development process.

Back in 2010, We built a desktop application called app.Builder.js, written in seed (webkit+gnome). It's main purpose was to enable the rapid development of RooJS applications (a fork of ExtJS). It worked wonders over the years, enabling us to build and prototype applications quickly, and continually improve on them.

While it worked well, due to the nature of Javascript bindings into C, the occasional code problem would cause a complete crash. As most of the code is dependant on the javascript bindings, and gir files that define them. It also became a little troublesome to maintain, extend as it was dependent on the availability of gir bindings for new widgets.

Around mid 2014, It was decided to port the code from Javascript to Vala. Being a relative new-commer to Vala, we first tried porting our Gitlive application, which monitors the filesystem for changes and instantly commit's and pushes all changes. This relatively small project gave us the skills set ready to rebuild application builder in vala.

Background