[Mimedefang] Next generation mimedefang-filter

[Nik Clayton]

Paul Whittney wrote:
> However, I hit the same issue, multiple config files, with slightly
> different functionality, or a complete lack of certain functions. I
> actually had more trouble with revision control of the ziptest parts,
> the actual "defang notice", boilerplate additions, and the changes to 
> the bad attachment files between a number of systems.
> 
> So, I split up the mimedefang config file into a parts directory:

[...]

I thought about something like that.  And it's a good short term 
solution -- another would be to have the mimedefang-filter read a config 
file and turn on/off certain functionality based on the config file.

But it doesn't:

  1. Make it easy to unit test your functionality.

     If you make a change to the filter then (apart from the basic Perl
     syntax checks) you've got to run up a full copy of Sendmail + MD
     and send some test messages at it.

     Now, for completeness you should be doing this anyway.  But that can
     be a fairly time consuming process.  So it would be nice to have a
     way to unit test the filter's functionality to catch any regressions
     before you have to go in to the test lab.

  2. Make it easy to share specific changes to the filter, or integrate
     third party changes in to your filter.

     Hands up everyone who wrote their own code to do SPF checks, or dig
     inside .zip files, or allow whitelists/blacklists?  At the moment
     the best we've got for sharing code is things like:

     http://www.mimedefang.org/kwiki/index.cgi?SpamReportAddress
     http://www.mimedefang.org/kwiki/index.cgi?RelayCheckAddresses

     Wouldn't it be simpler to:

        perl -MCPAN -e 'install 
MimeDefang::Filter::Plugin::SpamReportAddress"

     or similar?

N