[Mailman-Users] Sending a human message to the LISTNAME-request address.

[Barry A. Warsaw]

Let me try to follow up to this thread.  Apologies if I've missed out
on part of the discussion, and for the random nature of the responses
below.

- I agree that mailman@ ought to be a context-independent way of
  contacting the server.  It's more inline with what Majordomo does,
  which is what I think John modeled Mailman after most closely.

  However mailcmd would have to be fixed so it could handle such
  context-independent messages.

- mailman-owner@, owner-mailman@, and mailman-admin@ should go to a
  human, probably the site administrator.  This is more in line with
  the standard addresses generated for real lists.

- list-request@ goes to the server.  I think it's too late to change
  this default, although if you wanted to, you should be able to
  change the aliases to use a different standard (I haven't tried
  this, so I can't say whether this actually works or not).

- mailcmd should be fixed so that it sends a much more helpful
  response when the message contains errors.  Greg's right that it
  probably isn't a huge amount of work, but given the Web-centric view 
  of Mailman, it's not surprising this hasn't had as much attention as 
  it should.

- I18N has been discussed many times.  Much of the text that a human
  eventually sees is factored out into files, but not all of it.  I'd
  like to make setting up the I18N architecture the big feature for
  the 1.1 release.

- Design questions are probably best discussed on mailman-developers.

- To answer Bill's question about the `admin model' Mailman supports.
  Here at python.org, we have a large number of lists, managed by many 
  independent remote admins.  While this is an important design
  decision, Mailman could do better.  Harald has recently talked about
  some plans for introducing real user objects into Mailman, which
  would allow an admin to manage several lists more easily (it would
  also allow users to manage their multiple subscriptions much more
  easily).  Post 1.0

Hope that catches me up with this thread.  I'll try to add some of
these things to the new Jitterbug database.

-Barry