* Barry Warsaw <ba...@list.org>:
> On Apr 12, 2013, at 08:28 AM, Patrick Ben Koetter wrote:
>
> >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.
>
> Do you mean a hook in Mailman's LMTP server process? I thought about that in
Yes, I mean to hook MILTER capability into Mailman's LMTP server process.
> my previous message but decided not to mention it because it's not clear to me
> how performant Mailman's current smtpd-based (read: async) LMTP server is.
It's not clear to me either, but now that you made me think about it I begin
to ask myself how fast is fast enough and I also ask myself are we dealing
with a bogey (had to look this up. hope it fits) or are trying to address a
reasonable bottleneck. (I've experienced quite a few "problematic" situations
in mail transport which turned out to be more driven by myth and oral history
than by vested knowledge).
I agree we should measure, just in order not to speculate, but let me send
some thoughts ahead before we take out to test performance:
- Input/output ratio on a mailing list system is 1:n. Performance requirements
on the receiving side should be the least to worry about.
- In most usage scenarios that come to my mind companies run an MLM as a
supplement to their 'regular' mail system. Only a minor ratio of mail that
enters the mail system is routed forward to the MLM (here: MM3 LMTP server).
- At the moment (MM2) mail enters Mailman via a script that is called. Scripts
are _a lot_ slower than a server process. My understanding is MM3 will have
an LMTP server process. Any site that switches to MM3 should experience a
performance boost on the receiving side.
It seems to me most people will be off fine. Unfortunately I think "most
people" will not need to use a MILTER, too.
What characterizes the remaining group:
- They run sites dedicated solely to mailing lists.
- They need special filtering (read: MILTER and other methods).
- They split load via clusters.
- They have their own development teams to customize and optimize software as
required
> What I mean is, I'm not sure how much additional work we want the LMTP server
> to do.
How much should it be able to do at all? Do you collect and log statistics at
the moment? Personally I like the "delays=0.04/0.01/0.05/0.1" entry in
Postfix's log. Quote from postconf(5):
The format of the "delays=a/b/c/d" logging is as follows:
· a = time from message arrival to last active queue entry
· b = time from last active queue entry to connection setup
· c = time in connection setup, including DNS, EHLO and STARTTLS
· d = time in message transmission
-- $ man 5 postconf | less +/delay_logging_resolution_limit
> It would be cool if someone did some performance testing of the LMTP
> implementation, and it would be cool if someone tried to add some hooks into
> that server. It might also be interesting to look into alternative
> implementations. Another reason to push for getting Mailman 3 onto Python 3
> would be the ability to leverage Guido's Tulip work for better async IO
> performance.
I'm short on time to do performance testing myself, but I'll forward the
request to my team members since we are doing tests at the moment anyway.
Maybe someone finds time to squeeze LMTP server testing in.
My first idea would be to use either Postfix smtp-source (multi-threaded
SMTP/LMTP test generator) or swaks (Swiss Army Knife for SMTP)
<http://www.jetmore.org/john/code/swaks/> and create a wrapper around it that
produces the load.
> >Has anyone ever mentioned SNMP as a feature for Mailman?
>
> Nope, but that would be interesting too.
We (sys4) will contribute the MIB and monitoring server during development, if
someone takes onto the programming.
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
