[Mailman-Users] Integrating Sendmail and Solaris (installation guide)

[vancleef at lostwells.net]

Mailman, in its default configuration, readily integrates with a
properly-configured sendmail installation.  

The discussion below gives specific file locations for a Solaris 9
installation.  Solaris 10 locates the sendmail control file sources in
/etc/mail/cf rather than /usr/lib/mail/cf.  Locations of the sendmail
executable and ancillary files are compile-time options for sendmail,
so you will need to determine file locations for your specific
installation.  In our discussion, we also assume that the sendmail MTA
that communicates with the Internet backbone and Mailman are installed
on the same node (same hardware box).  

Steps required for a Mailman-sendmail integration:

1. Enable smrsh. Creating the directory links was covered in the
previous installation step.  In addition, assure that the link to the
smrsh program is declared in main.mc. (/usr/lib/mail/cf/main.mc on a
Solaris 9 system).

FEATURE(smrsh, /usr/lib/smrsh)dnl

2. For each list that you create, you need to add a set of alias
pipes to the aliases file (typically /etc/mail/aliases) and run the
newaliases program (/usr/sbin/newaliases).  If you are following this
guide for an initial Mailman installation, you will not be creating 
lists until later steps.  Mailman will give you the alias information
when you create a list.  Additionaly, the $(prefix)/bin/genaliases
script will generate all of aliases needed for all lists that have
been created to stdout.  These are in the correct format for the
sendmail aliases file.  

3. Set up sendmail masquerading to correspond to the Mailman
configuration.  For example, if your installation is on a machine
known as myhost.mydomain.net and you create a list to receive mail
at mylist at mydomain.net, you will need to masquerade as mydomain.net.
You will also need to masquerade the sending envelope as well.  
In its simplest form, the statements in main.mc for doing this are:

MASQUERADE_AS(`mydomain.net')dnl
FEATURE(`masquerade_envelope')dnl

4. Add the masquerade address to /etc/mail/local-host-names. For the
example above, the local-host-names file must have:

mydomain.net

The above four items cover the basics needed to integrate Mailman with
a simple sendmail installation.  Except for the need to enable smrsh
and to install piping aliases, virtually everything surrounding a
Mailman installation supported by the sendmail MTA is specific to
sendmail, and some of the above is abstracted from sendmail
documentation.  

This documentation includes:

The README included in the sendmail source distribution from
http://www.sendmail.org/

Costales, Bryan: "Sendmail," 3rd edition, O'Reilly, 2002
This is commonly referred to as the "bat book."

Costales, Bryan: "Sendmail 8.13 Companion," O'Reilly, 2006

Additional resources are the web site and sendmail faq at:
http://www.sendmail.org/
Usenet newsgroup comp.mail.sendmail

For convenience, we include comments here on sendmail configuration
considerations that often come up on the mailman-users list.  
References are to Costales, "Sendmail".  

A general guiding principle when working with sendmail is to "keep it
simple."  In particular, configure and test your sendmail installation
thoroughly, with user accounts running simple MUA's such as elm or
mutt, before expecting sendmail to work with Mailman.  Virtually all
of the problems users encounter with sendmail are visible to simple
MUA testing.  

In particular, do ALL of your sendmail configuration through the M4
macro files, rather than attempting to read and edit the .cf files.  
Since your M4 files will quickly become site-specific, we recommend
copying the the full M4 setup to a local directory, and managing the
configuration from there.  This will prevent a sendmail upgrade from 
overlaying your site's configuration, something that has historically
been a problem to Solaris users, where a sendmail upgrade is included
in a patch cluster.  

Management of sendmail .cf files through the M4 files is discussed in
"Sendmail" chapter 4.  

Virtual Domain handling:  This refers to the case where a server 
at mydomain.net handles mail for otherdomain.com.  The authoritative
DNS for otherdomain.com is set with A and/or MX records pointing to
the same IP as that for mydomain.net.

Handling this in sendmail is straightforward.  Masquerading is covered
in detail in "Sendmail" section 4.4, pp160ff.  However, the discussion
does not give a complete main.mc file masquerading configuration, which 
we include here for convenience:

MASQUERADE_AS(`mydomain.net')dnl
FEATURE(`masquerade_entire_domain')dnl
FEATURE(`limited_masquerade')dnl
LOCAL_DOMAIN(`mydomain.net otherdomain.com')dnl
MASQUERADE_DOMAIN(`mydomain.net')dnl

In short, you include all of the domain names you are handling, but
only specify masquerading for domains where you need a nodename
removed from the canonical name.  

You also need to add the additional domain(s) to
/etc/mail/local-host-names; each domain name on a separate line.

Note that "local-host-names" is actually optional feature for adding
names to the class $=w in the .cf file convention.  It is typically
defined (by default) in cfhead.m4 (on Solaris 9,
/usr/lib/mail/m4/cfhead.m4)
define(`confCW_FILE', `MAIL_SETTINGS_DIR`'local-host-names')

For test, a simple local MUA should be able to send and receive mail
from any of the domain names at your host.  Make sure that the
"host name this list prefers for email" on the main options page is
correct for the masquerading you have set up.  

Note that the list outgoing mail envelope is added by sendmail, and
is not a Mailman function.

Relaying:  Once upon a time, sendmail allowed significant relaying by
default.  Recent and current versions default to "no relaying at all."
"Sendmail," section 4.5, pp164ff, discuss sendmail relaying in detail.

Solaris users should be aware that the Sun Solaris sendmail
distributions have relaying enabled by default.  For almost all
installations, this should be corrected by changing the main.mc
DOMAIN statement to:
DOMAIN(`solaris-antispam')dnl

On non-Solaris systems, the usual DOMAIN statement is:
DOMAIN(`generic')dnl