If you do not care about majordomo responses coming from a "single"
domain, and all your lists use the same directory structure, you do
not need multiple majordomo.cf files (but you still need sendmail to
recognize the virtual domains via virtusertable, need -h domain.name
on resend aliases and/or resend_host = domain.name in .config files,
and have to contend with possible naming conflicts with other hosted
domains). Your hosted domains should not have access to the aliases
or majordomo.cf files that you setup for them anyway, so where does
the notion of having someone else execute random perl code come from?
There is a patch that disables -C majordomo.cf files except from a
specific secure directory. Otherwise, any knowledgeable user with
shell access to the majordomo machine can execute perl code on your
server without going through majordomo anyway.
Dan Liston
Alex Aminoff wrote:
>
> I have read the FAQs and searched the archives. I have implemented the
> method of dealing with virtual hosts described there. Each virtual host
> has to have its own majordomo.cf, which is specified with the -C flag in
> the invocation of majordomo (and wrapper, and resend) in the aliases
> file. That majordomo.cf then in turn sets $listdir and a bunch of other
> variables to the correct specific values for each virtual host.
>
> What I would like to do is eliminate the multiple .cf files. It would be
> nice if majordomo could set the relevant variables at run time dependent
> on a command-line option or on parsing the address the message was sent
> to (e.g. whatever-request@virtualdomain.com or
> majordomo@virtualdomain.com) or some other sensible method. This would
> make it more convenient to set up lots of virtual domains, and means
> that the maintainers of the virtual domains can't cause majordomo to
> execute random perl code by putting it in the virtual domain's .cf file.
>
> Has anyone done this? Is there a reason why it would be a bad idea?
>
> Thanks,
>
> - Alex Aminoff
> alex_aminoff@alum.mit.edu
> http://www.basespace.net/~alex/consult/
References:
|
|
