I'm currently using Mailman 2.1.4, and currently, there are several problems with Mailman's implementation of virtual hosting:
(a) List names aren't unique across virtual domains, domain1.com cannot have a list called 'test' if domain2.com has a list called 'test'
On a large installation this is a real problem, and the only real way around it is to run multiple installations of Mailman - one for each site. This is pretty impractical if there are many, many virtual domains.
(b) Linked to the above, the problem I've been having is that Mailman has one site password and one list administrators password for *all* virtual domains, (there are no 'domain administrators' who have add/delete privileges for lists *only* for their own domain). If someone knows the list admin password, they can create and delete lists not only for their own site, but on all the other virtual domains as well.
Currently, I'm having to hack Mailman in order to have a separate password for each virtual domain, which still doesn't solve the problem of unique list names.
I love Mailman a whole lot, but I'm having to look at other solutions, mainly because I'm heavily limited on time right now. Are there any plans to improve on the current support for virtual domains anytime soon?
Thanks in advance,
-j
-- -jamie <jamie@silverdream.org> w: http://silverdream.org | p: sms@silverdream.org pgp key @ http://silverdream.org/~jps/pub.key 20:30:01 up 23:57, 5 users, load average: 0.44, 0.21, 0.12
On Tue, 2004-02-10 at 15:51, Jamie Penman-Smithson wrote:
(a) List names aren't unique across virtual domains, domain1.com cannot have a list called 'test' if domain2.com has a list called 'test'
This is true.
(b) Linked to the above, the problem I've been having is that Mailman has one site password and one list administrators password for *all* virtual domains, (there are no 'domain administrators' who have add/delete privileges for lists *only* for their own domain). If someone knows the list admin password, they can create and delete lists not only for their own site, but on all the other virtual domains as well.
You can't create lists with just a list password, but you can with the creator password.
The first one has /some/ support in Mailman but it's very hacky. There's a module called Site.py and an extend.py module per list that provides some hooks for better virtualization. You'll have to hack Python here and unfortunately there aren't any examples. One approach might be to map listnames to directories that are prefixed with the domain's name.
The second is more difficult because the concept of a domain has mostly been wedged into MM2.1 so there's no notion of a separate authentication layer at the domain level.
Yes, this will be fixed in future versions, but not in Mailman 2.1.
-Barry
At 4:04 PM -0500 2004/02/10, Barry Warsaw wrote:
Yes, this will be fixed in future versions, but not in Mailman 2.1.
Mailman 3, or 2.2?
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
Jamie Penman-Smithson <jamie@silverdream.org> wrote:
I'm currently using Mailman 2.1.4, and currently, there are several problems with Mailman's implementation of virtual hosting:
(a) List names aren't unique across virtual domains, domain1.com cannot have a list called 'test' if domain2.com has a list called 'test'
On a large installation this is a real problem, and the only real way around it is to run multiple installations of Mailman - one for each site. This is pretty impractical if there are many, many virtual domains.
I've made a patch which addresses this one. The new lists have both list name and domain included in the _internal_name attribute, like cPanel (but with less bugs). It's really a hack, I didn't touch newlist nor the web interface for creating lists, the creation of aliases files is currently handled outside Mailman, but it works pretty well for now.
Let me know if you're interested.
(b) Linked to the above, the problem I've been having is that Mailman has one site password and one list administrators password for *all* virtual domains, (there are no 'domain administrators' who have add/delete privileges for lists *only* for their own domain). If someone knows the list admin password, they can create and delete lists not only for their own site, but on all the other virtual domains as well.
FWIW, we have a custom web interface for list creation (which dates back to early MM2.0 releases, when Mailman didn't have a web interface to create lists) which is the only place where our customers can create and delete lists by themselves. This application presents the customer only the lists residing on their own domains, and also updates the aliases file for our MTA.
Only the system administrator knows the site password.
Regards, Zoran
participants (4)
-
Barry Warsaw
-
Brad Knowles
-
Jamie Penman-Smithson
-
Zoran Dzelajlija