[
Lists Home |
Date Index |
Thread Index
]
Jeff,
> This is an example of what NOT to do when you have a question or problem
> with the mailing list server. If you contacted me directly, I would be
> happy to explain to you how bounce handling works within ezmlm in general
> and on xml-dev in particular.
If it was a problem that affects only me, I would have done that. I pointed
out this problem on XML-DEV because:
1. I felt problems like this are relevant to current discussion about the
future of XML-DEV mailing list.
2. Solving the problem requires policy change which should not be made
without proper discussion involving those who are affected by possible
policy changes. No single XML-DEV list subscriber should be able to bring
about such change, no matter how respected or persuasive the arguments are,
without asking other subscribers to comment on the suggested changes. This
includes 'council of elders'.
Allow me to point out that contents of the ezmlm warning I received paints a
different picture of how ezmlm handles delivery errors than your
description.
BOUNCE HANDLING POLICY CHANGE SUGGESTIONS
I would like to suggest that the bounce handling policy be changed in
following way:
1. Collect and maintain per-subscriber delivery reliability measurement and
unsubscribe subscribers whose reliability measurement falls under 50% for
two consecutive months. Inform subscribers of their delivery reliability
once a month or when it falls below unacceptable level. Measurement should
be biased toward recent events.
2. Before unsubscribing, send N number of messages to the address if the
reliability measurement is greater than zero. N is some reasonable number
based on reliability measurement.
3. Minimize or disable deferred delivery. If I don't get a message because
my ISP or some system in route malfunctions, I have nothing to complain
about. I would rather have fast responsive service than a system that
attempts to be perfect.
Best,
Don Park
Docuverse
|
