[Mailman-Developers] 2.1.8 documentation mismatch

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 08 Jun 2006 15:35:55 +0100
Ian Eiloart <iane at sussex.ac.uk> wrote:

> The thing is that if you decide that Mailman isn't going to share its
> data with anyone, then nobody can set up a Mailman system which
> doesn't generate collateral spam. I'm not suggesting that Mailman
> should relinquish its internal functionality, just that it should
> expose that functionality.

All of Mailman's functionality already /is/ exposed, although it may
not be in a format you are familiar and/or comfortable with.  I think a
lot of people don't get this, so it's important to emphasize.

Mailman is more than just open source.  Because it's written in Python,
even a deployed and operational system has complete access to Mailman's
implementation, not just its data.  Take a look at the command line
scripts some time.  There's really nothing special about them because
they use exactly the same exposed functionality as any MTA extension
would use.  The only thing special about them is that one of us wrote
it and it comes with Mailman.

It's not like your typical MTA written in C where if they don't expose
the right hooks, you're mostly SOL unless you can implement the hooks
yourself, recompile and redeploy the new binary.

Okay, you have to be a Python programmer and you probably have to
understand enough of Mailman to know what the consequences of your code
is, but that really isn't a huge hurdle (certainly the former isn't for
any experienced programmer and for the latter, that's why we're
here! :).

> In fact, for exim, the MTA authors may have to do nothing, it might
> just be a matter of fixing the configuration. In fact, its
> conceivable that I could do that already, but I'd much rather know
> that Mailman developers had some kind of commitment to solving the
> collateral spam problem. And I'd like there to be a supported method
> for doing that (an API). At the moment, I ask my list administrators
> to NEVER automatically bounce (sorry, "reject") messages - and I
> don't think that's satisfactory.

I certainly agree that the entire email stack has to be defensive about
collateral spam.  I do believe that scripts could be written that could
help an MTA make /some/ decisions about the disposition of an email
message lower down in that stack.  I'm not even opposed to distributing
some with Mailman that have a proven track record, nor am I opposed to
refactoring some code and "blessing" some APIs that make this job
easier with some guarantees of stability across releases.  But I'm not
going to write them. :) There really is nothing stopping anyone else
from starting to do that now, if you think about the problem in the
right way.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRIhEPXEjvBPtnXfVAQJC/wP+KCPhMYf4nDYRJx9/gH4f5T4dy5TjFb0q
AxvGWNNq7UZOisMQwnyF9VmEFDFBZDzAfCVttgDIRF27ZqTIDeMOdb8vayCmWk9T
n5Yj+oo6iPNsgsKGce07rXSHWFEVTqb1xx55Tcv8O0qshoBpLGmITQG+ueBQ/h/0
J2icggSEFB4=
=hiCr
-----END PGP SIGNATURE-----