[Mailman-Users] query re "message has implicit destination"(devils advocate!)

[Bretton Vine]

Brad Knowles said the following on 2006/09/01 01:24 AM:
> This is the key point that was not coming across to me, at least not
> until much later in the exchange.  Speaking only for myself, I seriously
> misunderstood what you were asking and why, which greatly colored my
> responses.

My apologies, I could have been clearer. I did try and fork the thread with
the inclusion of (devils advocate!) in the subject line.

> I'm still not certain that we've given you the best answer to this
> question, but I'm hoping that you'll be able to synthesize something
> that you will then be able to contribute back to the community, and we
> will hopefully be able to avoid these kinds of problems in the future --
> at least with respect to this one particular issue.

I may not have what I was looking specifically, but I do have a clearer of
how to approach things in future.

I've had to edit context significantly for various reasons (brevity being
one) but it comes down this. We've had a solution in place for 10 years that
just works but doesn't offer us the functionality we need or clients want
any more. I've been on mailman run lists for ~6 years and found the setup to
be more useful and when the time came for a new server had to make a number
of decisions based on skills available, difference in volumes of legitimate
mail and spam today (compared to setup of ageing server from 96) and new
things to be learnt using a different OS and architecture.

A mistake appears to be the perception (prior to installation and initial
use phase) that Mailman was Majordomo with a web-gui and archives. It's not.
It's a different product and approach entirely. This realisation is hammered
home in the implementation of Mailman -- but not easily visible when
researching alternative solutions to the previous way we did things.

Such a mistaken perception is echoed both up to management and down to users
in selling the solution. You get approval, go ahead and implement and then
there this "oops" moment and realisation you didn't have all the knowledge
to begin with, and sold management and users a solution you just couldn't
(at the time) anticipate certain problems with. So it's your head on the
block and you either have to wing it or come up with an explanation that
satisfies both users and management without too much trouble in the process.

Just as an example, some list-owners have pending administrative request
queues numbering in the hundreds already. No amount of prodding or pushing
or assisting helps them just to complete a small and easy daily task.
Feedback is "my prior list didn't bother me with stuff" or "Oh, I used to
just ignore that stuff anyway". Horse --> water situation.

Additionally in terms of the historical setup, things with majordomo were
already highly customised to our needs, and when I came in I
assumed/took-for-granted this was the default (old system has even worse
documentation than anything else I've seen <chuckles>) and also assumed
thing would be echoed in the Mailman setup. My mistake, but during the "ask
around for suggestions" phase most of the feedback I got was Mailman
orientated, like the move is just a casual change in clothes. It's not :-)

Now despite my mixed positive/negative reactions to documentation and
feedback from the list, and growing growing appreciation of why certain
things were done a certain way, neither users or management have the time to
sift through the same volume of information to reach a satisfactory
conclusion. Instead you get a very offensive response due to resistance to
change, or new variables.

You see the following doesn't cut it in that situation:

 * but we can change it
 * we can modify the source if we need to
 * that's the way the developers chose to do it
 * the documentation was lacking

In an environment where someone has to take responsibility for a situation,
even if it's not their fault as such, providing the best answer to users or
management can go two ways. Shift the blame, or fix the problem -- even if
it means undoing the best practices suggested and letting users/management
realise for themselves why it's a bad idea. But in some environments you
just can't afford to do this.

So far I've discovered that yes, most of the safe defaults are the best
desired functionality. And that on a Debian/Exim setup it's best to install
from source, and if using virtual domains to install a separate installation
of mailman per domain. The additional overhead on the box isn't that much
for ~20 domains. It might be for more than that though. I've also found the
documentation to be scattered but where there is info that can be
referenced, it's generally pretty good.

Once we have a stable system that meets the needs of users and management
I'll be happy to share the setup of how we've done it in our particular way
along with some rationale behind the different decisions based both on what
I've learnt on this list, and from user/management feedback.

Obviously every installation is in a different environment, and as has been
mentioned Mailman isn't a one-stop-solution-for-all-situations solution.
There is also a lot of public misconception about Mailman in general --
things you only realise when you're actually implementing it on a box or run
into trouble. I doubt anyone is to blame for this -- there are simply too
many variables involved.

I'd suggest to anyone looking at Mailman as a solution search the
docs/FAQ/list-archives, *and* join the list and ask a few questions before
actually implementing. It's a lot easier to anticipate certain things that
way. :-)

-- 
| Bretton Vine | 083 633 8475 | bretton at hivemind.net |
| GPG: http://bretton.hivemind.net/bretton_vine.asc  |

"Gods are fragile things; they may be killed by a whiff of science or a dose
of common sense." - Chapman Cohen