FAQ
I just installed Mailman and love it! Great work!

However, I have a question about how to make it work better with
VirtualHosts. I am hosting numerous client web sites using Apache
VirtualHosts. I have been able to make it so that my client's web sites can
each bring up the /mailman/listinfo and /mailman/admin pages from their own
domain.

The /mailman/listinfo page only shows the lists that are part of that
domain. Excellent. But the /mailman/admin page shows all of the lists on
the server whether they are for that domain or not (unless the lists are not
publicly displayed). Not so good.

Also, if I send an email to clientlist-request at clientdomain.com with the
command "help", the response email comes back from
clientlist-request at mydomain.com. It also has links and email addresses
throughout the email that point to
http://www.mydomain.com/mailman/listinfo/clientlist and
clientlist-admin at mydomain.com rather than
http://www.clientdomain.com/mailman/listinfo/clientlist and
clientlist-admin at clientdomain.com.

I expect that most of the email-based commands are going have responses that
look like they come from the main server rather than the customer's domain,
but I'm hoping there is a workaround I'm not aware of.

Lastly, when I execute the "newlist" command, the email that gets
automatically sent to the administrator refers to URLs at mydomain.com. I
would love to have a way to have that email refer to URLs at
clientdomain.com.

I'm sure there are all sorts of other little things that could be done to
make Mailman support VirtualHosts better. Are there ways to deal with these
issues? If not, do people think that they are worth adding to the product?

Thanks,

tauren at servlets.net

Search Discussions

  • Harald Meland at Aug 15, 1999 at 11:03 pm
    [Tauren Mills]
    I just installed Mailman and love it! Great work!
    Thanks, glad you like it!
    But the /mailman/admin page shows all of the lists on the server
    whether they are for that domain or not (unless the lists are not
    publicly displayed). Not so good.
    Yup -- the admin CGI script hasn't been made aware of virtual domains
    yet. Doing so would probably be quite easy, but I think the current
    support for virtual domains is a bit shoddy, so I've been putting it
    off...
    Also, if I send an email to clientlist-request at clientdomain.com with
    the command "help", the response email comes back from
    clientlist-request at mydomain.com.
    This can be configured -- see the "Host name this list prefers"
    setting on the general options page.

    However, if you have several lists with the same localpart name in
    different domains (i.e. "foobar at dom1.com" and "foobar at dom2.org"),
    you'll have to assign them different Mailman-internal names.

    I'd like to allow full email addresses as Mailman-internal list names
    to alleviate this. Then, the site admin could maintain some sort of a
    webserver<->maildomain cross reference (available to Mailman), and two
    settings on the general options page would no longer be needed.

    This would increase the need for easy internal renaming of a list, as
    domain changes would essentially be a change in the internal list
    name.

    Opinions, anyone?
    It also has links and email addresses throughout the email that
    point to http://www.mydomain.com/mailman/listinfo/clientlist
    See the "Base URL for Mailman web interface" setting in the general
    options page.
    Lastly, when I execute the "newlist" command, the email that gets
    automatically sent to the administrator refers to URLs at
    mydomain.com. I would love to have a way to have that email refer
    to URLs at clientdomain.com.
    I'm not aware of any easy solution to that problem. Sure, we could
    add another option to the "newlist" script for specifying the list's
    default URL (and another for it's mail domain), but I don't think
    that's a particularly neat solution...
    I'm sure there are all sorts of other little things that could be
    done to make Mailman support VirtualHosts better. Are there ways to
    deal with these issues? If not, do people think that they are worth
    adding to the product?
    I think better support for virtual hosts (or multiple domains, or
    whatever this kind of feature really /should/ be called :) are
    important, so my answer would definitely be yes.
    --
    Harald
  • Tauren Mills at Aug 16, 1999 at 8:05 am
    Hi Harald,

    Thanks for the details!
    Also, if I send an email to clientlist-request at clientdomain.com with
    the command "help", the response email comes back from
    clientlist-request at mydomain.com.
    This can be configured -- see the "Host name this list prefers"
    setting on the general options page.
    It is good to hear that this is already supposed to work, but this is not
    what I have experienced. I have set "Host name this list prefers" and it
    still returns emails with the main domain name in them. Maybe I have
    something configured incorrectly. I'll go poke around some more.
    However, if you have several lists with the same localpart name in
    different domains (i.e. "foobar at dom1.com" and "foobar at dom2.org"),
    you'll have to assign them different Mailman-internal names.
    What do you mean by "different Mailman-internal names"? If you meant that
    the name of a mailing list can look like one thing to the "world", but can
    be a unique name "internal" to Mailman, then I think I understand what you
    mean. See my notes below for more about this.
    I'd like to allow full email addresses as Mailman-internal list names
    to alleviate this. Then, the site admin could maintain some sort of a
    webserver<->maildomain cross reference (available to Mailman), and two
    settings on the general options page would no longer be needed.
    One thing that I have noticed might be a problem is that multiple domains
    might want a mailing list with the same name. For instance, we have this
    mailing list:
    announce at mydomain.com

    We've put this into our aliases file to handle it:
    announce: "|/home/mailman/mail/wrapper post announce"
    announce-admin: "|/home/mailman/mail/wrapper mailowner announce"
    announce-request: "|/home/mailman/mail/wrapper mailcmd announce"
    owner-announce: announce-admin
    announce-owner: announce-admin

    But, if a customer wanted a mailing list with the same name at their own
    domain, I'm not sure what we would do. I guess we could create a list
    called "announce2", and put this in the aliases file:
    announce2: "|/home/mailman/mail/wrapper post announce2"
    announce2-admin: "|/home/mailman/mail/wrapper mailowner announce2"
    announce2-request: "|/home/mailman/mail/wrapper mailcmd announce2"
    owner-announce2: announce2-admin
    announce2-owner: announce2-admin

    We would then put this into the virtusertable file:
    announce at customerdomain.com announce2
    announce-admin at customerdomain.com announce2-admin
    announce-request at customerdomain.com announce2-request
    owner-announce at customerdomain.com owner-announce2
    announce-owner at customerdomain.com announce2-owner

    But the problem is that the emails that get sent from Mailman would still
    say "announce2 at customerdomain.com" all throughout them, instead of
    "announce at customerdomain.com".

    Would your suggested changes solve this problem?
    This would increase the need for easy internal renaming of a list, as
    domain changes would essentially be a change in the internal list
    name.

    Opinions, anyone?
    It also has links and email addresses throughout the email that
    point to http://www.mydomain.com/mailman/listinfo/clientlist
    See the "Base URL for Mailman web interface" setting in the general
    options page.
    Again, the "Base URL" setting is not working for me. I'll experiment with
    this some more.
    Lastly, when I execute the "newlist" command, the email that gets
    automatically sent to the administrator refers to URLs at
    mydomain.com. I would love to have a way to have that email refer
    to URLs at clientdomain.com.
    I'm not aware of any easy solution to that problem. Sure, we could
    add another option to the "newlist" script for specifying the list's
    default URL (and another for it's mail domain), but I don't think
    that's a particularly neat solution...
    We are trying to automate as much of our system as possible. We would love
    to make it so that when a customer orders a mailing list service, it is
    automatically installed and configured. With this in mind, it would really
    make sense for the newlist command to be able to accept a bunch of command
    line parameters instead of stdin.

    Could the newlist command at least include options on the command line for
    the list's default URL and for the mail domain? That way you wouldn't have
    to muck up the stdin questions, but people who wanted more control could
    have it. It would be best if all options could be specified on the command
    line and any required ones that were not specified would be asked via stdin.
    I'm sure there are all sorts of other little things that could be
    done to make Mailman support VirtualHosts better. Are there ways to
    deal with these issues? If not, do people think that they are worth
    adding to the product?
    I think better support for virtual hosts (or multiple domains, or
    whatever this kind of feature really /should/ be called :) are
    important, so my answer would definitely be yes.
    I think that there are many ISPs that would absolutely love a mailing list
    system like Mailman if it had virtual hosting support built right in
    flawlessly (we certainly would!). We've managed to tweak Majordomo a bit so
    that it kind of works. And now we've kind of got Mailman working too. But
    we really would like it to make our lives easier in a virtual hosting
    environment, since that is pretty much all we do all day long.
    --
    Harald
    Thanks again!

    Tauren
    tauren at servlets.net
  • Tomas Fasth at Aug 16, 1999 at 8:58 am
    Tauren, Harald,

    I also have experienced problems with virtual hosting in Mailman. That is, if you try to make it work within a single installation. My solution was to install one instance of Mailman f?r each virtual domain, each with it's own account (userid). It works and it only takes a few extra meg for each domain. I even wrote a script to automate the configuration and installation which I use each time I need to setup a new domain. It's not perfect but it works. Just my two cents.

    Tomas
  • Darren Boyd at Aug 16, 1999 at 4:58 pm

    On Mon, 16 Aug 1999, Tomas Fasth wrote:
    I also have experienced problems with virtual hosting in Mailman. That
    is, if you try to make it work within a single installation. My
    solution was to install one instance of Mailman f?r each virtual
    domain, each with it's own account (userid). It works and it only
    takes a few extra meg for each domain. I even wrote a script to
    automate the configuration and installation which I use each time I
    need to setup a new domain. It's not perfect but it works. Just my two
    cents.
    Aaah, I don't suppose I can have a copy of that script?

    Thanks,
    Darren
  • Deirdre Saoirse at Aug 16, 1999 at 5:37 pm

    On Mon, 16 Aug 1999, Darren Boyd wrote:

    Aaah, I don't suppose I can have a copy of that script?
    I'd like it too! :)

    --
    _Deirdre * http://www.linuxcabal.net * http://www.deirdre.net
    "I must say that I was really happy to see _Linux for Dummies_ -- that's
    when you know you've arrived." -- Linus Torvalds
  • Tomas Fasth at Aug 17, 1999 at 11:28 am
    Sure, I'm happy to share my script. But you have to wait
    until I'm at the home base again (tomorrow). I currently
    have no direct access to our server's inner life.
    Besides, the script is embarressingly simple. What it does
    is to unzip-untar the source, execute configure with some
    settings to allow different userids and home dirs, and
    nothing much else. You still have to setup the mail server
    interface and the web connection, but it's all the same
    procedure as the single instance installation.

    I'll post the script tomorrow. Until then...

    Cheers, Tomas
  • Tomas Fasth at Aug 17, 1999 at 9:55 pm
    Okej, here's the script I use when setting up new virtual list domains.

    A few comments:
    I have collected all our virtual list stuff in /var/virtual/list. Lets
    call it the "base". I have choosen to put the script in subdir "bin".
    Many things are hardcoded. The script is assuming to be executing with
    the "base" as cwd. The gzipped tarball is assumed to be in subdir "pub".
    To avoid numerous pages of output from the 'configure' and 'make'
    commands, a log is created in an existing subdir "log". The script
    require two parameters, <user> and <domain>. The <user> is assumed to
    already exist in the system.
    The script creates a subdir with a name of <domain>. When it has
    finished there will be two subdirs in <domain>. The source tree
    "mailman-1.0" and the installation "mailman". The whole tree is owned by
    <user>.
    'configure' is run with parameter --with-mail-gid=<user>. This works
    with exim but may not work with other MTA implementations.
    Currently, 'configure' insist to figure out by itself the
    DEFAULT_HOST_NAME and DEFAULT_URL defined in Mailman/mm_cfg.py. So for
    now, this has to be done manually.
    The mail aliases has to be defined according to the different
    installation path.
    The same goes for web server configuration. I use Apache <VirtualHost>.
    Note that /mailman in the URL is a requirement for the cookie handling
    to work properly. I found out this the hard way when I tried to optimize
    the URL to "http://my.domain" skipping the /mailman. Without a broken
    handling of cookies you end up entering the same admin password again
    and again.

    If you have any questions, just mail me.
    Oh, by the way, you may not need bash to execute the script. But I
    haven't bothered to test anything else.

    Cheers, Tomas

    -------------- next part --------------
    #!/usr/bin/env bash

    if [ $# -ne 2 ] ; then echo "USAGE: $0 <user> <domain>" ; exit ; fi

    export listuser=$1
    export listdomain=$2
    export virtualbase=$PWD
    export logfile=${virtualbase}/log/$listdomain
    export gzippedtarball=${virtualbase}/pub/mailman-1.0.tgz

    function verbose () {
    echo + $@ >&2
    $@
    }

    function rotate () {
    local head=$1 tail=$2 version=$3 horizon=$4
    if [ $version -lt $horizon ] ; then
    if [ -e $head.$version ] ; then
    rotate $head .$version `expr $version + 1` $horizon
    fi
    if [ -e $head$tail ] ; then
    verbose mv $head$tail $head.$version
    fi
    fi
    }

    rotate $logfile "" 0 10

    umask 2
    verbose mkdir -m a+rx,ug+w $listdomain
    verbose chown $listuser.$listuser $listdomain
    verbose chmod g+ws $listdomain
    verbose cd $listdomain

    su $listuser -- -sx ${gzippedtarball} > $logfile <<-\EOF
    mmdir=mailman
    prefix=`pwd`/$mmdir
    mkdir $mmdir
    chmod a+rx,g+ws $mmdir
    tar zxf $1
    cd mailman-1.0
    export MAILMAN_UID=`id -u` MAILMAN_GID=`id -g`
    ./configure --prefix=$prefix --with-mail-gid=`id -g` 2>&1
    make install 2>&1
    EOF
  • Harald Meland at Aug 17, 1999 at 5:05 pm
    [Tomas Fasth]
    Tauren, Harald,

    I also have experienced problems with virtual hosting in
    Mailman. That is, if you try to make it work within a single
    installation. My solution was to install one instance of Mailman f?r
    each virtual domain, each with it's own account (userid).
    Just a quick note: That would work OK for now, but wouldn't benefit as
    well as it could from the installation-global user database that's
    planned for next generation Mailman...

    Thanks for the tip anyway,
    --
    Harald
  • Tomas Fasth at Aug 19, 1999 at 2:29 pm
    At my site, an installation-global (site-specific) user database will not
    prove useful in most cases. Customers are typically administer their own
    lists of recipients using a tool of their own choice, exporting email
    addresses to mailman when needed. This is an interesting area in it self,
    and an extension to the notion of user (or subscriber) databases. For
    example providing "hooks" in Mailman for externally managed information
    about subscribers.

    Anyway, Mailman is already showing an impressive range of usefulness, and
    better native support for virtual hosting would surely make it excel even
    more.

    All in all, great stuff! Cheers, Tomas

    Harald Meland wrote:
    [Tomas Fasth]
    Tauren, Harald,

    I also have experienced problems with virtual hosting in
    Mailman. That is, if you try to make it work within a single
    installation. My solution was to install one instance of Mailman f?r
    each virtual domain, each with it's own account (userid).
    Just a quick note: That would work OK for now, but wouldn't benefit as
    well as it could from the installation-global user database that's
    planned for next generation Mailman...

    Thanks for the tip anyway,
    --
    Harald

    ------------------------------------------------------
    Mailman-Users maillist - Mailman-Users at python.org
    http://www.python.org/mailman/listinfo/mailman-users
  • Harald Meland at Aug 17, 1999 at 5:03 pm
    [Tauren Mills]
    I have set "Host name this list prefers" and it still returns emails
    with the main domain name in them.
    Strange -- this certainly works fine for me, and I can't see any
    site-global configuration settings that could somehow inhibit changes
    done here. You're sure that it isn't your MTA that's rewriting the
    (header) addresses after Mailman has handed the message over to it?
    However, if you have several lists with the same localpart name in
    different domains (i.e. "foobar at dom1.com" and "foobar at dom2.org"),
    you'll have to assign them different Mailman-internal names.
    What do you mean by "different Mailman-internal names"?
    E.g. the list <mailman-users at python.org> has the Mailman-internal name
    "mailman-users". Thus, if the Mailman installation at python.org
    housed another domain "example.com" that wanted a list
    <mailman-users at example.com>, that list would have to use a different
    Mailman-internal name, e.g. "mailman-users-example.com" -- which would
    result in Mailman-generated messages looking rather messy, with email
    addresses like

    mailman-users-example.com at example.com

    all over them...

    If the Mailman-internal name was equal to the (preferred) email
    address of the list, there wouldn't be these kind of naming
    collisions.
    But the problem is that the emails that get sent from Mailman would still
    say "announce2 at customerdomain.com" all throughout them, instead of
    "announce at customerdomain.com".

    Would your suggested changes solve this problem?
    That is the main motivation for me suggesting it, so yes, I do hope it
    would :)
    Could the newlist command at least include options on the command
    line for the list's default URL and for the mail domain?
    What do others think about this? I'd really rather solve this once
    and for all with my proposed email-addr-as-internal-name and
    maildomain->base_URL scheme... but if no one but me think that that's
    the way to go, I probably won't bother :)

    Besides, I'm kind of swamped with real work right now :(
    --
    Harald
  • Tauren Mills at Aug 17, 1999 at 6:20 pm
    Harald,
    I have set "Host name this list prefers" and it still returns emails
    with the main domain name in them.
    Strange -- this certainly works fine for me, and I can't see any
    site-global configuration settings that could somehow inhibit changes
    done here. You're sure that it isn't your MTA that's rewriting the
    (header) addresses after Mailman has handed the message over to it?
    I haven't had a chance to look into this more. I'll let you know what I
    find. Thanks for the suggestion.
    If the Mailman-internal name was equal to the (preferred) email
    address of the list, there wouldn't be these kind of naming
    collisions.
    OK. That is the same problem I was describing. Glad to hear we are talking
    about the same thing.
    Could the newlist command at least include options on the command
    line for the list's default URL and for the mail domain?
    What do others think about this? I'd really rather solve this once
    and for all with my proposed email-addr-as-internal-name and
    maildomain->base_URL scheme... but if no one but me think that that's
    the way to go, I probably won't bother :)
    If the newlist command asked for the maillist name, but expected a fully
    qualified email address, then I would certainly be satisfied. But I would
    still like to be able to run newlist by specifying all of the options on the
    command line so that automating list creation is a little easier.
    Besides, I'm kind of swamped with real work right now :(
    I hear ya!

    It was suggested on this list that we install a separate installation of
    Mailman for each domain. This would work and would solve the virtualhost
    problem. But it seems like you are already very close to having virtual
    hosting support built into a single installation. I think I'd rather try to
    hold off until you can add these features. Can you comment on when we might
    expect them? Where are these virtual hosting features being placed on your
    priority list? Are there a bunch of other items that need to be taken care
    of before you tackle virtual hosting support?

    Thanks again for your help!

    Tauren
  • Ron Jarrell at Aug 17, 1999 at 6:25 pm
    This bites people a lot, and should probably be in the faq; hell, I've been doing
    dns and sendmail for *years* and *I* periodically forget it's going to happen.

    If you're planning on sending mail *from* a host, make sure it's a real
    host entry, not an alias. In DNS terms, verify that it's an A record
    pointing at the same ip address as the main host (perfectly valid to
    do); do *not* put in a CNAME pointing at it. Unless someone has
    specifically configured sendmail to be set to nocanonify, mail from
    cnames will be re-written into the canonical name (that's what cname
    stands for), which is not the virtual hostname. This is also done by
    the *receiving* end, so there's nothing you can change on your side,
    it must be done in DNS. This is a stupid default, but was the default
    before virtual hosting really caught on.

    Most sites that just web virtual host use cnames; add email into the picture
    and suddenly nothing works like you expect.

    At 07:03 PM 8/17/99 +0200, Harald Meland wrote:
    [Tauren Mills]
    I have set "Host name this list prefers" and it still returns emails
    with the main domain name in them.
    Strange -- this certainly works fine for me, and I can't see any
    site-global configuration settings that could somehow inhibit changes
    done here. You're sure that it isn't your MTA that's rewriting the
    (header) addresses after Mailman has handed the message over to it?
    However, if you have several lists with the same localpart name in
    different domains (i.e. "foobar at dom1.com" and "foobar at dom2.org"),
    you'll have to assign them different Mailman-internal names.
    What do you mean by "different Mailman-internal names"?
    E.g. the list <mailman-users at python.org> has the Mailman-internal name
    "mailman-users". Thus, if the Mailman installation at python.org
    housed another domain "example.com" that wanted a list
    <mailman-users at example.com>, that list would have to use a different
    Mailman-internal name, e.g. "mailman-users-example.com" -- which would
    result in Mailman-generated messages looking rather messy, with email
    addresses like

    mailman-users-example.com at example.com

    all over them...

    If the Mailman-internal name was equal to the (preferred) email
    address of the list, there wouldn't be these kind of naming
    collisions.
    But the problem is that the emails that get sent from Mailman would still
    say "announce2 at customerdomain.com" all throughout them, instead of
    "announce at customerdomain.com".

    Would your suggested changes solve this problem?
    That is the main motivation for me suggesting it, so yes, I do hope it
    would :)
    Could the newlist command at least include options on the command
    line for the list's default URL and for the mail domain?
    What do others think about this? I'd really rather solve this once
    and for all with my proposed email-addr-as-internal-name and
    maildomain->base_URL scheme... but if no one but me think that that's
    the way to go, I probably won't bother :)

    Besides, I'm kind of swamped with real work right now :(
    --
    Harald

    _______________________________________________
    Mailman-Developers maillist - Mailman-Developers at python.org
    http://www.python.org/mailman/listinfo/mailman-developers
  • Tomas Fasth at Aug 17, 1999 at 9:05 pm

    Ron Jarrell wrote:

    Most sites that just web virtual host use cnames; add email into the picture
    and suddenly nothing works like you expect.
    I got a recommendation long ago about using A records, not CNAME. I have since then
    followed that recommendation, but long since forgot why. Thanks for reminding me
    (us).

    Cheers, Tomas

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedAug 14, '99 at 9:39a
activeAug 19, '99 at 2:29p
posts14
users6
websitelist.org

People

Translate

site design / logo © 2022 Grokbase