Sophie

Sophie

distrib > Mandriva > 10.0 > i586 > media > updates > by-pkgid > 5db5b94fc31c810a6866b8dd191bebc4 > files > 1649

mailman-2.1.4-2.3.100mdk.i586.rpm

Mailman - The GNU Mailing List Management System
Copyright (C) 2001-2003 by the Free Software Foundation, Inc.
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA


GENERAL SETUP INFORMATION

    Mailman should work pretty much out of the box with a standard
    Postfix installation.  As of this writing I've tested it with
    Postfix 19991231 up to pl13, 200010228 up to pl08, and up to
    Postfix 2.0.15.

    By default, Postfix treats -owner and -request addresses
    specially.  Since we want Postfix to deliver such messages to
    Mailman, you should turn off this option by adding this to your
    main.cf file:

        owner_request_special = no

    In order to support Mailman's optional VERP delivery, you will
    want to disable luser_relay (the default) and you will want to set
    recipient_delimiter for extended address semantics.  You should
    comment out any luser_relay value in your main.cf and just go with
    the defaults.  Also, add this to your main.cf file:

        recipient_delimiter = +

    Using + as the delimiter works well with the default values for
    VERP_FORMAT and VERP_REGEXP in Defaults.py.

    When attempting to deliver a message to a non-existent local
    address, Postfix may return a 450 error code.  Since this is a
    non-transient error code, Mailman will continue to attempt to
    delivery the message for DELIVERY_RETRY_PERIOD (5 days by
    default).  You might want to set Postfix up so that it returns
    permanent error codes for non-existent local users by adding the
    following to your main.cf file:

        unknown_local_recipient_reject_code = 550

    Finally, if you are using Postfix-style virtual domains, read the
    section on virtual domain support below.


INTEGRATING POSTFIX AND MAILMAN

    You can integrate Postfix and Mailman such that when new lists are
    created, or lists are removed, Postfix's alias database will be
    automatically updated.  The following are the steps you need to
    take to make this work.

    In the description below, we assume that you've installed Mailman
    in the default location, i.e. /usr/local/mailman.  If that's not
    the case, adjust the instructions according to your use of
    configure's --prefix and --with-var-prefix options.

    - If you are using virtual domains and you want Mailman to honor
      your virtual domains, read the section below first!

    - Add this to the bottom of the $prefix/Mailman/mm_cfg.py file:

      MTA = 'Postfix'

      The MTA variable names a module in Mailman/MTA which contains the
      MTA-specific functions to be executed when a list is created or
      removed.

    - Look at the Defaults.py file for the variables POSTFIX_ALIAS_CMD
      and POSTFIX_MAP_CMD command.  Make sure these point to your
      postalias and postmap programs respectively.  Remember that if
      you need to make changes, do it in mm_cfg.py.

    - Run the genaliases script to initialize your aliases file.

      % cd /usr/local/mailman
      % bin/genaliases

      Make sure that the owner of the data/aliases and data/aliases.db
      file is `mailman' and that the group owner for those files is
      `mailman'.  E.g.:

      % su
      % chown mailman:mailman data/aliases*

    - Hack your Postfix's main.cf file to include the following path
      in your alias_maps variable:

          /usr/local/mailman/data/aliases

      (no trailing .db).  Do not include this in your alias_database
      variable.  This is because you do not want Postfix's newaliases
      command to modify Mailman's aliases.db file, but you do want
      Postfix to consult aliases.db when looking for local addresses.

      You probably want to use a hash: style database for this entry.
      Here's an example:

      alias_maps = hash:/etc/postfix/aliases,
          hash:/usr/local/mailman/data/aliases

    - When you configure Mailman, use the --with-mail-gid=mailman
      switch (actually, this will be the default if you configured
      Mailman after adding the `mailman' owner).  Because the owner of
      the aliases.db file is `mailman', Postfix will execute Mailman's
      wrapper program as uid and gid mailman.

    That's it!  One caveat: when you add or remove a list, the
    aliases.db file will updated, but it will not automatically run
    "postfix reload".  This is because you need to be root to run this
    and suid-root scripts are not secure.  The only effect of this is
    that it will take about a minute for Postfix to notice the change
    to the aliases.db file and update its tables.  I consider this a
    minor inconvenience.


VIRTUAL DOMAINS

    Postfix 2.0 supports "virtual alias domains", essentially what
    used to be called Postfix-style virtual domains in earlier Postfix
    versions.  To make virtual alias domains work with Mailman, you
    need to do some setup in both Postfix and Mailman.  Mailman will
    write all virtual alias mappings to a file called, by default,
    /usr/local/mailman/data/virtual-mailman.  It will also use postmap
    to create the virtual-mailman.db file that Postfix will actually
    use.

    First, you need to set up the Postfix virtual alias domains as
    described in the Postfix documentation (see Postfix's virtual(5)
    manpage).  Note that it's your responsibility to include the
    "virtual-alias.domain anything" line as described manpage; Mailman
    will not include this line in virtual-mailman.  I highly encourage
    you to make sure your virtual alias domains are working properly
    before integrating with Mailman.

    Next, add a path to Postfix's virtual_alias_maps variable,
    pointing to the virtual-mailman file, e.g.:

    virtual_alias_maps = <your normal virtual alias files>,
        hash:/usr/local/mailman/data/virtual-mailman

    assuming you've installed Mailman in the default location.  If
    you're using an older version of Postfix which doesn't have the
    virtual_alias_maps variable, use the virtual_maps variable
    instead.

    Next, in your mm_cfg.py file, you will want to set the variable
    POSTFIX_STYLE_VIRTUAL_DOMAINS to the list of virtual domains that
    Mailman should update.  This may not be all of the virtual alias
    domains that your Postfix installation supports!  The values in
    this list will be matched against the host_name attribute of
    mailing lists objects, and must be an exact match.

    Here's an example:

    Let's say I've set up Postfix to handle the virtual domains
    dom1.ain, dom2.ain, and dom3.ain.  Let's say further that in
    main.cf you've got the following settings:

        myhostname = mail.dom1.ain
        mydomain = dom1.ain
        mydestination = $myhostname, localhost.$mydomain
        virtual_alias_maps =
            hash:/some/path/to/virtual-dom1,
            hash:/some/path/to/virtual-dom2,
            hash:/some/path/to/virtual-dom2

    Let's say further that in virtual-dom1, you've got the following
    lines:

        dom1.ain  IGNORE
        @dom1.ain @mail.dom1.ain

    This tells Postfix to deliver anything addressed to dom1.ain to
    the same mailbox at mail.dom1.com, its default destination.

    In this case you would not include dom1.ain in
    POSTFIX_STYLE_VIRTUAL_DOMAINS because otherwise Mailman will write
    entries for mailing lists in the dom1.ain domain as

        mylist@dom1.ain         mylist
        mylist-request@dom1.ain mylist-request
        # and so on...

    The more specific entries trump your more general entries, thus
    breaking the delivery of any dom1.ain mailing list.

    However, you would include dom2.ain and dom3.ain in mm_cfg.py:

        POSTFIX_STYLE_VIRTUAL_DOMAINS = ['dom2.ain', 'dom3.ain']

    Now, any list that Mailman creates in either of those two domains,
    will have the correct entries written to
    /usr/local/mailman/data/virtual-mailman

    As above with the data/aliases* files, you want to make sure that
    both data/virtual-mailman and data/virtual-mailman.db are user and
    group owned by the `mailman' user/group.  So to get things
    started, set up your virtual domains, run bin/genaliases, and
    check the ownerships of the files.  From here on out, you should
    be good to go.


AN ALTERNATIVE APPROACH

    Fil <fil@rezo.net> has an alternative approach based on virtual
    maps and regular expressions, as described at:

    (French)  http://listes.rezo.net/comment.php
    (English) http://listes.rezo.net/how.php

    This is a good (and simpler) alternative if you don't mind
    exposing an additional hostname in the domain part of the
    addresses people will use to contact your list.  I.e. if people
    should use mylist@lists.dom.ain instead of mylist@dom.ain.

    I have not extensively tested this approach however.



Local Variables:
mode: text
indent-tabs-mode: nil
End: