This page discusses sendmail-8.9.1a/8.9.3 installation
Actual version you can find at http://www.natur.cuni.cz/~mmokrejs/sendmail
Last update: 21.8.1999

Similar page you can find at http://www.iicons.com/sendmail/configme.html
 

Index:

General information
General considerations
Binaries
Installation
Other sendmail config tasks
Starting sendmail
Problems with with libbind.a nad libresolv.so on Digital UNIX 4.0D
Special features
Sendmail and DNS records, in respect to antiSPAM - campus wide solution
Note on Berkeley DB makemap usage
The proper (official) way of compiling sendmail since 8.9.x version






General information:

At least on machines from Digital/SGI/Sun to which I have access to there were pretty old versions of sendmail. Although COMPAQ/Digital offers sendmail-8.8.8 in it's Digital Unix 4.0E, you get precompiled binary most probably without tcp-wrapper support. Because I think one can't live without tcp-wrappers on UNIX system, I'd recommend you to compile sendmail yourself. I'll time to time place newer precompiled distributions to my web, but this page will still discuss probably 8.9.1a or 8.9.3 version installations.

A lot of very usefull information you can get directly from www.sendmail.org.

Advanced users can visit http://www.sendmail.org/~ca/email/chk89-opt.html, but it's not necessary.

Before compiling sendmail, install db-2.4.X from http://www.sleepycat.com/ into /usr/local/ directory (that's ./configure --prefix=/usr/local ). However, it seems to install into /usr/local/BerkeleyDB/, so move files to /usr/local from that dir or whatever.

Compile sendmail with -DTCPWRAPPERS compileflag, and with LIBS = /usr/local/libdb.a /usr/local/libwrap.a. This will link both libraries statically into the resulting binary. After creating sendmail's binary you have to generate the sendmail.cf file, which is the most difficult task.

I'm using procmail as a local delivery agent because it's very flexible, it gives you ability to filter-out e-mails, sort them, even tweak broken MIME headers, remove some viruses, automagically remove those ugly attachments like WINMAIL.DAT, MS-TNETF and lots of others.

Some URL's related to procmail:
http://www.ii.com/internet/robots/procmail/
ftp://ftp.rubyriver.com/pub/jhardin/antispam/procmail-security.html

Perfect resources about whole InterNet informations are at ftp://cs.uta.fi/pub/ssjaaa/bookmark.html
 
 

General considerations:

 It's a good idea whatever you ever compile yourself to place into /usr/local. To /usr write system installation tools and sometimes they overwrite you binaries, libraries, headers, or you overwrite them. For example: current versions of bind-8.x install themselves into /usr and I twice eneded up with overwrittes header files in /usr/include
Whenever I installed sendmail into /usr/sbin and went to install vendor patches to Digital Unix server, it complained that binaries are different then original from Digital and it refuses to install affected patch. If I just ignored this and went over, I overwrote my binaries of sendmail and could recompile/reinstall them again. So, SAVE YOUR TIME, place everything into /usr/local and just modify /etc/rc* scripts to start programs from new locations. When you will upgrade your OS, you will appreciate that all new stuff is in /usr/local.
 
 

Binaries:

To be found at http://www.natur.cuni.cz/~mmokrejs/sendmail/dux_40, http://www.natur.cuni.cz/~mmokrejs/sendmail/sgi_62, http://www.natur.cuni.cz/~mmokrejs/sendmail/solaris_26

The above binaries were compiled on Digital Unix 4.0D (forerly OSF1, now becoming Compaq Tru64Unix).

7a0b00f57b0d9c4b29f810c739882d39  db-2.4.14-out.tar.gz
ef7f96f5d998383a4bc9494586c84c67  db-2.7.3-dux_40d.tgz
4adfe895535b059b9a44920a63ace1e8  procmail-3.11pre7-out.tar.gz
8a39b10690556964c140fb39c3bc06c4  sendmail-8.9.3-dux_40.tar.gz
dc543ac88c9f00534b0c0a713d7fb43e  sendmail-891a-out.tar.gz
060e66e59b80701a98acab3d274a9fa4  sendmail.cf-8.9.1a.gz
ea6c9cf0920cd8399859b94d1f3b73a0  sendmail.cf-8.9.3.gz

You can find some more info in one SUMMARY message.
 

 
 
 

This text will guide you how to recompile sendmail and necessary applications yourself. If you don't want to remove my binaries from my precompiled sources, omit following 2 command lines bellow whenever they appaer in thi manual:

Commands you may omit are:
make clean
make

Create backups!
cp /usr/lib/sendmail /usr/lib/sendmail.old
cp /etc/sendmail.cf /etc/sendmail.cf.old
 

Installation:

-install tcp-wrappers, get them from ftp://ftp.porcupine.org/pub/security:
- be sure to install NOT only binaries, but also the library and header file! Install binaries into /usr/etc/ or /usr/sbin/ directories

tcp-wrappers$ cp ./tcpd ./tcpdmatch ./tcpdchk ./try-from ./safe-finger /usr/sbin
tcp-wrappers$ cp tcpd.h /usr/local/include
tcp-wrappers$ cp libwrap.a /usr/local/lib
 

-procmail, get it from http://www.procmail.org/ or my precompiled distribution:

gzip -dc procmail-3.11pre7-out.tar.gz |tar xvf -
cd procmail-3.11pre7
make clean

cd procmail-3.11pre7
make clean
make
make install
 

-new Berkeley DB (1.85 or better never releases from 2.x series), get it from http://www.sleepycat.com/ or my precompiled distribution:

gzip -dc db-2.4.14-out.tar.gz |tar xvf -
cd db-2.4.14/build.unix
make clean
make
make install
cp /usr/shlib/libdb.so /usr/shlib/osf.1/libdb.so
cp ./libdb.so /usr/shlib/libdb.so

  - the shared library in my package was created by this command:

ld -shared -no_archive -o ./libdb.so -all ./libdb.a -none -lc

  - when you compile libdb.a with CXX support, linker in previous command warns you about unresolved symbols

  - also you can have another problem when you enable the dump_db85 feature, run make and make fails with this error:

    cc -o db_dump185  db_dump185.o err.o getlong.o
    ld:
    Unresolved:
    dbopen
    *** Exit 1

                       ..... which is solved by this

    cc -o db_dump185  db_dump185.o err.o getlong.o ./libdb.a
    and type make again

 I've heard, that this is not a right way producing shared libraries and that may be not functional. So, no warranty.

 

-sendmail, get it from http://www.sendmail.org/ or my precompiled distribution:

--install GNU m4 utility, you will need it for creating the config file
  - or use our sendmail.cf file (note that in the sendmail.cf file are
    used Tab-s, not spaces!!! Otherwise, sendmail will not work!
    So not dowload it as a text file. Anyway, you should use this file only with same version of sendmail.

--documentation:
        sendmail-8.9.1/README
        sendmail-8.9.1/src/README
        sendmail-8.9.1/cf/README
        sendma

cp sendmail.cf /etc/sendmail.cf
 

        [For your info, the config file is created this way:

        edit sendmail-8.9.1/cf/domain/generic.m4
                -just check what is in ;)

        edit sendmail-8.9.1/cf/cf/tcpproto.mc
                -lines containing OS type and version
                -if you leave there DOMAIN(generic), than the
                 sendmail-8.9.1/cf/domain/generic.m4 is used
                    (which doesn't hurt and you save some time copying sendmail-8.9.1/cf/domain/generic.m4 to sendmail-8.9.1/cf/domain/your-domain-name.m4
                 -if you place there DOMAIN(natur.cuni.cz), it will require sendmail-8.9.1/cf/domain/natur.cuni.cz.m4 file, so an extra work. ;-)
 

Here's our tcpproto.mc, maybe you can omit relay_entire_domain. ;-)

divert(0)dnl
VERSIONID(`@(#)tcpproto.mc      8.10 (Berkeley) 5/19/1998')
OSTYPE(osf1)
FEATURE(nouucp)
FEATURE(access_db)
FEATURE(blacklist_recipients)
FEATURE(redirect)
FEATURE(smrsh)
FEATURE(relay_entire_domain)
FEATURE(rbl)
FEATURE(use_cw_file)
FEATURE(redirect)
FEATURE(local_procmail)
FEATURE(always_add_domain)
LOCAL_CONFIG
O MaxMimeHeaderLength=256/128
MAILER(procmail)
MAILER(local)
MAILER(smtp)
 
 
 

        The final steps are:

        cd sendmail-8.9.1/cf/cf
        /usr/local/bin/m4 ../m4/cf.m4 ./tcpproto.mc > ./sendmail.cf
        more ./sendmail.cf
        cp ./sendmail.cf /etc/sendmail.cf

You want to end up with sendmai.cf containing:


Mlocal,         P=/usr/local/bin/procmail, F=SAw5:|/@qglDFMPhsfn, S=10/30, R=20/40,
                T=DNS/RFC822/X-Unix,
                A=procmail -Y -a $h -d $u
Mprog,          P=/usr/local/sbin/smrsh, F=lsDFMoqeu9, S=10/30, R=20/40, D=$z:/,
                T=X-Unix,
                A=sh -c $u

D       Need Date: in header
F       Need From: in header
M       Need Message-ID: in header
S       Assume specified uid and gid
P       Need Return-Path: in header
h       Preserve uppercase in hostname
n       Don't use UNIX-style From in header
u       Preserve uppercase for username.
9       Convert 7-bit to 8-bit if appropriate

You also have to setup smrsh to execute some files, otherwise it will deny all requests:


You have to tell smrsh that procmail and for example vacation are valid 
program which it may exec. All other execution will be denied.

do it as follows:
cd /var/adm
mkdir sm.bin
cd sm.bin
ln -s /usr/local/bin/procmail .
ln -s /usr/bin/vacation .
ln -s /usr/majordomo/resend .
ln -s /usr/majordomo/tlb .
ln -s /bin/mail .

Don't forget to install sendmail's helpfile like this:
cp sendmail-8.9.3/sendmail/helpfile /etc/mail/helpfile
  (the actual target place for helpfile is defined in sendmail.cf

mkdir /var/spool/mqueue/.hoststat
touch /etc/mail/statistics
chmod 644 /etc/mail/statistics


> I would like my users to individually use procmail from their .forward,
> but I would like to use smrsh as well. Is there any solution?

For security reasons you should install smrsh into sendmail.cf.
At least for performance and quality of procmail you should use procmail
as a Local Delivery Agent (Mlocal part). That's because procmail is fast, 
reliable, handles many locking strategies, there's simply no reason why not 
to do that - IMHO.

mmokrejs> library. How can I tell the Build script to use
mmokrejs> /usr/shlib/libdb.so?

It searches the following directories, in order:
/lib /usr/lib /usr/shlib


If you want /usr/shlib searched first, set:
define(`confLIBDIRS', `/usr/shlib')
in your site.config.m4 file.

Another note from src/README may be appropriate here:

        On Digital UNIX 4.0 and later, Berkeley DB 1.85 is included with the
        operating system and already has the ndbm.o module removed.  However,
        Digital has modified the original Berkeley DB db.h include file.
        This results in the following warning while compiling map.c and udb.c:

        cc: Warning: /usr/include/db.h, line 74: The redefinition of the macro
         "__signed" conflicts with a current definition because the replacement
         lists differ.  The redefinition is now in effect.
        #define __signed        signed
        ------------------------^

        This warning can be ignored.

 
 
 

Special features:

There are some usefull features you might need. They can be configured by editing some of the .m4 files before sendmail.cf is generated. Have a look at general introduction to cf/README at http://www.sendmail.org/m4/readme.html.

For example, if you want to set up a machine, which will send all outgoing e-mails to some central e-mail server in your domain, you can edit /etc/sendmail.cf in this way:

# "Smart" relay host (may be null)
DSour_mailhub.ourdomain


Sendmail and DNS records, in respect
to antiSPAM - campus wide solution:

You would configure properly your forward DNS database to protect your network against unauthorized relaying attempts. Block on your router all incoming SMTP(tcp/25) data to other hosts than mail.domain and it's backups mail2.domain and mail3.domain. Let's suppose you have also mail4.otherdomain server which collects e-mail for you domain if your router is down.

          IN         MX     10     mail.domain.
          IN         MX     100    mail2.domain.
          IN         MX     200    mail3.domain.
          IN         MX     300    mail4.otherdomain.

Because you are blocking SMTP connections to all SMTP-capable machines you don't have root access to or don't have time to upgrade to latest sendmail with antispam config, you have to create MX records for these machine. If mailers used by clients are configured correctly, before they try to send an e-mail, they should do na MX lookup, and get MX records for destination host, and if there are any, client mailers should use them in preference to direct delivery.

Let's say you want have somehost.domain, which without an MX recor cannot recieve any e-mail outside your domin, because it's in your firewalled network. ;-) The MX priority can be of any value.

The idea is:
We have an e-mail for user@somehost.domain, does the somehost.domain have an MX record? YES, it's mail.domain and it's the only one MX record. Let's try to deliver it there. Does mail.domain have some MX record? YES, 4 records! Great. Let's try the one with lowest priority, i.e. mail.domain itself. Ooooops, it's down! Let's try mail2.domain ... and so on.

 
somehost.domain.          IN         MX     200     mail.domain.
somehost2.domain.         IN         MX     200     mail.domain.
somehost3.domain.         IN         MX     200     mail.domain.


Also, you most probably will need enabled the following line in /etc/sendmail.cf,
otherwise you will most probably get an error like Local configuration
error: MX loops back to myself :
# if we are the best MX host for a site, try it directly instead of config err
O TryNullMXList


Note on Berkeley DB makemap usage:

The following e-mail was about the problem, that I "discovered", that on SGI server is also `makemap' program, which does something different what i expected - manipulates colors. Since then I know, that you even shoudln't use makemap from even Berkeley DB to produce .db files for sendmail.

Date: Mon, 25 Jan 1999 00:21:20 +0100 (MET)
From: Per Hedeland 
To: mmokrejs@natur.cuni.cz
Cc: sendmail-questions@sendmail.org
Subject: Re: Broken DB-2.6.4 support on Irix6.2

Martin Mokrejs  wrote:
> But, I was starting
>different makemap binary - some SGI product utility called makemap, which
>manipulates with color definitions. 
>
>So, `makemap hash /etc/aliases < /etc/aliases' did produce
>/etc/aliases.db, with zero size.

Even if you get the "right" makemap, you can't use it to build the
aliases map - use 'newaliases' (a.k.a. 'sendmail -bi') for that.


The proper (official) way of compiling sendmail since 8.9.x version:

This a response from sendmail maintainers about this page you currently read. Yes, you should start using the Build utility from distribution, so apply the message as a patch to everything you've currently read on my page. ;-)

mmokrejs> Because I did few times respond to some questions related to
mmokrejs> sendmail on various lists and did not want to write always the
mmokrejs> same, I wrote a simple webpage. It seems that people use it and
mmokrejs> do ask me even more, which is pretty bad, because I don't
mmokrejs> understand sendmail anyhow. ;(

mmokrejs> I'd like not to suggest people my way of creating binary and .cf
mmokrejs> file, shortly:

mmokrejs> cd src.
mmokrejs> ./Build     -after it creates makefile do Ctrl+c
mmokrejs> cd obj*
mmokrejs> edit Makefile, add -DTCPWRAPPERS and adjust LIBS ....
mmokrejs> make clean
mmokrejs> make

Instead, put the following in BuildTools/Site/site.config.m4:

APPENDDEF(`confENVDEF', `-DTCPWRAPPERS=1')
APPENDDEF(`confLIBS', `-lwrap')

And Build will automatically take care of the changes for the Makefile.
See BuildTools/README for more information.

mmokrejs> cd cf/cf
mmokrejs> edit tcpproto.mc
mmokrejs> /usr/local/bin/m4 ../m4/cf.m4 ./tcproto.mc > ./sendmail.cf

Instead:

cd cf/cf
cp tcpproto.mc my.mc
edit my.mc
m4 ../m4/cf.m4 my.mc > my.cf

mmokrejs> I'd like to ask you to explain me the proper way. I did try to
mmokrejs> learn it myself, but for example I was never able to set in any
mmokrejs> .m4 file TIMEZONE correctly. It was always truncated by the m4
mmokrejs> program, so I had always to edit the resulting sendmail.cf and
mmokrejs> correct it.

From cf/README:

EXCEPTIONS: DEC's m4 on Digital UNIX 4.x is broken (3.x is fine).  Use GNU
m4 on this platform.

mmokrejs> 5.

mmokrejs> The RELNOTES for 8.9.3 do not mention that one still need to set

mmokrejs> CFLAGS= -D_FFR_MAX_MIME_HEADER_LENGTH=1

mmokrejs> It only says the 8.9.1a patch has been included, but that doesn't
mmokrejs> mean it's activated by default.

Yes, new features are never added in a minor release.  It will be activated
in 8.10.