Results from 2.1a2's /mailman/create ... not as expected

I dont know if this was by design or not, but I went to my (not externally accessible) test system at http://www.testdomain.com/mailman/create and created a list "justatest" and got the message tacked on the bottom of this message.
Things that "JustDontLookRight" to me include:
- picked up the server's name, rather than the domain name of the host it was triggered under.
Could it not be set up to take the virtual host underwhich it was triggered (ie, testdomain.com), and use that as the prefered name of the list? The next page that comes up is listed as being under that virtual host -- but all the links point back to the machine's name.
- Required me to use the sitepassword to create a new list...
How can I give that priveledge to someone else (like a virtual host admin)... I've not found any documentation anywhere that describes how to register a valid user under a domain (such that they can only create lists under that domain)
- last line in message didnt have proper replacement of "hostname".
Just a buglet - but I dont know enough python to fix it....
- The email that is produced with the /etc/alias additions... is it possible to define where that goes, say in the mm_cfg.py?
It would be nice to be able to pipe those specific through another email address that triggers a routine that could actually do the append as root...
-----Original Message----- From: justatest-admin@bubba.localdomain [mailto:justatest-admin@bubba.localdomain]On Behalf Of mailman-owner@bubba.localdomain Sent: Saturday, July 28, 2001 10:40 PM To: ----------------------- Subject: Your new mailing list: justatest
The mailing list `justatest' has just been created for you. The following is some basic information about your mailing list.
Your mailing list password is:
justatest
You need this password to configure your mailing list. You also need it to handle administrative requests, such as approving mail if you choose to run a moderated list.
You can configure your mailing list at the following web page:
http://bubba.localdomain/mailman/admin/justatest
The web page for users of your mailing list is:
http://bubba.localdomain/mailman/listinfo/justatest
You can even customize these web pages from the list configuration page. However, you do need to know HTML to be able to do this.
There is also an email-based interface for users (not administrators) of your list; you can get info about using it by sending a message with just the word `help' as subject or in the body, to:
justatest-request@bubba.localdomain
To unsubscribe a user: from the mailing list 'listinfo' web page, click on or enter the user's email address as if you were that user. Where that user would put in their password to unsubscribe, put in your admin password. You can also use your password to change member's options, including digestification, delivery disabling, etc.
Please address all questions to mailman-owner@%(hostname)s.

"SB" == Scott Brown <scott-brown@home.com> writes:
SB> I dont know if this was by design or not, but I went to my
SB> (not externally accessible) test system at
SB> http://www.testdomain.com/mailman/create and created a list
SB> "justatest" and got the message tacked on the bottom of this
SB> message.
SB> Things that "JustDontLookRight" to me include:
SB> - picked up the server's name, rather than the domain name of
SB> the host it was triggered under.
SB> Could it not be set up to take the virtual host underwhich it
SB> was triggered (ie, testdomain.com), and use that as the
SB> prefered name of the list? The next page that comes up is
SB> listed as being under that virtual host -- but all the links
SB> point back to the machine's name.
See the latest cvs. If you add add_virtualhost() calls to your mm_cfg.py file, this should all now work. I think this is what you meant (in private email) about cheap-'n'-easy virtual hosts. The intent is to do everything we can to support virtual hosts in MM2.1, short of eliminating the restriction of unique list names across the entire site. That I'm punting on until after MM2.1.
SB> - Required me to use the sitepassword to create a new list...
SB> How can I give that priveledge to someone else (like a virtual
SB> host admin)... I've not found any documentation anywhere that
SB> describes how to register a valid user under a domain (such
SB> that they can only create lists under that domain)
You should be able to set the "list creator's" password by using the -c option to bin/mmsitepass. This doesn't let you hand out unique list creation privileges per virtual domain, but it does let you delegate those privileges to folks who won't have site admin access.
SB> - last line in message didnt have proper replacement of
SB> "hostname".
SB> Just a buglet - but I dont know enough python to fix it....
Should be fixed now.
SB> - The email that is produced with the /etc/alias
SB> additions... is it possible to define where that goes, say in
SB> the mm_cfg.py?
SB> It would be nice to be able to pipe those specific through
SB> another email address that triggers a routine that could
SB> actually do the append as root...
Currently it's hard coded to the "site owner" address, typically mailman@your.dom.ain, where the LHS is defined by MAILMAN_SITE_LIST and the RHS is defined by mappings in VIRTUAL_HOSTS (configured by add_virtualhost() calls). Don't change MAILMAN_SITE_LIST just to change this behavior; for now hack Mailman/MTA/Manual.py to change the destination address.
-Barry

"SB" == Scott Brown <scott-brown@home.com> writes:
SB> I dont know if this was by design or not, but I went to my
SB> (not externally accessible) test system at
SB> http://www.testdomain.com/mailman/create and created a list
SB> "justatest" and got the message tacked on the bottom of this
SB> message.
SB> Things that "JustDontLookRight" to me include:
SB> - picked up the server's name, rather than the domain name of
SB> the host it was triggered under.
SB> Could it not be set up to take the virtual host underwhich it
SB> was triggered (ie, testdomain.com), and use that as the
SB> prefered name of the list? The next page that comes up is
SB> listed as being under that virtual host -- but all the links
SB> point back to the machine's name.
See the latest cvs. If you add add_virtualhost() calls to your mm_cfg.py file, this should all now work. I think this is what you meant (in private email) about cheap-'n'-easy virtual hosts. The intent is to do everything we can to support virtual hosts in MM2.1, short of eliminating the restriction of unique list names across the entire site. That I'm punting on until after MM2.1.
SB> - Required me to use the sitepassword to create a new list...
SB> How can I give that priveledge to someone else (like a virtual
SB> host admin)... I've not found any documentation anywhere that
SB> describes how to register a valid user under a domain (such
SB> that they can only create lists under that domain)
You should be able to set the "list creator's" password by using the -c option to bin/mmsitepass. This doesn't let you hand out unique list creation privileges per virtual domain, but it does let you delegate those privileges to folks who won't have site admin access.
SB> - last line in message didnt have proper replacement of
SB> "hostname".
SB> Just a buglet - but I dont know enough python to fix it....
Should be fixed now.
SB> - The email that is produced with the /etc/alias
SB> additions... is it possible to define where that goes, say in
SB> the mm_cfg.py?
SB> It would be nice to be able to pipe those specific through
SB> another email address that triggers a routine that could
SB> actually do the append as root...
Currently it's hard coded to the "site owner" address, typically mailman@your.dom.ain, where the LHS is defined by MAILMAN_SITE_LIST and the RHS is defined by mappings in VIRTUAL_HOSTS (configured by add_virtualhost() calls). Don't change MAILMAN_SITE_LIST just to change this behavior; for now hack Mailman/MTA/Manual.py to change the destination address.
-Barry
participants (2)
-
barry@zope.com
-
Scott Brown