[Mailman-Developers] anti-spam filter

[Patrick Ben Koetter]

* Mark Sapiro <mark at msapiro.net>:
> On 4/18/2013 1:32 PM, Patrick Ben Koetter wrote:
> > * Terri Oda <terri at zone12.com>:
> >>
> >> I hope that no one was seriously considering that level of
> >> hardcoding.  What we are almost certainly talking about is setting
> >> up a handler (I think Stephen estimated this to be around 10 lines
> >> of code).
> > 
> > And that handler would be - excuse my ignorance I don't program - a Python
> > function to handle a Python program? Could the handler pass a message over to
> > e.g. SpamAssassin (Perl) or openDKIM (c code) or any other non Python program
> > without the need to add any additional (Python) code?
> 
> In 10 lines? Maybe.
> 
> If SpamAssassin is spamd, the Python socket module is part of the
> standard library.
> 
> OpenDKIM includes a milter interface. There are Python milter shims
> available
> 
> Perhaps your point is that this is more than 10 lines of code which is
> probably true, but interfacing to some specific spam filter plugin
> architecture from a Mailman chain rule module does not seem to me to be
> a big project.

My original point was that we should use MILTERs because we shouldn't reinvent
what already has been implemented very well and we shouldn't come up with a
proprietary solution, because that will make it harder to expand Mailman and
also less versatile as a tool.

Let me add this too:

I think we miss out some important customers if we stop at "but you only need
to add code to get what you want".

Mail systems are created and run by postmasters in most cases. Even though
there's a strong movement at the moment towards 'devops', the majority of
sysops/postmasters can't program.

If we stop at a programmable interface - which I understand is what you and
Terri suggest - they will not be able to use Mailman in more complex setups,
because integrating additional mail processing components would require them
to program.

I suggest to go further and add a MILTER because this way all customers
involved - admins and developers - will get what they want/need:

- Admins can check if there's a MILTER <https://www.milter.org/> out there
  that already does what the mail processing chain needs. If there is, they
  connect Mailman and the MILTER via a well know interface (UNIX domain
  socket/TCP socket) and be done. No need to program. Configuration only.
  Most of the tools used in everyday postmastering provide a MILTER interface
  to interact with other mail processing components.

- Developers will have full access (LMTP session data, mail header, mail body)
  to a message via the MILTER protocol. They can create their specialized
  application in any programing language that suits the job. As you said,
  Python brings (about 16) tons of code to get you started easily.

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