FAQ

On Wed, 30 Mar 2011, Mark Sapiro wrote:
Lucio Chiappetti wrote:
(QUESTION 5)
The arrangement on the target system will be more complicated.
because our aliases are mantained on the NIS master server. The master and
slave servers are also the domain main and backup MX.

However the web server is on a third machine. A configuration like the one
I use on my test machine (local sendmail aliases inherited from local
mailman aliases, which "pipe" into local mailman executables) is likely
to work there ...
I don't think I actually understand the configuration or what the
problem is.

Ultimately, mail to a list must be delivered to the Mailman machine,
but I don't understand why the existing MXs can't relay it there or
can they?
So far not unless explicitly aliased.
This is how I see it (and how our other things work currently).

- all our e-mail are of the form user at domain
NOT user at host.domain

- all outgoing mail is masqueraded as user at domain by sendmail

- the DNS advertises two MX's for the domain. We do not advertise MX's for
particular hosts. Hosts other than MX's should have the SMTP port
blocked by a firewall on the boundary router (we are several institutes
in the same building, the boundary router is not managed by ours).

- incoming mail of the form user at domain is delivered to other hosts
via alias expansion managed by NIS. So some users get it delivered
to user at personalhost, some other to user at projectimapserver.

- our current mailing lists (e.g. staff at domain) are managed by :include:
in the NIS aliases source, pointing to list of addresses in include
files. The expansion works because all local hosts (including the MX's)
can access (via NFS) the included files. We do manage both "system"
lists (include file in a system directory) and "project" lists (include
file in an user directory)

We plan to replace those lists by mailman-managed lists.

- mailman will be installed on a given host (I call it mmhost for the
purposes of this mail, but the real name will be different). Most
likely it will be our www server (www.domain where www is a CNAME
for its real host name), NOT the MXs (the two MXs are redundant,
and are also the primary and secondary DNS and NIS servers).

- I know now that DEFAULT_URL_HOST shall point to www.domain (or
perhaps a dedicated virtual www server)

- I know now that DEFAULT_EMAIL_HOST can be set to "domain" to make
lists and service addresses of the form "list at domain"
(preferred to list at mmhost.domain)

- I know from my tests how to coerce sendmail and mailman to use (and
automatically create) LOCAL aliases of the form

listname: "|/usr/lib/mailman/mail/mailman post listname"

but of course THESE aliases are not suitable to be NIS aliases.
/usr/lib/mailman/mail/mailman won't exist on the MXs and on the
clients !

- I can imagine two ways out of it.

a) having some manual or crontab operated script which for all
mailman alias on the mmhost, replicates in the NIS aliases
aliases of the form

listname: listname at mmhost
listname-owner : listname-owner at mmhost
etc.

b) renouncing to the listname at domain in favour of listname at mmhost.domain
addresses, and doing some clever use of MX records and sendmail
mailertable to route all mail for mmhost (firewalled from outside)
to such machine

PS
I read also FAQs 4.84 and 4.72. Any more suitable for our configuration ?

--
------------------------------------------------------------------------
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
------------------------------------------------------------------------

Search Discussions

  • Mark Sapiro at Apr 1, 2011 at 4:25 pm

    Lucio Chiappetti wrote:
    - all our e-mail are of the form user at domain
    NOT user at host.domain

    OK

    - all outgoing mail is masqueraded as user at domain by sendmail

    OK

    - the DNS advertises two MX's for the domain. We do not advertise MX's for
    particular hosts. Hosts other than MX's should have the SMTP port
    blocked by a firewall on the boundary router (we are several institutes
    in the same building, the boundary router is not managed by ours).

    OK


    [...]
    - mailman will be installed on a given host (I call it mmhost for the
    purposes of this mail, but the real name will be different). Most
    likely it will be our www server (www.domain where www is a CNAME
    for its real host name), NOT the MXs (the two MXs are redundant,
    and are also the primary and secondary DNS and NIS servers).

    If it is not the www server, you can use one of the methods in FAQ 4.84

    - I know now that DEFAULT_URL_HOST shall point to www.domain (or
    perhaps a dedicated virtual www server)

    - I know now that DEFAULT_EMAIL_HOST can be set to "domain" to make
    lists and service addresses of the form "list at domain"
    (preferred to list at mmhost.domain)

    - I know from my tests how to coerce sendmail and mailman to use (and
    automatically create) LOCAL aliases of the form

    listname: "|/usr/lib/mailman/mail/mailman post listname"

    but of course THESE aliases are not suitable to be NIS aliases.
    /usr/lib/mailman/mail/mailman won't exist on the MXs and on the
    clients !

    But it is trivial to augment your script that copies Mailman's aliases
    for sendmail by adding something like

    sed -r -e "s/^(.*):.*$/\1: \1 at mmhost.domain/" < /path/data/aliases > ...

    plus the command(s) necessary to install those in NIS.


    [...]
    PS
    I read also FAQs 4.84 and 4.72. Any more suitable for our configuration ?

    I think those are good.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedApr 1, '11 at 8:38a
activeApr 1, '11 at 4:25p
posts2
users2
websitelist.org

2 users in discussion

Lucio Chiappetti: 1 post Mark Sapiro: 1 post

People

Translate

site design / logo © 2022 Grokbase