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

[Mark Sapiro]

Timo Wingender wrote:

>Stephen J. Turnbull schrieb:
>>
>> - 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.


This would be useful. I *might* even be able to mentor this (or even a
larger) part of the project, but I'm not able to commit to that at
this time.


>> - (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.


As far as I'm concerned, nothing should be done in 2.1 at this point.
All development of anything other than bug and security related fixes
going forward should be on the 2.2 or 3.0 branches (I know some
consider backscatter to be a security issue, but that is not the sense
I mean when I say 'security related').

I would like 2.2.0 to be the next release after 2.1.10. I have some
small changes to go into it now, and I think addressing backscatter
should be high on the list. We also thought initially that getting
some GUI improvements would be the primary focus of 2.2, but if that
work (which wasn't being done by me) is not forthcoming soon, I would
consider making 2.2 relatively short lived and deferring the GUI
improvements to a potential 2.3 release.

>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.


My view on spam is that as much as possible, it should be dealt with in
the MTA and Mailman should never see it. I know that this is not
possible in all situations because critera for non-acceptance or
discard of a message may be different for Mailman lists than for other
mail.

I personally have recently started using MailScanner on the server that
I admin. It is actually very flexible in allowing different critera
and rules based on sender or recipient or whatever. The one thing I
don't like is that it interfaces with Postfix (and other MTAs too) in
a way that doesn't allow rejecting the mail at incoming SMTP time. Of
course I don't accept mail for recipients I don't know, and I greylist
everything else, but after that, I have to just store or discard the
mail I don't want to deliver as it's too late to not accept it.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan