The mailing list for listmasters using Sympa

[Teunis Peters <address@concealed>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Olivier Salaün - CRU wrote:
> Hi Teunis,
> 
> The way Sympa manages bouncing list members is described here :
> http://www.sympa.org/doc/html/node25.html
> Basically Sympa :
> 
>    1. does automatic management of bouncing users (listmasters / owners
>       just have to tune the system)
>    2. has 2 types of actions : 1) warn the user 2) unsubscribe

I want 2 - to move the user into another list?  (a "do not email list")
(as per my manager's request - not my own idea.  I'd rather just
unsubscribe them)

>    3. these actions are based on a bounce score which algorithm is
>       described in the documentation

Tuned as per - but only so helpful.

>    4. does NOT disable  a bouncing account because if it is disabled we
>       can't find out if it is bouncing anymore. It is a bad way to solve
>       the problem
>    5. uses VERP is a smart way : if configured VERP is used for a
>       percentage of all list members + bouncing users

I solved part of the problem by disabling VERP on the "list of
unavailable email addresses".

I've now got mail in the queue (for three lists) for 2 hours undelivered
- - and have no idea why it hasn't.   This is quite frustrating.

Is there any way to send to multiple lists in parallel?
Is there any way to find out what the system is currently doing?  (or
even abort a task?)

> Concerning your situation :
> 
>    1. Things should get better after a period of time when Sympa has
>       collected sufficient information about bouncing users and has
>       removed some  of them

Not good for a "live" scenerio where this process has made the system
unbelievably slow.    Messages need to be delivered within an hour or
so...  and waiting DAYS is hurting things.


>    2. You can fasten this process by tuning (minimum_bouncing_count,
>       minimum_bouncing_period,default_bounce_level1_rate and
>       default_bounce_level2_rate in sympa.conf)

minimum_bouncing_count is the only one that seemed valuable.   I'm still
making heads or tales out of how the others could apply - or even if
they do.

>    3. The situation you describe (36 hours for 3 messages) makes me
>       think that your MTA tuning is far from perfect. But you didn't
>       mention the # of subscribers and # of bouncing users. As an
>       example our Sympa server delivers a message to 15K subscribers
>       within 378 seconds.

I'm still tuning the MTA but postfix has been good before - and it
handled this load on mailman acceptably and could deliver 100K of
messages in about 15 minutes.   This is why I'm looking at sympa for
configuration.

The first list is 65K users - and after two hours is still delivering.
 Most of my experience is on smaller systems (only a couple of thousand
users). There are several lists - of which the largest is near 200K users.

I'm under a lot of pressure and could lose my job over this.   Mailman
failed with extreme prejudice (several hard crashes on the server +
spamming huge lists of extra messages).   I've now spent two weeks
trying to make this work - after getting everything moved over within
less than a day.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFXK+YbFT/SAfwLKMRAnVfAJ0WiOKrVENJVFp77gozNo5BaabnowCgqOx/
kOxp7w8+xu03LSucNRaqTcg=
=Ydpl
-----END PGP SIGNATURE-----