[Mailman-Users] Diagnosing command failures

[Gary Merrill]

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 the forum 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 password.

>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


> -----Original Message-----
> From: Stephen J. Turnbull [mailto:stephen at xemacs.org]
> Sent: Thursday, January 22, 2015 5:44 AM
> To: Peter Shute
> Cc: 'ghmerrill at chathamdesign.com'; 'Mark Sapiro'; Mailman Users
> Subject: Re: [Mailman-Users] Diagnosing command failures
> 
> Peter Shute writes:
> 
>  > A lot of people use the cPanel version and can't do anything  > complicated for
> support. Even though this particular case is about  > trying to help a difficult user to do
> something that's normally  > straightforward that's probably pointless anyway, I hope
> v3 at  > least gives cPanel users access to more diagnostics than v2 does.
> 
> Don't hold your breath.  The problem is hosting services (and to some extent cPanel
> itself), not Mailman.  If they wanted to provide the kind of service you want, they
> could ask us for help and we'd give it to them.  (Eg, it probably wouldn't be too hard to
> grep for specific vhosts in the logs, and so minimize the probability of cross-vhost
> personal information leakage.  Of course, if they wanted to do that they probably
> already can.  Evidently they don't care. :-( )  But if we added an option to (say) display
> the "smtp" log (or a hypothetical "auth" log for the current thread) the first thing they'd
> do is disable it in Defaults.py for the cPanel version since it would be too likely to leak
> personal data across virtual domains.
> 
> We do have some work (courtesy Andrew Stuart) ongoing to improve authentication
> for access to core databases in Mailman 3.  I don't know exactly what that work is at
> the momemnt, but it might be possible to leverage it so that subscribers and/or list
> owners could use Mozilla Persona or OAuth2 to access the information they're
> authorized for.  (Postorius already requires, or soon will require, Persona for
> authorization IIRC.)  At least then you can pass the buck for authn/authz issues to
> Google or Mozilla. ;-)
> 
> If you have *specific* diagnostics that don't violate the hosting services' senses of
> propriety (and I suppose they normally won't be problematic), please, *please*,
> PLEASE *ask* for them by name (a brief description is fine, too, of course).  "More
> diagnostics" is not a requirement we can use to specify and design new features.
> 
> Preferably a bug report to Launchpad, tagged "mailman3", but a post to the list or a
> request on IRC would probably be picked up, too.