[Mimedefang] Next generation mimedefang-filter

[David F. Skoll]

Nik Clayton wrote:

> 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.

I'm sure Citigroup could spare a few thousand bucks... :-)

> 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.

True.

> Second, it doesn't handle diverse requirements.

[...]

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

This is indeed a problem.  What we did in CanIt was separate out the
"facts" from the "policy".

So the "facts" modules might say:

- User xyz at foo.com is whitelisted.
- Domain foo.com is blacklisted.
- Message contains a JPEG extension.

The policy module is presented with these facts, and it decides what to
do about them.  And given the huge diversity of MIMEDefang implementations,
I rather doubt that a config file is sufficient.  Ultimately, I think
the policy module must be written in Perl.  It would be vastly simpler
than writing a MIMEDefang filter is now, because obtaining all the facts
is just a matter of having the right plugins.

> 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.

See above.  Automatically installing a plugin will make its facts
available.  It's up to the policy to decide what to do.

It's not quite as simple as I described, because you obviously want
to minimize processing, so if you know you'll reject a message because of
a fact obtained early on in the SMTP transaction, you don't want to bother
obtaining facts from the message content.  So CanIt splits modules
into "envelope facts" and "content facts", and the policy module is allowed
to make a decision solely on the basis of envelope facts.

Regards,

David.