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
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
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.
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
-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
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.ourdomainSendmail 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 TryNullMXListNote 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 HedelandTo: 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.