-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 08 Jun 2006 15:35:55 +0100 Ian Eiloart <[EMAIL PROTECTED]> 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----- _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
