[Mailman3-dev] Flexible data storage

[Erez Zadok]

In message <1079386691.5149.278.camel at anthem.wooz.org>, Barry Warsaw writes:
> On Mon, 2004-03-15 at 16:22, Erez Zadok wrote:

> I totally agree.  I'm thinking of Mailman 3 more as a library or a
> framework than an application.  Of course, only a small number of
> hackers will care about that, and we need to keep in mind that we're
> going to distribute something useful.  Which means that there will be
> default implementations of most of the APIs.  Having a turnkey list
> manager that's at least as easy and featureful as MM2 is a high
> priority.

Agreed.  A library alone would not be terribly useful to anyone.  It has to
have at least a superset of sorts of the features of V2.

On a related note, it's vital that MM3 will be as much as possible a drop-in
replacement for MM2.  If a configuration/format change is required then I
don't mind running a script "convert-v2-to-v3.py" but I don't want to have
to hand-fix or hack my lists for V3.  It'd be even nicer if there were a
backout option ("convert-v3-to-v2.py").  All these will be crucial for MM3's
adoption (you don't want to be stuck maintaining both v2 and v3 for years,
right?)

I'm reminded that one of the reasons why EXT3 was adopted so quickly was
that there had always been a simple procedure for converting an EXT2 file
system to EXT3 -- *and* back(!)

> > - I should be able to easily define a chain of pre-processing filters (e.g.,
> >   spamc) to get a hold of the message before MM does.
> 
> +0, mostly because we have to tease out where the boundary between the
> MTA and the MLM is going to be.  For example, a virus detector probably
> belongs in the MTA long before Mailman sees the message.  A spam
> detector /might/ belong in the MTA, but clearly Mailman wants to do some
> classification of messages before it hits the list membership.

Yes, well, there's a raging debate where anti-spam/anti-virus things should
be addressed: the MTA, LDA, per-user, ingress routers, or even congress.  I
personally think that ultimately the entire Internet will have to move to a
strongly authenticated form of SMTP -- that seems to me like the most
appropriate place for such filtering software.  But we're a long way from
that happening, so for the time being, it'd be nice if MM3 could support it.

Therefore, it is even more important that the way for supporting anti-spam
packages in MM3 would be through flexible hooks/APIs.  One day, when we have
anti-spam integrated into SMTP, I'd want to turn *off* Mailman's support for
that (in fact, even today you could buy routers that have anti-spam built in
--- yes, they have to assemble whole SMTP messages from individual packets,
inspect each message, then fragment the message again into packets for
sending to the next hop).

Erez.