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@domain
NOT user@host.domain
- all outgoing mail is masqueraded as user@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@domain is delivered to other hosts
via alias expansion managed by NIS. So some users get it delivered
to user@personalhost, some other to user@projectimapserver.
- our current mailing lists (e.g. staff@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@domain"
(preferred to list@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@mmhost
listname-owner : listname-owner@mmhost
etc.
b) renouncing to the listname@domain in favour of listname@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
------------------------------------------------------------------------
------------------------------------------------------
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
