[Savannah-hackers] Re: Spam in CVS notifications

[Sylvain Beucler]

[This message is also directed to the Savannah hackers and Savane-dev]

[We set up a Mailman filter to get rid of any mail sent to a CVS
notification list, and not sent via lists.gnu.org. It matches a
Received: line in the header. More info in Hacking Savannah]

> Thanks for setting this up.
> 
> Assuming it works, I think you should convert all Savannah diffs
> notification lists to work this way.  To leave it up to the many
> different administrators of many such lists is not efficient.
> Also, in the future, anyone who creates a list for diffs of any project
> should by set it up initially with this kind of filtering.
> If you have a script to set up such a list, the script should
> set up this kind of filtering.
> 
> In the long run, this will get the job done with the least human attention.

Hmmm, that needs to be given some thoughs.

We currently have no way to determine whether a list is used for
notifications only, or partly for notifications and parly for
discussions. At the moment, it is up to the users to determine their
mailing list usage - and hence, their filtering policies. I don't
think we have that much notification mailing lists in place, so maybe
we can browse each mailing list archives to see how it is used. Then
we can send mail to the administrators telling them we added a filter,
and how they can remove it if they want.

Regarding the mailing list creation script, we should be able to
create a specific one. However, we have to keep that in mind when we
have the mailing list created automatically through Savane. We'll
certainly have to:

- provide the user a way to enable CVS notification, create the
  mailing list(s) and add the filter all in a row. That's a special
  kind of list creation. There's still the need for the CVSROOT
  management interface.

- use some new flag in the database to tell sv_mailman that we want
  the filter to be added at list creation time;

- customize the filter according to the Savane installation, since it
  contains the mailing host to match.

Another way is to create the mailing list at project creation time (I
think that's what Gna! does), but that prevents people from setting up
other notification mailing lists later on.

Yet another variant is to make the commit notifier application produce
a special header to be matched; that removes the need to specify the
mailing host, but that may make the Savane installer guy modify that
application.

Of course, nothing is 100% spam-safe, since spammers could add fake
Received: or log_accum headers, but in practice it should work well.

Maybe also there is a solution that only involves the mail system
configuration, in which case there would be no need to modify Savane.

Any comments?

-- 
Sylvain