> Problem:  Selecting the privacy option to "Hide the sender of a message,
> replacing it with the list address" is ignored by mailman.  The sender is
> still listed in the From field.  And frankly, if mailman can't do this, then
> it is a fancy way to manage mail aliases.  

What version of mailman are you using?  And did you mean From_, or From:?
At any rate, I wasn't able to reproduce this (mailman faithfully replaced
all of my headers (except for the initial Received: header identifying
me)...  

> Also, mailman can't allow apache to implement one security feature in the
> httpd.conf recommended by apache, namely:
> <Directory />
>    Order deny,allow
>    Deny from all
> </Directory>
> 
> Apparently mailman needs to configure the server to allow directory listings
> in order to work.  Is this really neccesary?

I'm not sure what you mean here; I have it working perfectly with that
directive, followed by

   <Directory $prefix/cgi-bin/>
      Options SymLinksIfOwnerMatch ExecCGI
   </Directory>

You need to allow access to the CGI scripts for the Web interface to
work, but that's it (replace $prefix with your installation directory).

> Also, the INSTALL document needs to mention about setting of allow/deny
> options of apache.  For instance, a corporate server might deny everyone
> except the corp.   For instance, I deny anything which is not .gov or .mil
> from seeing the web site, EXCEPT for the machines of people on the list.
> So, if you set up apache to be restrictive, you need to modify apache to
> allow people in the list to subscribe.  You may want to put an option in
> there somewhere for mailman to generate a perl script to be run by root
> which will modify the httpd.conf to allow individual machines to have access
> to the web site as part of an approved subscription.  You may ask how "how
> in the devil am I going to locate a DHCP machine behind a firewall?"  The
> answer is not simple, but, it works - cookies.  Couple a public web server
> on the other URL from which they receive a cookie.  Allow access
> conditionally on domain/cookie in apache /* which involves rewriting apache
> :(  */  and you're there.  Otherwise, it's back to manual editing, which I
> don't mind in this case because my list is small.   However, why did Larry
> create perl?

I'm not one of the Mailman developers, so I can't speak for them or the
documentation.  But I would guess that if someone were to write up all of 
this info in a concise, easy-to-follow relevant form that they would include
it.  

Remember, this ain't Microsoft; they'll share the code/documentation
and accept any changes in return.  :)

But you have to draw the line somewhere...  Are instructions also going to 
be included for setting it up under Netscape's servers?  Or what about 
the old NCSA server?  The situation that you outline above is just a 
specific case of more general situations that are probably better 
documented elsewhere.  I'm working on matching Kerberos principals
to mailing list subscriptions for authentication to a Kerberized 
SSL server (and eventually AFS Web secure) for the MHonArc archives
that we use with mailman.  It's an interesting problem, but it probably
only applies to the tiniest fraction of Mailman users, and as such 
would only confuse those struggling through a simple install.

I personally feel that if it had a place, it would be as a link from the
online FAQ or in a file called 'Advanced' or somesuch.

Chris