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 ?