[Mailman-Users] Diagnosing command failures
Barry S. Finkel
bsfinkel at att.net
Thu Jan 22 23:11:40 CET 2015
On 1/22/2015 10:10 AM, Gary Merrill wrote:
> Again, thanks to all of you for your responses. There are a number
of thorny issues in attempting to "fix" (or at least address) what is
"wrong" here. The original conceptual model of something like Mailman
isn't quite right for the situation being faced today in the types of
capabilities and support offered to the "general public". This doesn't
mean that that model was wrong, but that's it's not a thoroughly good
fit for a certain service/support/marketing model employed by others.
Making things "fit" better is a daunting task because of the numbers and
types of players involved, and their varied goals and constraints. Hey,
before I retired, I spent about 13 years developing knowledge
representations and software (server and user) for multiple disparate
medical coding schemes for the purposes of drug discovery and adverse
event detection. I know the kinds of problems you guys are facing --
although you should be somewhat grateful that you aren't dealing with
the FDA, insurance
> companies, gigantic healthcare organizations, the CDC, and
multiple pharma companies. :-) "Don't hold your breath" is a
perfectly apt comment.
> The hosting services companies may want to provide certain services
(or at least their developers and support staffs may). They (meaning
the their developers and support organization) may in fact care, but
they may be severely constrained in what they can do within the economic
model of the company and how effectively they can fight their marketing
organization. The issues here often aren't technical, but economic and
political (in the sense of company politics). Sometimes the good guys
win, and a lot of times they don't. And to some degree you get what you
pay for (if you're lucky and deal with a reputable provider). I'm quite
happy with the service and support that Webhostingpad has provided me (I
have two sites hosted by them).
> Prior to running the Mailman list for this community band, I had --
for a year -- been running a phpBB bulletin board. Of course this is
quite different from Mailman, is more feature-rich, employs a completely
different conceptual model and architecture, and required that I install
and configure it myself. That gave me a lot more control over it than I
have over my Mailman lists that are available through Cpanel. It was a
noble experiment that failed. While the majority of the band really
liked the idea and functionality of forums, there was a contingent that
was highly resistant to using that approach. (These were not always, or
even generally, the elder members, but somewhat oddly tend to be in the
45-55-ish age group.) They didn't like having to go to the site ...
they didn't like having to employ a password to access it ... but they
wanted to be sure that everything was secure and not visible to
outsiders ... the primary people who in fact needed to make postings to
> um on a regular basis "couldn't remember" to do so, etc.
Basically, it was something that a contingent of the organization wasn't
familiar with and just didn't want to learn about -- whatever the
advantages were. It gave me a lot of flexibility and control because
virtually everything concerning its administration was in "my own
space". As in the case with Mailman, I avoided any patches, custom
code, or addition of anything other than the base modules and some
images. I had to abandon it because as a communication mechanism, it
just wasn't working for this group of people. No amount of education or
support would solve the problem.
> I then recalled the experience I'd had with the listservs used by the
National Library of Medicine and thought: That should do the trick for
this group. Their model of online communication is email. It's simple.
Of course, 80% of my organization can't distinguish between a
privately held and maintained mailing list of contacts and a mailing
list managed by something like Mailman -- but it's working out nicely
and they're learning the few important fundamentals over time. By far,
most of them have never changed their default password (everyone
originally was batch-subscribed) or even used their password or felt the
need to. Many of them have probably forgotten that they even have a
>>From my point of view, what would be ideal in managing a Mailman list
would be to have all the relevant data for the list in "my space", and
accessible to me so that on the rare occasions when things don't work I
could at least look for what is causing the problem. Some configurable
level of logging (again with the information kept in "my space") would
be very helpful so that this could be turned on and off as necessary.
Perhaps administrator-configurable/editable error messages would be nice
as well -- and ones not requiring modifying code or central files
governing the entire Mailman instance.
> That is, some enhanced degree of "local list control" would be very
helpful. Currently this seems to be supported only through the ability
to edit "public" HTML and text files (of which there are few) -- so
someone has recognized the utility of local list control, but it's just
never been taken very far. This is all to say that I think much would
be gained by moving the perspective of "the administrator" from a global
perspective to a more list-local perspective in many instances. Perhaps
the upcoming release will include such things; perhaps not. I don't
know your architecture or your constraints, and so I'm not going to
start pitching such ideas at you in the form of change requests.
> Mailman is currently quite nicely satisfying the needs I have, and I
look forward to the next release.
> Gary H. Merrill
> Chatham Design Consultants
> +1 919.271.7259
One quick comment on Mailman support - When I was managing a Mailman
installation on Ubuntu, I was told that I had to install a package.
I looked at the Ubuntu package and compared the source therein with
the SourceForge source. There were many changes, and I could not
determine what they all were. My boss told me that we could install
the Ubuntu package and then get a support contract with Debian/Ubuntu.
I told him that I was more comfortable with the SourceForge source
and the support I got from this list. He allowed me to build a Mailman
package from the SourceForge source, and that is what I did.
I never installed the Debian/Ubuntu Mailman package, so I never had to
talk to the Debian/Ubuntu Mailman support staff.
More information about the Mailman-Users