Jeffrey Goldberg writes: > For one mailman instance, I will have in > > /usr/local/mailman/vhosts/lists.wilson-pta.org/data/virtual-domains > > # STANZA START: pta-board > # CREATED: Wed Aug 12 17:17:42 2009 > pta-bo...@lists.wilson-pta.org pta-board
> /usr/local/mailman/data/virtual-domain > > # STANZA START: pta-board > # CREATED: Fri Mar 30 14:20:25 2007 > pta-bo...@lists.shepard-families.org pta-board I don't know Postfix well enough to tell you *how* to do it, but note that Mailman doesn't care what the addresses you use are. So the bounce address, which you seem to want to be common (why? aren't the Mailman instances separate?), can be "pta-board-bounces-common" for all the domains and lists, while the confirm addresses can be "pta-board-confirm-shepard-families" and "pta-board-confirm-wilson-pta" respectively. Or they can be "mm1" ... "mm<as-many-as-you-need>" for that matter. ;-) > Anyway, in my set up, it's always going to the first one first (which > is listed earlier in postfix/main.cf) In exim, it is possible to set up multiple routers so that something that is incoming for "lists.shepard-families.org" uses a separate configuration in all ways from "lists.wilson-pta.org". Maybe a similar effect can be achieved with Postfix? > Both these aliases files and both virtual-domains files are generated > by Mailman. So I don't see where I have scope to fix things. I would > like to know how people who have run multiple instances of mailman > have managed to keep lists in different namespaces. By hand, my man, by hand. I second Brad's recommendation to install each instance of Mailman from upstream sources rather than via a package. You should check the patches applied by your distro to see if there any you want, but usually they're not very useful -- mostly they wrench Mailman's configuration into some preconceived scheme, very often at great cost in flexibility. (This is not a bad thing in the context of a distro wanting to provide seamless installation, but it could screw somebody with requirements like yours royally.) Please note that neither the distros nor the Mailman maintainers have a mission to support you (ie, whatever it is that keeps them doing their work, it doesn't apply to your use case). Their focus is on mainstream users, which for most distros is SOHO-type installations and personal workstations, not vhosting, and for Mailman is people running a coherent set of mailing lists themselves. This is a historical thing for Mailman; Barry and Mark have long since signed on to better support for vhosters, but practically speaking that has to come in MM3; it would seriously destabilize MM2. I wouldn't bet on it changing in the distros soon though. So the bottom line is you will have to do much of the config work by hand for the foreseeable future, and on the one hand installing Mailman from upstream source is tiny compared to the rest of the work you do, and on the other makes it much easier for Mailman people who don't know your distro to help. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
