[Mailman-Developers] 2.1.8 documentation mismatch

[Ian Eiloart]

--On 8 June 2006 08:52:26 -0500 Brad Knowles <brad at stop.mail-abuse.org> 
wrote:

> At 12:20 PM +0100 2006-06-08, Ian Eiloart wrote:
>
>>  No, that's not true. What's required is that Mailman provide a simple
>>  API to allow MTA developers to ask Mailman whether a particular sender
>>  is permitted to post to the list. Holding rosters (a v3 proposal) in
>>  open databases would solve this problem - at least for Exim.
>
> 	That's fine, for Exim.
>
>>  Although Mailman is capable of filtering on other factors, I don't think
>>  the number of cases is significant. However, it might be possible to
>>  extend the API to provide information on other list policies.
>
> 	I disagree that it's not significant.  If you want to extend the "simple
> API" argument to other aspects of the filtering Mailman is capable of
> doing, that's fine.
>
>
> 	But you still have to have something to use that API to tell the MTA
> what it needs to know and when, and I don't think we can necessarily
> depend on the MTA authors to create that.  Maybe the Exim authors could
> and would do so quickly, but that's not the only MTA we have to concern
> ourselves with.

Well, that doesn't matter. Obviously no solution is going to work for *all* 
MTAs. Some couldn't work with *any* solution.

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.

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.


-- 
Ian Eiloart
IT Services, University of Sussex