[Mailman-Users] Rewriting or identifying late bounces

[Stefan Förster]

* 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
   1414 gmx.de
   1009 web.de
    404 freenet.de
# list_members mylist | wc -l
2966

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
MTA.

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
modern MTAs?

>> 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.


Cheers
Stefan