[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 _______________________________________________ Savane-dev mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/savane-dev
