[Mailman-Users] Rewriting or identifying late bounces
cite+mailman-users at incertum.net
Thu Jul 9 13:00:04 CEST 2009
* Brad Knowles <brad at shub-internet.org> wrote:
> on 7/8/09 6:12 PM, Stefan Förster said:
>> Thanks for your advice, Brad. The problem is that, due to policy
>> reasons, outgoing mail has to pass a content filter, running locally
>> on the Mailman box. With VERP...
> Chuq von Rospach wrote some stuff in the FAQ detailing his experience
> with how VERP impacted performance on the systems he was managing. Of
> course, this doesn't necessarily apply directly to your case, but it is
> instructive to read.
To be honest - I never understood where he got his numbers from. Or to
be more precisely, how he got that lucky (note that I obfuscated the listname):
# list_members mylist | cut -d@ -f2 | sort | uniq -c | sort -rn | head -3
# list_members mylist | wc -l
For that list, there would be 5 connections from Mailman to the local
MTA for 2827 recipients, followed by <= 139 connections for the
remainder of the whole list, i.e. no more than 144 delivery attempts.
With VERP, there would be 2966 connections from Mailman to the local
With the content filter set up the way it is, without VERP, the MTA
would create no more than 144*2 queue files and the content filter
would in turn create 144 subdirectories with about 3 files each, for a
total of 720 files and 144 directories created/unlink'd.
VERP'd, I'd have to create/unlink 14830 files and 2966 directories.
And yes, I know that the MTA might create more than one file per
message delivery - I was assuming the "best case". Perhaps I just got
"unlucky" with the recipient distribution for that particular list -
if it is of any importance to the lsit archives, I'd gladly
investigate other lists I'm running. Or perhaps you could provide some
live data from python.org lists?
BTW - will MM3 be able to utilize the VERP features offered by many
>> I guess I will simply move the list server to another computer (and a
>> different network).
> OTOH, moving the mailing list function to a different server and
> separating that from the content scanning system is also a good idea,
> including lots of other reasons.
My main reason to move the whole installation is mainly that in
another network, I don't have to scan every outgoing message. After
all, it's not Mailman's fault that the box is heavily loaded.
> Good luck, and I hope that this works out for you.
Thank you, Brad.
More information about the Mailman-Users