* Stephen J. Turnbull <step...@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@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 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
