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

The List Server Administrator at UNH listadm at metaphor.unh.edu
Fri Mar 19 21:50:24 CET 1999


    A couple of preliminaries:

      o  I'm not sure if a discussion of this nature -- i.e. design 
         philosophy -- is best done here or on the developers' list.
         I worry that end-users may be arguing these fine points but 
         the developers are blissfully unaware of these proceedings.

      o  If you have never read it, check out the "Mailing List Management
         Software FAQ" which you can find at places like:

   http://www.faqs.org/faqs/mail/list-admin/software-faq/
   ftp://ftp.uu.net/usenet/news.answers/mail/list-admin/software-faq

         It contains lots of good information about list servers in
         general and has reviews of what is currently out there.
         Unfortunately I have not found a copy that has been updated
         any later than 1995.

      o  In some respects I feel like I should not get too excited about
         this issue of how you communicate with the server via e-mail,
         given Mailman's web orientation.  But I think it is an issue
         that should be delt with sooner than later with a firm
         understanding as to why various decisions where made.

    Now...

    Thanks for all the replies regarding list aliases and error
    messages.   Here are my thoughts on some of the issues raised.

    Chuck Swiger <chuck at codefab.com> posted (in part):

CS> ListProc uses only one -request address, I think that this is better than
CS> have a lot of -request address (like mailman) all doing (basically) the
CS> same., after all , the list manager is mailman, not the list in question.

    Hmmmm, I think I know what you're saying here, but let's establish
    some definitions.  Looking at some other mailers and what they do
    for addresses we have:

              LISTSERV        ListProc        Majordomo       Smartlist
TO CONTACT   --------------  --------------  --------------  -------------
server        listserv        listproc        majordomo       *-request
list owner    *-request       *-request       ?               ?
delivery err  owner-*         owner-*         ?               ?
all owners    all-request     n/a             ?               ?
site admin    owner-listserv  n/a             ?               ?

    LISTSERV, ListProc, and Majordomo all have the idea of a central
    server address for contacting the server.  Smartlist and Mailman
    seem to instead use the model that there is (what appears to be) a
    server dedicated to each list.  An advantage to having server
    commands go to the *-request address is that by virtue of the fact
    that you are mentioning the list, you have established a context
    within which to interpret commands.  But with Mailman, the only
    thing that will seem to pull everything together, i.e. display a
    set of lists available from the server, will be the web page.  Or
    am I missing something?

    I would rather see the *-request address used for contacting a
    human since that is how it is most widely used.  If the desire is
    to have a model of a `separate server for every list', I would
    recommend using *-server instead.  As it turns out LISTSERV also
    uses this address format as well, and I don't believe it
    contradicts any other existing use for this form of address.

    I had previously posted:

BC> >    [speaking as the user] But know [SIC] I don't know
BC> >    who I should contact or what I should do for help.

    to which Roger Escobio <roger at infomed.sld.cu> posted:

RE> *****-owner at xxxx.xxxx.xxx

    Sure as a list admin -- I know that.  You know that.  But how does
    the *user* know that?  There is nothing in the e-mail message sent
    back that tells the user who to go to for help or make suggestions
    what to do next:

          From mailman-users-request at python.org Fri Mar 19 08:35:04 1999
          Date: Thu, 18 Mar 1999 14:52:25 -0500 (EST)
          From: mailman-users-request at python.org
          To: listadm at metaphor.unh.edu
          Subject: Mailman results for Mailman-Users

          **** Subject line ignored: This is a test...

          >>>> Please excuse this test.
          **** please: Command UNKNOWN.

    The only addresses I see here are my own (listadm) and the list's
    server address (mailman-users-request).  That's it.  There isn't
    even a hint that I could send back a HELP command to the server
    address.  No mention of how to contact a human.  Nothing.

    Here is an extract from a Majordomo response to a similar problem:

          From Majordomo at pop.psu.edu Fri Mar 19 14:44:00 1999
          Date: Fri, 19 Mar 1999 12:23:16 -0500 (EST)
          From: Majordomo at pop.psu.edu
          To: List.Admin at unh.edu
          Subject: Majordomo results

          --

          >>>> get file majordomo-faq
          **** get: unknown list 'file'.
          >>>> 
          **** Help for Majordomo at pop.psu.edu:

         This help message is being sent to you from the Majordomo 
         mailing list management system at Majordomo at pop.psu.edu.

         This is version 1.94.4 of Majordomo.

         If you're familiar with mail servers, an advanced user's 
         summary of Majordomo's commands appears at the end of this 
         message.

         etc.

    I believe it was Roger Escobio who also wrote:

RE> I'm looking one interesting things, how could someone look all the
RE> list running on mailman if he dont subscribe to any of them? sending
RE> e-mail to where??

    This is a good point.  While Mailman seems to be following the
    Smartlist model for aliases, most servers seem to offer a central
    address for contacting the server without the context of any given
    list.  Perhaps it would be trivial to do the same thing with
    Mailman -- but is that indeed part of the current installation
    standard?

    In any case, going back to Chuck's original comment, I tend to
    agree that I like LISTSERV/ListProc model better, where there is a
    single address for the server, and all list addresses are really
    unique for that list.  But I don't know if we're in a position to
    change the current Mailman approach radically given the current
    stage of development.  But it would be nice to have that approach
    and philosophy spelled out.  I think one of the worst things about
    ListProc, reflected by its chaotic command structure, is that grew
    by virtue of creeping featurism.  To me ListProc doesn't look like
    it was designed, it just grew like a weed.

    Bruce <bruce at hams.com> take on the multiple aliases:

B> You can run Mailman with only one -request address, just edit your aliases
B> that way. The -admin address is useful if you have different administrators
B> for different lists.

    We might be getting to an important point -- what type of model is
    Mailman aimed at?  Are we talking about an installation where the
    list server admin is managing all of the lists, or a situation
    where the lists are all `owned' by different (often non-technical)
    people who are managing their own lists.  In our particular case,
    we have over 400 lists on our server, so we are definitely the
    latter.  So you do need a unique address for contacting that
    list's manager.  But in the case of ListProc it is using the
    "*-request" alias for that, and establishes a single address for the
    server itself.

    Clark Evans <clark.evans at manhattanproject.com> wrote regarding the
    idea of having a single address for the server:

CE> How do you do this?  
CE> 
CE> one:  "|/mailman/mail/wrapper mailcmd one"
CE> two:  "|/mailman/mail/wrapper mailcmd two"

    This brings me back to my question of -- does Mailman have a
    central server address, for contacting the server without respect
    to a given list.  I said that I thought establishing such an
    address would be trivial, i.e.:

         mailman: ""|/mailman/mail/wrapper mailcmd mailman"

    Where mailman is a phantom list.  But now we have established a
    list context which may cause problems depending upon the command
    given.  What is needed is a list contextless way of contacting the
    server. 

    Clark also followed up:

CE> On a related topic, with majordomo you can unsubscribe from
CE> all of the lists on a server by sending:
CE> 
CE> "unsubscribe * my-email at my-domain"
CE> 
CE> Can people do this with Mailman?

    Precisely!  ListProc has a similar feature.

    Finally Bruce followed up to Clark's posting:

CE> How do you do this?  (one address for the server)

B> If you are lucky enough to be running qmail, you can use my virtual domain
B> script and run Mailman with _no_aliases_whatsoever_.

    I think this misses the point.  The issue here is the address
    model presented to the end-user, not how this address model is
    implemented. 

    In summary, there doesn't appear to be much standardization on
    this issue of list and server addresses.  From the Norm Aleks
    <naleks at Library.UMMED.EDU> Mailing List Management Software FAQ:

       "A standardized addressing system would be very useful, there's
        no doubt.  Everyone has their own opinion on what the best
        choice would be, and I have mine, but most of all I would like
        to see the MLMs' writers agree on *some* standard.  Just my
        opinion -- but it certainly would help the end users."

    I think there is a lot to be said for following the mostly widely
    used conventions which I believe would be 

            *-request at somewhere.org

    for contacting the list owner. But more important, I think, is the
    establishment of the model Mailman is going to follow, articulate
    that model, and then design the software accordingly.

    Sorry about the length.


                                           Cordially,
                                           The List Server Admin
                                           list.admin at unh.edu
                                           (currently Bill Costa)












More information about the Mailman-Users mailing list