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

[Patrick Ben Koetter]

* Stephen J. Turnbull <stephen at xemacs.org>:
> Sreyanth writes:
> 
>  > 3. Anti-spam / anti-abuse in Mailman.
> 
> 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.

I concur.

> 1.  Mailman is the wrong place to do filtering.  It's equally
>     effective, normally covers more messages, and is somewhat more
>     efficient in resource usage to do it at the MTA.

Spam-filtering is expensive. It should be done only once - at sender level and
not for each recipient of a mailing list.

We could let Mailman do it when the mail enters, but what would be the gain?
There's plenty of software out there that already knows how to battle spam.

Even worse! In some countries - take Germany for example - you either reject
spam at SMTP session level while the sending client is still there and will
take notice or you MUST deliver it - else you break the law because you took
reponsibility for transport, but supressed the message.

Mailman is part of a mail system, but it I don't expect it will ever become
the component that will communicate directly with a remote (spam sending)
client.

All the work to add an anti-spam feature in Mailman would be 'useless' to
countries with laws as I described above.

BUT ...

I think it would be real nice to have a MILTER interface at LMTP server level
to allow mail modification as required. Mailman runs in large environments and
all the 'large organizations' I have worked asked my team and me to customize
how mail is processed. MILTER is a great interface to modify mail.


> 2.  Any new algorithms *should* be made available at the MTA level
>     where they can be best put to use by more people.  This implies
>     something that either plugs into existing filters (such as
>     spamassassin) or MTAs (ie, milters) rather than a Handler.
> 3.  Adapting existing filters is generally pretty trivial: you write a
>     10-line custom Handler that pipes it to an external process.  This
>     isn't big enough for a GSoC project.
> 4.  To the extent that new algorithms are involved, I have doubts that
>     Mailman mentors have the kind of expertise needed to really help
>     with such a project (I could be wrong, but I certainly don't know
>     much about that kind of text processing, and I don't know that
>     anybody else in Mailman has expertise in it).
> 
> On the other hand, I don't know which project in GSoC would be a
> better place for it.  It's possible to argue that Mailman is a
> reasonable place for it, but IMHO we probably shouldn't.

I hate to stand in the way of someone, who wants to contribute to OSS, but
IMHO we shouldn't either.


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

Has anyone ever mentioned SNMP as a feature for Mailman?

p at rick


-- 
[*] sys4 AG
 
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Joerg Heidrich