[Mimedefang] Next generation mimedefang-filter

[Nik Clayton]

David F. Skoll wrote:
> 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... :-)

Sparing it is one thing.  Getting it out of them is something completely 
different.

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

Hmm, interesting.

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

Does this mean you must get all your content facts before you can make a 
content decision?

For example, both AV and Spam content filtering have to be run, and you 
can't say "Run the AV first.  Reject the message if it's got a virus, 
otherwise run the spam scanner"?

N