* Mark Sapiro <m...@msapiro.net>: > On 4/18/2013 1:32 PM, Patrick Ben Koetter wrote: > > * Terri Oda <te...@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@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