[Mailman-Developers] Google Summer of Code - Spam Defense

[Timo Wingender]

Stephen J. Turnbull schrieb:
> Timo Wingender writes:
>
>  > This are my ideas so far. Is this welcome in Mailman and is it enough 
>  > for an GSoC Project? Where would it be best? 2.1.11? 2.2.0? 3.0.0?
>
> I don't speak for the core developers, but to summarize what several
> others have said and add a couple of points:
>
> - If you are going to reject or discard a post, you really want to
>   reject it in the SMTP transaction that submits it to your external
>   MX, not in Mailman.  This implies
>   
If you don't discard all messages from nonmembers then this is not 
possible. Of course everything which is obviously spam or produce an 
error in mailman should be rejected in the smtp transaction. But the 
must be discarded in mailman
>   - Since SpamAssassin (SpamBayes, etc) are easily integrated into MTAs,
>     it's of secondary value to have them run from Mailman.  There are
>     also already such patches, so I don't think those would really
>     qualify for GSoC by themselves.
>   - The big hole in the current architecture is that there is no way for
>     spam filters in the MTA to get information from Mailman's member
>     lists.  That seems to be the crucial defect at present.
>   
That's a good point for lists which discards all messages from 
non-members. But I think it doesn't affect lists which holds messages 
from nonmembers by default.
> - You should get in touch with Brad Knowles who currently isn't
>   subscribed to this list AFAIK, but is the resident anti-spam guru on
>   Mailman-Users.  He might be a good GSoc mentor if he's willing,
>   although he's not a code jockey AFAIK.
>
> - Peripherally related, but also very important, is work on the
>   backscatter problem.  See the ongoing "before next release: disable
>   backscatter in default installation" thread on this list.  However,
>   Jo Rhett has sketched out what basically is needed.  It's not big
>   enough to qualify for GSoC ;-)  The remaining work, however, is
>   substantial, but may not really be on-topic for GSoC: updating the
>   templates, working with the translators to get the new templates
>   translated, and testing the result.
>   
I read parts of this thread. It's a very long discussion.
Adding configuration options to mailman to disable some of the aliases 
and only answer requests if they seem to contain a command, could be a 
part of my application.
> - (I do not speak for Barry or Mark, but FWIW) As I read Barry's
>   statements, this kind of thing would not be appropriate for 2.1.
> - It is definitely appropriate for 2.2 IMO.  That would need Mark's
>   cooperation, of course.
> - Barry has already started work on 3.0 with the intent of realizing
>   some of the ideas summarized above by allowing callbacks into
>   Mailman to be subscriber info for the use of the MTA, including spam
>   fighting.  Probably the architectures of a 2.2 implementation and a
>   3.0 implementation would be quite different.
>   
I thought of 2.2 too. 2.1 would be nicer because 2.2 and 3.0 seems too 
far away.

I wrote to this list to get some information which spam features are 
acceptable by the mailman developers and to get some more specific ideas.