[Mimedefang] Future development
mdlist-20140424 at billmail.scconsult.com
Sun Nov 22 15:21:04 EST 2020
On 22 Nov 2020, at 13:32, Dianne Skoll via MIMEDefang wrote:
> On Sun, 22 Nov 2020 13:24:24 -0500
> Dianne Skoll <mimedefang at lists.roaringpenguin.com> wrote:
>> Anyway... I'd really like to see MIMEDefang development activity pick
>> up again. I'm hoping The McGrail Foundation will attract more
>> interest in the project.
> Specifically... these are things I would do differently if I were
> starting MIMEDefang now instead of 20 years ago. :)
> The C code is mostly fine; the milter and the multiplexor work
> pretty well.
> The Perl code is atrocious.
That's a bit harsh...
It is solidly non-OOP and clearly organically grown over a long time,
but I've worked with worse code that was more carefully designed.
> mimedefang.pl is over 7500 lines of
> Perl in one ugly file with a ton of global variables. It needs a
> overhaul. I would start by writing a MD::Filter base class
> and storing state in the MD::Filter object. Callbacks could be
> as methods and users could subclass MD::Filter to implement their
PLUS: A more elegant design. Probably easier to maintain long-term. More
accessible/attractive to trained developers who are more comfortable
MINUS: Raises the bar for Perl skill needed to implement local
customizations. Less accessible for people who only understand
> Functions like md_check_against_smtp_server, etc. should
> be broken out into helper modules.
Yes. Having done some work in and around md_check_against_smtp_server, I
agree that breaking out those sorts of utilities into other modules
apart from the core functionality would be a good idea, even if it's
just into a MD::Utils module full of subroutines.
> The actual filter file would be a very simple thing that simply
> instantiates a (subclass of) MD::Filter and calls $filter->run() to
> run the main mimedefang.pl loop.
Obviously OOPifying MD would be a v3 project, as it would break all
existing mimedefang-filter.pl scripts.
A nearer-term step to clean up the code a bit would be to break out
existing code to distinct modules that may (or may not) be the basis for
future object structures. This could result in supporting existing
configurations with a code base that is easier to maintain and
bill at scconsult.com or billcole at apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
More information about the MIMEDefang