[Mimedefang] Future development

Dianne Skoll dianne at skoll.ca
Mon Nov 23 13:48:31 EST 2020

On Mon, 23 Nov 2020 12:41:00 -0500
Anne Bennett <anne at encs.concordia.ca> wrote:

> > The Perl code is atrocious.  

> Give yourself a break.  ;-)

Well, OK. :)

The code itself is not terrible.  I like to write clear code that any
newbie can understand (for "newbie", read "myself in 6 months time...")

What I mean is the *design* is atrocious, given that MIMEDefang is the
result of acretion rather than design.

(OTOH, I have worked on systems with beautiful designs but very tricky
and "clever" code where most of my time is spent reverse-engineering.
We don't want that either.)

>   - Initially (years ago), it was a bit hard to keep track of the bits
>     and pieces, because mimedefang.pl calls my filter file, and my
>     filter file calls various utilities provided by mimedefang.pl.
>     Any code re-org that would make it easier to untangle this would
>     help, even something as simple as putting the user-filter-called
>     facilities into their own Perl module.

Right.  Tracking the flow of control when callbacks are involved is tricky.

>   - I like to run with Perl taint checks on, but mimedefang.pl
>     doesn't cooperate well with that.

Oh, hmm. :)  That would be a lot of work.

>   - Picking up needed information (i.e., from the envelope and
>     message, and QID) seems to be different in each filter_*
>     subroutine.  I don't know how this would affect performance,
>     but if there were a hash containing all available header,
>     envelope, message status so far (e.g., did we mark as to
>     be rejected?), and QID information, and maybe even headers
>     in concatenated and decoded form, that would make writing
>     filter_* subroutines easier.

Yes, some sort of context object that held all of this would be good.

> > I would start by writing a MD::Filter base class
> > and storing state in the MD::Filter object.  Callbacks could be
> > implemented as methods and users could subclass MD::Filter to
> > implement their behaviour.

> As another poster mentioned, that would indeed require more
> advanced Perl chops from the end user (postmaster), though
> well-chosen examples might go a long way toward alleviating
> that requirement.

In my ideal world, you would be able to take an existing mimedefang-filter
script, and add two lines to the top:

        package MyFilter;
        use base 'MD::Filter::Compat';

and then have it Just Work.  I don't know if this is realistic or a pipe-dream.

> Well, there's still potentially a fair amount of homegrown code that
> people can add.  I'm assuming that this would somehow fit into "users
> could subclass MD::Filter to implement their behaviour".

Yes, exactly.



More information about the MIMEDefang mailing list