Welcome to MSDN Blogs Sign in | Join | Help

Terry Zink's Anti-spam Blog

Protecting your mail from the scum of the internet
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.

Posted: Wednesday, April 09, 2008 10:04 PM by tzink
Filed under:

Comments

Manoj Katragadda said:

>>>>But, there should always be the ability to override a decision that automation makes.  That's a hallmark of my style of design.

Guess that is what called as a "BACK-DOOR" ????

# April 10, 2008 4:48 AM

David Cawley said:

Nice Analogy. I agree with your idea of manual override.

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.

# April 10, 2008 4:44 PM

Terry Zink's Anti-spam Blog said:

A couple of weeks ago, I posted three posts about security and back doors.  My point was that in

# April 25, 2008 1:16 AM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker