[Mailman-Developers] GSoC 2013 - GNU Mailman - Introduction and Project Discussion

[Terri Oda]

On 13-04-11 10:44 AM, Stephen J. Turnbull wrote:
> 1.  Mailman is the wrong place to do filtering.  It's equally
>      effective, normally covers more messages, and is somewhat more
>      efficient in resource usage to do it at the MTA.
> 2.  Any new algorithms*should*  be made available at the MTA level
>      where they can be best put to use by more people.  This implies
>      something that either plugs into existing filters (such as
>      spamassassin) or MTAs (ie, milters) rather than a Handler.
> 3.  Adapting existing filters is generally pretty trivial: you write a
>      10-line custom Handler that pipes it to an external process.  This
>      isn't big enough for a GSoC project.
> 4.  To the extent that new algorithms are involved, I have doubts that
>      Mailman mentors have the kind of expertise needed to really help
>      with such a project (I could be wrong, but I certainly don't know
>      much about that kind of text processing, and I don't know that
>      anybody else in Mailman has expertise in it).

Writing individual pipelines may be trivial, but making a user interface 
for managing said pipelines is non-trivial.  Right now, our pipeline 
management interface is "there's a text box in postorius that lets you 
choose a pipeline.  It's not even a dropdown, and you may be screwed if 
you make a typo" which is obviously not how I want it when we release. ;)

I see a potential project timeline going something like this:

A. make a set of custom Mailman 3 Handlers for some well-known existing 
anti-spam/anti-malware software.  (Maybe 2-3 weeks of work here, finding 
2-4 reasonable pieces of software, setting them up, writing the 
handlers, and testing them)

B. make an interface in Postorius so list admins can 
enable/disable/reorder these and any whitelisting happening within 
mailman.  This should involve making an interface in Postorius that 
gives admins the ability to change the Pipeline being used, and will 
likely involve a small amount of user testing to make sure said 
interface doesn't have risk of disastrous results if the administrator 
does the wrong thing.  (Another 3-4 weeks of work including user 
testing, unit tests, and documentation)

C. Figure out how to set up some sort of packager that can install 
handlers + antispam software so that the site admin has an easy way to 
set these up if requested. (Another 3-4 weeks of work, including testing 
any scripts on a few different OSes and extensive documentation)

D. If there's any time leftover, implement some clever new filter (and 
appropriate Handler) that makes use of the list information itself (e.g. 
subscriber list, archives, etc.) to make better spam decisions. (at this 
point, you've got maybe 2 weeks left in the GSoC timeline)


I think that constitutes enough useful-to-mailman work to justify the 
google funds, gets us some customizable spam filtering (which as you 
say, is a frequently requested feature), but doesn't turn us into 
something we're not.  That's why anti-spam made this year's gsoc list 
even though we've always said "do it in the MTA" and I'm not about to 
change that policy in general.

Do feel free to disagree with me, of course, Stephen. Or complain that 
I'm using the lure of antispam to get someone solve my user interface 
for pipelines problem, which I totally am. ;)

  Terri