A little bit more on security and back doors

A little bit more on security and back doors

Continuing on from my previous posts, I thought I'd talk a bit more about one of the hallmarks of my designs - the ability to override automated algorithms.

As a stock trader, there are two types of systems. Mechanical trading and discretionary trading. Mechanical trading is a specific set of trading rules that execute when criteria is met and there is very little room for the trader to make decisions other than selecting the initial trading system. Discretionary trading is when the trader has some rules that he uses to select stocks but allows himself the ability to overrule some existing rules based upon intuition or feel. I'm definitely a discretionary trader. I have existing trading rules but many times I will override those if I feel my rules do not accurately capture or reflect the current trading environment.

This preference for discretionary trading carries over to my designs in fighting spam. One of the applications that we have built is an internal interface for managing our IP blocklists. All the big players in the antispam industry use blocklists of one kind or another. We are no different. We have built our own list based upon an algorithm that I created over a year and a half ago and it blocks about 1/4 of our total inbound mail. For the longest time the delisting process was manual based upon rules that were developed over time. One of the projects that we have been working on for the past year is converting the list from a text based one to a database backed one.

In the new system, the process of delisting an IP will be done through a front-end web interface that interacts with the back end database. Some heuristics are built in to the interface such that when an IP delisting request is escalated, the decision to approve or reject the request is done automatically. However, I insisted on one thing: the spam analyst must have the ability to override any decision that the back end makes. Sometimes the rules that are set up to prevent errors do not accurately reflect all the circumstances surrounding the IP escalation request. I further insisted on the ability to proactively insert IPs into the database as well, regardless of whether or not they were listed (ie, a pre-emptive whitelisting or blocklisting). This would be analogous to a manual db insert or removal.

My theory in automating manual processing is that automation should handle the bulk of the work. But, there should always be the ability to override a decision that automation makes. That's a hallmark of my style of design.

It might be worth comparing your current implementation against the draft document of Best Current Practices for DNSBL's. If you haven't seen it already, it's available on the IETF website (draft-irtf-asrg-bcp-blacklists-02.txt) and it does promote the idea of having automated listing removal.