[Mimedefang] Next generation mimedefang-filter

[Nik Clayton]

David F. Skoll wrote:
> This is on our roadmap... eventually...
> 
> We've just gone through massive pain to reorganize CanIt into proper
> Perl modules that are maintainable, easy to separate, and modular.
> We made the effort because CanIt is paying the bills.
> 
> Eventually, we plan on a complete revamp of MIMEDefang, but frankly,
> it won't happen until there is a compelling business reason to do it.
> We have way too much engineering work to do on our commercial products
> to devote significant resources to fixing MIMEDefang right now.
> 
> Unless some kind company were to sponsor a rewrite, my guess is it won't
> happen for at least a year.

Any interest in a community effort around this?  Last time I looked at 
this I got as far as pulling MD in to my public Subversion repository so 
I could branch it and start noodling around.  No noodling has happened 
yet, but I'd like something like this to make my life easier at Citigroup.

>>There needs to be some sort of ordering mechanism in here to ensure that
>>multiple plugins with a filter_sender() method get called in the right
>>order.
> 
> Yes.  But I don't like a configuration-file approach; I'd rather have
> plugins declare either which order they want to run in (similar to
> traditional UNIX runlevel scripts that use S00 through S99 to order
> themselves), or more ambitiously, to have plugins declare that they
> must run before plugins X, Y and Z, and after A, B and C, and do a
> topological sort to find the correct order.

I thought about that.  Two problems with that approach.

First, this means that I can no longer trivially find out what the order 
of plugin execution is going to be.  I either need to trace through the 
plugins and do the topological sort myself, or there needs to be a tool 
(or command line option, or something) that prints out the order.

Second, it doesn't handle diverse requirements.

For example, in my environment the blacklist trumps the whitelist.  If 
we've blacklisted you it's for a very good reason, and your presence on 
the whitelist is immaterial.

So you run the blacklist checks first.

I can quite easily see that being the other way around for many people, 
and whitelist entries trump blacklist entries.

So you run the whitelist checks first.

There needs to be some way for the end user to specify the order in 
which plugins run irrespective of the wishes of the plugin's author(s). 
  The simplest thing I can think of is an ordered list of names in a 
config file.

I also don't think it's a good idea that all you need to do to get a 
plugin to work is to install it, and have MD magically pick it up and 
start using it.  Installing a plugin and enabling a plugin should be two 
separate steps.  IMHO of course.

N