LISTSERV was designed to be a high-end mailing list system offering a lot of flexibility. Solutions that do not work in the general case are not allowed in the product. Of course, there is a downside. A tool that only does one thing in one particular case is always simpler to use than a generic tool that can do many things in many different situations. > The probes are a > list-issue and a list simply probes every user, so multiple lists send > multiple probes to a given user. Other products like mailman put the > user first and probe the user just once. That's much more convenient > from an end-user-point of view. This is true if you can make the assumption that all the list owners want to use active probing with a period of one month and with the exact same probe text. In a typical university, or large company, or service bureau, there are dozens or even hundreds of list owners, who each like to run their list a different way. The probe text that the Sales department wants to use is totally unacceptable to the Investor Relations department. The only solution is then for each group of like-minded list owners to run their separate copy of the software, which means higher manpower costs. When someone leaves the company one day and the new guy does not agree with the rest of the group he is working with, a new instance needs to be installed just for him. Personally, I think active probing is obsolete anyway. There are cases where it makes sense, but they are very few. I don't use it on any of my lists. > One more example for lists first, users second: if internationalization > is needed, every list-owner can provide his list-templates in a language > of his/her choice. Imagine a user subscribed to a German, an English and > a French mailinglist, who wants to change one of his/her options for > each list. The user will see a German, an English and a French > interface, depending on the list (...) if it was a > mailman-installation, the user might choose his/her preferred language > and have the same interface for each mailinglist. To the end-user, > that's much more convenient. This again works fine on the assumption that list owners do not customize the web interface. Otherwise, you will only have chaos. The user, having selected for instance German as his preferred language, will see a random mix of French and German when accessing the French list. The pages or fragments of pages customized by the French list owners will (I would assume) be in French, and the default system pages would be in German. Of course, this problem could be solved if the French list owner would provide a German version of his customizations (and one for every other supported language). But what is the motivation for the French list owner to do this, even assuming that he also speaks German? In the end, you need to use the tool that works best for you. If you can assume that all the list owners are in agreement about the text of templates and the probing method and message text and so on, perhaps something simpler than LISTSERV will save you time and money. If at the other end of the scale you are running a list hosting service, you need to look for a product where most decisions can be made separately for every list. Eric