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

Barry Warsaw barry at list.org
Fri Apr 12 15:54:21 CEST 2013


On Apr 12, 2013, at 01:44 AM, Stephen J. Turnbull wrote:

>A couple of people have mentioned anti-spam, and it's a frequently
>requested feature.  Nevertheless, I don't think we should spend Google
>money and mentor time on it.

From the core's perspective, I tend to agree that there is some interesting
things we'd like to add here, but it's probably not enough work to justify a
GSoC slot.  I'm not sure if additional ui work can pad that out.

I also agree that in general, we want to encourage sites to push anti-spam
defenses into the MTA as much as possible.  The counter argument is that we
get plenty of requests from folks who have no control over their MTA and want
to be able to configure Mailman to help reduce spam.  I think the following
avenues would be interesting to pursue.

* Assume the MTA is doing filtering, and that messages will fall into three
  categories: known bad (these get dropped at the MTA), known good (these flow
  through), unsure.  For the latter, the message will probably be marked in
  some way, e.g. a header with a spam score, and it would be good if Mailman
  has some facility (e.g. a rule) to parse that header and make disposition
  decisions based on that value.  One thing Mailman can do that the MTA cannot
  is allow for human intervention for disposition.

* Provide an option for messages to detour into spam filters like spamassassin
  during Mailman message processing.  This probably means a rule which calls
  out to SA or equivalent, and stores the score in some metadata.  A rule hit
  might mean that the message has a spam score higher than a threshold, in
  which case processing jumps to a chain which can discard, reject, or hold th
  message.

>Regarding anti-abuse, we would like to do something about problems
>like backscatter.  However, I have to wonder how much *code* (vs
>*specification* and *design*) is needed for those problems.  If the
>project is really spec-heavy, it's probably not really what Google has
>in mind (based on comments on the mentors' list, not on any official
>Google pronouncements, though).

Agreed.

-Barry


More information about the Mailman-Developers mailing list