MailSentry - rewriting a ruby mail analysis tool in erlang

I’m going to become an erlang ninja. So rewriting some of my old ruby code that could use some parallelizing seems like a good way to start. I’ll start with a description of what the project is and why I think erlang would do a better job than ruby and then I’ll set out to prove myself right!

Mail Sentry (Ruby Version)

Years ago I had a grand vision of an email analysis system for hospitals that would scan all outbound emails for patient health information or other sensitive data. The system could be configured to block offending mail and notify the privacy office or force the message through a challenge response process that forces the receiver to view it over a secure connection rather than allow the message to be sent unsecured.

So I built it using Ruby. It’s never seen any “real world” action, but it works. The gist of it is this:

You take all the sensitive data you have (patients name, addresses, medical record numbers, etc) and it’s tokenized and hashed and loaded into an in memory DB.

There is a message analyzer that’s added as a filter on your organization’s mail relay (to sendmail, zmailer, whatever). It rips apart the message and converts binary attachments into tokenized text (pdf, word, etc. It can even do OCR on scanned images). It’s passed off to a DRB service that hosts the in-memory DB of hashed sensitive data.

The algorithm

The assumption is that if you have a list of just the first name of 100 patients/clients/whatever, then you aren’t actually violating anyone’s privacy because you haven’t uniquely identified any specific patient. So the DRB service builds a list of hits against specific patients/entities. For example, it determines that a patient 1 had their first name referenced, patient 2 had their last name referenced, patient 3 had their first, last and social security number referenced.

Those “hits” are passed to a rules engine that allows each institution to define what constitutes a breach of privacy. Pretty much anyone would agree that patient 3 in the example above is enough info to uniquely identify them. The rules also specify the action (allow, deny, log, notify, etc) to perform.

Mail Sentry Architecture

The erlang re-write

This all works great. So.. why re-write it in Erlang?

Well, we have many processes (managed by the mail relay) generating analysis requests, but only 1 DRB service to manage them. If we want to scale beyond a certain point it’ll get rough.

So, here’s the plan: Let’s rewrite the “Message Analyzer” as an erlang server. The ruby is working perfectly for ripping apart the email, running the rules engine, converting the attachments and so on.. so let’s leave it as Ruby.

If it all works out, we should have a super scalable email analysis tool that can scale to any sized organization, with any amount of sensitive data.

Stay tuned!

5 comments ↓

#1 jazzhammer on 06.12.08 at 10:53 am

an impressive idea, and undertaking. hospitals accept a severe risk of confidentiality breach with current practice. they’ll need something in place before they start getting sued.

#2 joshua noble on 06.15.08 at 6:36 am

If you’re looking to mimic some of the rules functionality from rein in erlang you might be interested in eXAT, which I can’t personally vouch for, but would worth taking a look at I’d think.

#3 joshua noble on 06.15.08 at 6:39 am

Ok, so after reading some code I realized the rules engine is ERES, which w/in eXAT and is stored here: http://sourceforge.net/projects/eresye/

#4 Luke Galea on 06.15.08 at 8:08 pm

Thanks Joshua. I was actually thinking I’d leave the rules engine in Ruby since it isn’t very computationally intensive. I’ll definately take a look at ERES though for academic purposes!

#5 MailSentry released — The Idea Forge on 07.27.08 at 8:51 am

[...] I’m not done re-writing the relevant ruby portions of MailSentry in Erlang yet. But I really should release early, release [...]

You must log in to post a comment.