|
Setting up sendmail on a firewall, Part 3Learn about special situations and testing techniques |
Carole's previous two columns on sendmail 8.9.3 explained the new features available and described how to build the binary and configuration files. This final part covers installation, optional features, and testing techniques. An example of configurations for a special situation is described. (4,400 words)
This is the final installment of my three-part series on secure sendmail installations. There's plenty more to say, of course, but I don't want to turn this into a Wizard's Guide to Sendmail column.
To paraphrase an old saying, an example is worth a thousand words. This month, I'll elaborate on some optional features of sendmail and give an example of a configuration I have used. This example worked for me, though I am by no means stating that it is the best or only solution to the problem. It is merely a solution that I successfully implemented. Hopefully, you can learn something from it. If you have a better way of solving the same problem, just send me mail and I'll post it. I'm always interested in learning something new. I'll also cover some testing and debugging techniques that might be useful.
Putting it into production
Several years ago, a friend of mine built a sendmail
configuration for a firewall, but left the company before it was put
into production. The administrator who took over the system did not
realize that the intention was to run sendmail in a restricted
(chrooted) environment with no root privileges. When the firewall
was put into production, it was quickly hacked because sendmail was
not installed properly.
Where to install
I like to use chroot to create a restricted padded cell to isolate
sendmail from the rest of the system. (See my January 1999 column,
"Creating
a basic padded cell".) Using chroot is no guarantee of security,
but it does limit exposures. If it is used in combination with tight
permissions, it provides an effective security barrier.
For the sake of argument, let's say that the root of the cell is a
filesystem called /sendmail_cell
that is mounted "nosuid"
. Normally,
on Solaris, the sendmail binary is installed in /usr/lib/sendmail
and the configuration file is in /etc/mail/sendmail
. Since the
configuration file used to be in /etc
, I put in a symbolic link from
/etc/sendmail.cf
to /etc/mail/sendmail.cf
. Because we're using a
padded cell here, it will be in /sendmail_cell/usr/lib/sendmail
and
/sendmail_cell/etc/mail/sendmail.cf
. The startup script (/etc/rc2.d/S88sendmail
on Solaris) is modified to start sendmail with chroot.
At the beginning of the startup file, define a variable for the
padded cell directory:
PADDED_CELL=/sendmail_cell
Preface all paths with the padded cell variable as in:
(text deleted) if [ -f ${PADDED_CELL}/usr/lib/sendmail -a -f ${PADDED_CELL}/etc/mail/se ndmail.cf ]; then if [ -d ${PADDED_CELL}/var/spool/mqueue ]; then (cd ${PADDED_CELL}/var/spool/mqueue; rm -f nf* lf*) else mkdir ${PADDED_CELL}/var/spool/mqueue chown root ${PADDED_CELL}/var/spool/mqueue chgrp staff ${PADDED_CELL}/var/spool/mqueue chmod 750 ${PADDED_CELL}/var/spool/mqueue fi /usr/sbin/chroot ${PADDED_CELL} /usr/lib/sendmail -bd -q15m; fi (more text deleted)
Permissions
Sendmail will complain about directory permissions until you fix them:
chmod go-w / /etc /etc/mail /usr /var /var/spool /var/spool/mqueue chown root / /etc /etc/mail /usr /var /var/spool /var/spool/mqueue
See the README
file in the top sendmail distribution directory for a
more complete explanation.
If you are using a padded cell, preface each directory above with
the name of the cell known to the system, as in /sendmail_cell
,
/sendmail_cell/etc/mail
, and so on.
I shouldn't even have to say this, but make sure the sendmail.cf
file is not world writeable. In fact, it should not be world
readable either unless you're running a POP or IMAP server on the
firewall. I have mine owned by root and only readable by root:
-r-------- 1 root bin 27626 Mar 19 12:59 /etc/mail/sendmail.cf
The most common misconception about sendmail is that the binary has
to run setuid
to root. While this is true on an internal mail host,
it is not true on a firewall. Because there are no users actually
receiving mail on the firewall, sendmail does not need to read
users' home directories to look for .forward
or vacation
files.
Therefore, it does not need to be setuid
to root:
-rwxr-xr-x 1 root other 343846 Apr 16 1998 sendmail
Security in the configuration file
By default, the sendmail configuration file sets options such as
file creation mode (O TempfileMode=600
) to be secure. Do not change
these without understanding the consequences. You may want to turn
off vrfy
and expn
to prevent someone from trying to verify valid
user IDs on the system. Of course, if you're using chroot to run
sendmail in a cell, the copy of the passwd
file that is in the cell
should not be the real one. In my recent "Audits
from Hell" column, I used this fact to have a little fun with
the penetration team. They usually get the name of the site contact
and try a combination to find out the user ID. In this example,
assume that "Carole Fennelly" and "Jon Klein" are in the WHOIS
database -- juvenile, I know, but fun:
root:x:0:1:Welcome Penetration Test Team!:/:/sbin/sh daemon:x:1:1::/: bin:x:2:2::/usr/bin: sys:x:3:3::/: adm:x:4:4:Admin:/var/adm: smtp:x:0:0:Mail Daemon User:/: listen:x:37:4:Network Admin:/usr/net/nls: nobody:x:60001:60001:Give up!:/: noaccess:x:60002:60002:No Access User:/: nobody4:x:65534:65534:SunOS 4.x Nobody:/: fennelly:x:7000:7000: Carole doesn't live here. Good try though:/tmp:/usr/local/ etc/noshell cfennell:x:7001:7001: We don't let Carole out during the day. Try at night:/tmp:/ usr/local/etc/noshell jklein:x:7001:7001:We don't let Jon out at all. He bites:/tmp:/usr/local/etc/n oshell
A vrfy
on the SMTP port yields:
vrfy root
250 Welcome Penetration Test Team!vrfy cfennell
250 We don't let Carole out during the day. Try at night. <cfennelly@company.com> vrfy jklein
250 We don't let Jon out at all. He bites. <jklein@company.com>
Anyway, if you want to turn off vrfy
and expn
, put the following line in your m4 configuration file. (I used firebox.mc
in my example last month):
define(`confPRIVACY_FLAGS', `noexpn,novrfy')
The access database
The access database provides the administrator with a mechanism to
set up specific access lists to control the sender and relayers of
mail. It provides more granularity than the sender/relayer rules.
An access database is an ASCII file that is converted into a database that is in dbm format (ndbm), hash, or btree format (Berkeley DB). It is up to the reader to decide which database to use. For the purposes of this article, we are using a dbm database.
A database record consists of two parts: the key and the action. The
key can be a user name, domain name, or network address. The action
could be OK
, RELAY
, REJECT
, DISCARD
or an RFC821
message. Below is
a sample access database list taken from the README
file in
sendmail-8.9.3/cf.
cyberspammer.com 550 We don't accept mail from spammers okay.cyberspammer.com OK sendmail.org OK 128.32 RELAY
Additionally, we will add a few more records:
foobar.com REJECT garbage@spam.org DISCARD
In the above examples, mail coming from cyberspammer.com
is
rejected, and the 550 message is sent back to the originator.
However, if the mail comes from host okay.cyberspammer.com
, then the
mail is accepted. Mail from sendmail.org
is accepted. Mail from any
host in the 128.32 class B is allowed for relay (and thus is
accepted as OK). Mail from foobar.com
is rejected and sender gets an
access denied message. Mail from garbage@spam.org
is accepted from
the sender's perspective but is actually thrown away by the
recipient mailer. The sender thinks that mail was sent
satisfactorily when in fact it was not.
To enable the access database, add to your .mc
file:
FEATURE(`access_db')dnl
This will create an entry in the .cf
file to use the hash database:
Kaccess hash -o /etc/mail/access
To override this, you can add a second parameter to the feature. In our case, we want to use a dbm type database so we would enter:
FEATURE(`access_db',`dbm -o /etc/mail/access')dnl
The -o
option specifies that the map is optional. (If it can't be
opened it will be ignored.) If it's important that the access
database be used, don't specify -o
. This will create an entry in
the sendmail .cf
file in the form:
Kaccess dbm -o /etc/mail/aliases
Remember, that you must build and use the makemap command to
generate the access database. For our example, we had a source list
called /etc/mail/access.list
. By running the command
makemap dbm /etc/mail/access < /etc/mail/access.list
we would generate an access.dir
and access.pag
in the /etc/mail
directory. This is the file that sendmail will use for the
database.
Here is a test with our sample access database:
220 mgate.wkeys.com ESMTP Sendmail 8.9.3/8.9.3; Sun, 23 May 1999 21:53:13 -0400 ( EDT) helo wkeys.com 250 mgate.wkeys.com Hello merlin.wkeys.com [190.70.70.50], pleased to meet you mail from: <klein@cyberspammer.com>
550 <klein@cyberspammer.com>... We don't accept mail from spammers mail from: <klein@foobar.com>
550 <klein@foobar.com>... Access denied mail from: <klein@okay.cyberspammer.com>
250 <klein@okay.cyberspammer.com>... Sender ok rcpt to: <klein@wkeys.com>
250 <klein@wkeys.com>... Recipient ok data
354 Enter mail, end with "." on a line by itself test .
250 VAA07870 Message accepted for delivery quit
221 mgate.wkeys.com closing connection 220 mgate.wkeys.com ESMTP Sendmail 8.9.3/8.9.3; Sun, 23 May 1999 21:54:08 -0400 ( EDT) helo wkeys.com
250 rahl.wkeys.com Hello merlin.wkeys.com [190.70.70.50], pleased to meet you mail from: <garbage@spam.org>
250 <garbage@spam.org>... Sender ok rcpt to: <klein@wkeys.com>
250 <klein@wkeys.com>... Recipient ok data
354 Enter mail, end with "." on a line by itself test .
250 VAA07876 Message accepted for delivery quit
221 mgate.wkeys.com closing connection
Here is the log file information on the test:
May 23 21:53:26 mgate sendmail[7868]: VAA07868: from=klein@cyberspammer.com, size=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=merlin.wkeys.com [190.70.70.50] May 23 21:53:34 mgate sendmail[7869]: VAA07869: ruleset=check_mail, arg1=klein@fo obar.com, relay=merlin.wkeys.com [190.70.70.50], reject=550 klein@foobar.com.. Access denied May 23 21:53:34 mgate sendmail[7869]: VAA07869: from=klein@foobar.com, size=0, cl ass=0, pri=0, nrcpts=0, proto=SMTP, relay=merlin.wkeys.com [190.70.70.50] May 23 21:53:59 mgate sendmail[7870]: VAA07870: from=klein@okay.cyberspammer.com, size=5, class=0, pri=30005, nrcpts=1, msgid=<199905240153.VAA07870@mgate.wkeys.c om>, proto=SMTP, relay=merlin.wkeys.com [190.70.70.50] May 23 21:53:59 mgate sendmail[7871]: VAA07870: to=klein@wkeys.com, delay=00:00:0 7, xdelay=00:00:00, mailer=local, stat=Sent May 23 21:54:18 mgate sendmail[7875]: VAA07875: ruleset=check_mail, arg1=klein@fo obar.com, relay=merlin.wkeys.com [190.70.70.50], reject=550 klein@foobar.com.. . Access denied May 23 21:54:18 mgate sendmail[7875]: VAA07875: from=klein@foobar.com, size=0, cl ass=0, pri=0, nrcpts=0, proto=SMTP, relay=merlin.wkeys.com [190.70.70.50] May 23 21:54:29 mgate sendmail[7876]: VAA07876: ruleset=check_mail, arg1=garbage@ spam.org, relay=merlin.wkeys.com [190.70.70.50], discard May 23 21:54:36 mgate sendmail[7876]: VAA07876: from=garbage@spam.org, size=5, cl ass=0, pri=30005, nrcpts=1, msgid=<199905240154.VAA07876@mgate.wkeys.com>, proto= SMTP, relay=merlin.wkeys.com [190.70.70.50] May 23 21:54:36 mgate sendmail[7876]: VAA07876: discarded
TCP Wrappers
Sendmail supports the use of TCP Wrappers. (The current
version is tcp_wrappers 7.6, available from
ftp://ftp.cert.org/pub/tools/tcp_wrappers/.) In your site configuration file, /usr/local/src/sendmail-8.9.3/BuildTools/Site/site.config.m4
, add the following:
APPENDDEF(`confENVDEF', `-DTCPWRAPPERS') APPENDDEF(`confINCDIRS',`-I/usr/local/include') APPENDDEF(`confLIBS', `-lwrap') APPENDDEF(`confLIBDIRS',`-L/usr/local/lib')
You must have previously installed libwrap.a
and tcpd.h
into a
system library and include directory, respectively. Once this is done, you
can build sendmail. To use the feature, enter a service name of
sendmail in /etc/hosts.allow
or /etc/hosts.deny
. If a connection is
denied, the machine will still be able to create the connection, but
all command requests will generate an "access denied" message for
the user and a rejection message in the server's log file.
In this example, we have set up a host access list that allows firebox
but not
merlin
. First, here's the output from firebox
, and then merlin
:
220 mgate.wkeys.com ESMTP Sendmail 8.9.3/8.9.3; Sun, 23 May 1999 21:40:21 -0400 ( EDT) helo wkeys.com
250 mgate.wkeys.com Hello firebox.wkeys.com [190.70.70.20], pleased to meet you vrfy root
250 Super-User <root@mgate.wkeys.com> mail from: <klein@wkeys.com>
250 <klein@wkeys.com>... Sender ok rcpt to: <klein@wkeys.com>
250 <klein@wkeys.com>... Recipient ok data
354 Enter mail, end with "." on a line by itself .
250 VAA07830 Message accepted for delivery quit
221 mgate.wkeys.com closing connection
On mgate
, the log file has the following:
May 23 21:40:29 mgate sendmail[7829]: NOQUEUE: firebox.wkeys.com [190.70.70.20]: vrfy root May 23 21:40:51 mgate sendmail[7830]: VAA07830: from=klein@wkeys.com, size=5, cla ss=0, pri=30005, nrcpts=1, msgid=<199905240140.VAA07830@mgate.wkeys.com>, proto=S MTP, relay=firebox.wkeys.com [190.70.70.20] May 23 21:40:52 mgate sendmail[7833]: VAA07830: to=klein@wkeys.com, ctladdr=klein @wkeys.com (1002/10), delay=00:00:10, xdelay=00:00:00, mailer=local, stat=Sent
From merlin
, we have the following:
220 mgate.wkeys.com ESMTP Sendmail 8.9.3/8.9.3; Sun, 23 May 1999 21:42:24 -0400 ( EDT) helo wkeys.com
250 mgate.wkeys.com Hello merlin.wkeys.com [190.70.70.50], pleased to meet you vrfy root
550 Access denied mail from: <klein@wkeys.com>
550 Access denied rcpt to: <klein@wkeys.com>
550 Access denied data
550 Access denied .
550 Access denied quit
221 mgate.wkeys.com closing connection
And mgate
has the following in its log:
May 23 21:42:24 mgate sendmail[7840]: tcpwrappers (merlin.wkeys.com, 190.70.70.50) rejection May 23 21:42:44 mgate sendmail[7840]: NOQUEUE: Null connection from merlin.wkeys.com [190.70.70.50]
Example of a sendmail configuration
I think the best way to explain this example is to describe a
problem that I once tried to solve, followed by the eventual solution. As
I've learned more about sendmail, my solutions have changed to
reflect what I've learned. Consequently, they may change again as I
continue to learn new or better ways to do things.
The problem:
There are two organizations (let's say ORG1 and ORG2) in the same company
(company.com
) that are separated by an internal firewall (int_fw.company.com
). This company has not implemented sub-domains (both sides are company.com
-- don't ask). ORG1 has an internal mail host called
mgate_org1.company.com
with an IP address of 10.11.12.13. All external
mail comes in through the ORG1 side, which is running a proprietary mail
solution. ORG2 has an internal mail host with an address of 190.70.60.50 that
is called mgate_org2.company.com
and is running sendmail.
Life would be much easier if sub-domaining had been used, but it wasn't.
ORG2 has its mail configured to deliver the mail locally if it is in the domain
company.com
and to send it to the external firewall if it is not. The problem
arose when ORG2 wanted to be able to send mail to users in ORG1. ORG1 has
to maintain a database listing each user and their address. Yuck. They are both
company.com
. We didn't want to maintain an alias file for every user in the
company for ORG2. The mail gateway in ORG2 (mgate_org2.company.com
)
knows who its users are from the master passwd
file and can be configured to
relay to the internal firewall all unknown local users (see the "mgate_org2.mc
" listing).
However, the internal firewall (int_fw.company.com
) has no way of distinguishing
who is a user for ORG1 and who is a user for ORG2.
The solution:
One possible solution is to have the internal firewall maintain two files that list the users for the respective organizations. But this is a maintenance nightmare that we wanted to avoid. The solution I used is a bit strange (suggested by my partner Jon, who is also a bit strange), but it works.
Basically, the internal firewall (int_fw.company.com
) has two instances of
sendmail running, each listening on separate interfaces for the two networks.
Remember, this is a firewall with two interface cards: one for the 10.11.12 net
(let's say with the address of 10.11.12.14) and the other for the 190.70.60 net
(say, 190.70.60.40). Each instance of sendmail will have its own configuration
file. The configuration file that listens on the 10.11.12.14 interface will forward all the mail it gets to mgate_org2.company.com
. The configuration file that listens on the 190.70.60.40 interface will forward all the mail it gets to
mgate_org1.company.com
. Each configuration keeps separate queue and alias
files (see the "int_fw_from_org1.mc
" and "int_fw_from_org2.mc
" listings).
Logging and troubleshooting
Sendmail uses the syslog utility to log information based on the
LogLevel option defined in the sendmail.cf
file. By default, the
LogLevel option is set to 9
, and log information is appended to
/var/log/syslog
. I use the default LogLevel, but change
/etc/syslog.conf
so that sendmail data is stored in a separate file,
/var/log/mail.log
. (Don't forget the tab between mail.debug
and
ifdef
.)
mail.debug ifdef(`LOGHOST', /var/log/mail.log, @loghost)
For more details on sendmail logging and syslog, see Chapter 26 of Sendmail -- 2nd edition by Bryan Costales.
The sendmail log file (in my case /var/log/mail.log
) is very useful
for debugging purposes. I usually run a tail -f
on it when I'm
installing a new configuration or troubleshooting a problem.
Sendmail is pretty good about telling you if it's upset with
something. Here are some samples from my firewall's log files:
This is a normal incoming mail message:
May 23 15:56:52 firebox sendmail[12211]: PAA12211: from=<merlin@feline.com>, si ze=1895, class=0, pri=31895, nrcpts=1, msgid=<02d1f0156191759CPIMSSMTPU02@email. feline.com>, proto=ESMTP, relay=cpimssmtpu02.email.feline.com [123.45.67.8] May 23 15:56:53 firebox sendmail[12213]: PAA12211: to=<fennelly@wkeys.com>, dela xdelay=00:00:00, mailer=smtp, relay=mgate.wkeys.com. [190.9.10.11], stat=Sent (PAA04928 Message accepted for delivery)
I changed names and IP addresses in this example, but this shows
incoming mail from the user merlin
at the domain feline.com
(IP
address 123.45.67.8) with the message ID PAA12211
. Another sendmail
kicks off to send the mail to its destination user, fennelly
, via the
wkeys.com
relay system mgate.wkeys.com
(IP 190.9.10.11). The
important piece here is the stat=Sent
. If you have users complaining
about mail not getting through, search your log file for
stat=Deferred
. If it's only a few sites, the problem is probably at
their end. If it's everything, you're going to have a bad day.
This next example from the logs looks like a nasty hacker attack from attrition.org
-- a site that is associated with hacking:
May 21 18:23:18 firebox sendmail[8929]: NOQUEUE: POSSIBLE ATTACK from attrition. org: newline in string "culthero " May 21 18:23:19 firebox sendmail[8930]: SAA08930: from=<jericho@attrition.org>, size=876, class=0, pri=30876, nrcpts=1, msgid=<Pine.LNX.3.96.990521151311.6238O- 100000@forced.attrition.org>, proto=ESMTP, relay=culthero@attrition.org [128.11. 253.197] May 21 18:23:20 firebox sendmail[8932]: SAA08930: to=<fennelly@wkeys.com>, delay =00:00:02, xdelay=00:00:01, mailer=smtp, relay=mgate.wkeys.com. [190.80.70.7], stat=Sent (SAA04517 Message accepted for delivery)
Indeed, the first time I saw this I followed up by sending mail to
the site's administrator (with the lines from my log file)
requesting help in tracking this down. After several e-mails back
and forth, it turned out that sendmail was not happy about some
custom headers at the attrition.org
site, although it allowed the
mail to go through. It was not an actual attack, and in fact shows
up every time I get mail from that site. I was glad I had not jumped
to the conclusion that I was being attacked. (See link to "Chain of
Command" article in the Resources section
below.) Keep in mind that just because the log says something may be
an attack, it may not be malicious at all. Here are some that were
attacks using ISS Scanner:
Mar 21 13:52:31 dummyname.org sendmail[6560]: NOQUEUE: POSSIBLE ATTACK f rom ip192.isdn5.new-york4.ny.psi.net: newline in string "iss Croot Mprog, P=/b in/sh, F=lsDFMeu, A=sh -c $u Mlocal, P=/bin/sh, F=lsDFMeu, A=sh -c $u R<"|/... Vulnerable | mail postmaster@dummyname.org"> R<"|( sleep 2 ; echo quit ) |teln et 0.12.253.120 5701" Mar 21 13:52:52 dummyname.org sendmail[6568]: NOQUEUE: POSSIBLE ATTACK f rom ip192.isdn5.new-york4.ny.psi.net: newline in string "iss Croot Mprog, P=/b in/sh, F=lsDFMeu, A=sh -c $u Mlocal, P=/bin/sh, F=lsDFMeu, A=sh -c $u R<"|/... g Vulnerable | mail postmaster@dummyname.org"> R<"|( sleep 2 ; echo quit ) |tel net 0.12.253.120 570" Mar 21 14:01:26 dummyname sendmail[6947]: NOQUEUE: POSSIBLE ATTACK f rom ip192.isdn5.new-york4.ny.psi.net: newline in string "iss Croot Mprog, P=/b in/sh, F=lsDFMeu, A=sh -c $u Mlocal, P=/bin/sh, F=lsDFMeu, A=sh -c $u R<"|/... Vulnerable | mail postmaster@dummyname.org"> R<"|( sleep 2 ; echo quit ) |teln et 0.12.253.120 5701"
This next item seems to be an attempt to send in mail from a non-existent domain:
May 22 02:02:26 firebox sendmail[9573]: CAA09573: ruleset=check_mail, arg1=<cdof fer@apmail.com>, relay=promit@promit.im-www.com [192.41.27.132], reject=501 <cdo ffer@apmail.com>... Sender domain must exist
In this case, DNS failed to find the domain apmail.com
and rejected
the mail. However, a subsequent check with nslookup
showed that the
domain did, in fact, exist. There may have been a temporary DNS
problem for their particular site, although DNS was working
everywhere else. If you have a site with persistent DNS problems,
you may want to consider adding them to the access database as an
exception.
Testing techniques
Chapter 38 of the Sendmail book describes in wonderfully gory detail all the testing techniques for sendmail. I encourage anyone who wants to learn more (including me!) to try the techniques described. Chapter 37 is devoted to all the debugging options. Choose whichever suits you. Typically, I use the following:
/usr/lib/sendmail -bt -d35.9 -C/path/to/new/config/file.cf
This produces a lot of output, complete with all the macro definitions (see last month's column for an example). There are some pretty neat things you can do
in test mode. At the >
prompt, enter ?
, and it should give you all the available functions. If it doesn't, make sure you've installed the sendmail.hf
file:
# cd /usr/local/src/sendmail/sendmail-8.9.3/src # cp sendmail.hf /etc/mail # /usr/lib/sendmail -bt > ? Help for test mode: ? :this help message. .Dmvalue :define macro `m' to `value'. .Ccvalue :add `value' to class `c'. =Sruleset :dump the contents of the indicated ruleset. =M :display the known mailers. -ddebug-spec :equivalent to the command-line -d debug flag. $m :print the value of macro $m. $=c :print the contents of class $=c. /mx host :returns the MX records for `host'. /parse address :parse address, returning the value of crackaddr, and the parsed address (same as -bv). /try mailer addr :rewrite address into the form it will have when presented to the indicated mailer. /tryflags flags :set flags used by parsing. The flags can be `H' for Header or `E' for Envelope, and `S' for Sender or `R' for Recipient. These can be combined, `HR' sets flags for header recipients. /canon hostname :try to canonify hostname. /map mapname key :look up `key' in the indicated `mapname'. rules addr :run the indicated address through the named rules. Rules can be a comma separated list of rules. End of HELP info >
Final thoughts
Hopefully, this series has shed some illumination on the murkiness
of sendmail. Every time I work on a new configuration I swear
"never again!" Yet I constantly discover something about sendmail
that I can't do with other MTAs. If you'd like to use sendmail, but
would like an easier interface, you may consider using the
commercial product offered by Sendmail, Inc. Unlike some other open
source software that has gone commercial and abandoned new releases
for the free version, Sendmail, Inc. should be commended for
supporting open source development.
I'd like to thank Greg Shapiro at sendmail.org
for reviewing (and
correcting!) this column and Jon Klein at Wizard's Keys Corp. for
help with the access database and TCP Wrappers portions. Finally,
much appreciation goes to Brian Martin at attrition.org
for
permitting me to publish actual log data.
Disclaimer: The information and software in this article are provided as-is and should be used with caution. Each environment is unique and the reader is cautioned to investigate with his or her company as to the feasibility of using the information and software in the article. No warranties, implied or actual, are granted for any use of the information and software in this article and neither author nor publisher is responsible for any damages, either consequential or incidental, with respect to use of the information and software contained herein.
Resources
About the author
Carole Fennelly is a partner in Wizard's Keys Corporation, a company
specializing in computer security consulting. She has been a Unix
system administrator for more than 15 years on various platforms and has
particularly focused on sendmail configurations of late. Carole
provides security consultation to several financial institutions in
the New York City area.
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-06-1999/swol-06-security.html
Last modified: Wednesday, June 02, 1999
[Copyright message from Eric Allman] divert(0)dnl VERSIONID(`@(#)mgate_org2.mc 8.9.3 (Company) 5/21/1999') OSTYPE(solaris2)dnl DOMAIN(generic)dnl FEATURE(nouucp)dnl MASQUERADE_AS(company.com)dnl FEATURE(`masquerade_envelope')dnl FEATURE(`relay_entire_domain')dnl define(`SMTP_MAILER_FLAGS', `c')dnl define(`LUSER_RELAY', `int_fw.company.com')dnl MAILER(local)dnl MAILER(smtp)dnl LOCAL_RULE_0 # if it's for the external list server, send it to the firewall R$+<@listserver.$={MyDom}.> $#smtp $@firebox.company.com $:$1<@listserver.$2> #if it's in my domain, process it locally R$+ < @ $* $={MyDom}. > $#local $: $1 # otherwise, send it to the firewall -cbf R$+ < @ $+ > $#smtp $@firebox.company.com $:$1 < @ $2 > LOCAL_CONFIG C{MyDom}company.com
int_fw_from_org1.mc
[Copyright message from Eric Allman] divert(0)dnl VERSIONID(`@(#)int_fw_from_org1.mc 8.9.3 (Wizard's Keys) 4/14/1999') OSTYPE(solaris2)dnl DOMAIN(generic)dnl FEATURE(nouucp)dnl FEATURE(always_add_domain)dnl FEATURE(allmasquerade) FEATURE(masquerade_entire_domain) FEATURE(masquerade_envelope) FEATURE(accept_unresolvable_domains) define(`LUSER_RELAY', `mgate_org2.company.com)dnl FEATURE(`smrsh', `/usr/local/etc/smrsh')dnl MASQUERADE_AS(company.com)dnl define(`SMTP_MAILER_FLAGS', `c')dnl define(`confDAEMON_OPTIONS',`Addr=10.11.12.14')dnl define(`SMART_HOST', smtp:mgate_org2.company.com)dnl define(`QUEUE_DIR',`/var/spool/mqueue_fr_org1')dnl define(`ALIAS_FILE',`/etc/mail/aliases_fr_org1')dnl MAILER(local)dnl MAILER(smtp)dnl LOCAL_RULE_0 R$+ < @ $* $={MyDom}. > $#local $: $1 LOCAL_CONFIG C{MyDom}company.com
[Copyright message from Eric Allman] divert(0)dnl VERSIONID(`@(#)int_fw_from_org2.mc 8.9.3 (Wizard's Keys) 4/14/1999') OSTYPE(solaris2)dnl DOMAIN(generic)dnl FEATURE(nouucp)dnl FEATURE(always_add_domain)dnl FEATURE(allmasquerade) FEATURE(masquerade_entire_domain) FEATURE(masquerade_envelope) FEATURE(accept_unresolvable_domains) define(`LUSER_RELAY', `mgate_org1.company.com)dnl FEATURE(`smrsh', `/usr/local/etc/smrsh')dnl MASQUERADE_AS(company.com)dnl define(`SMTP_MAILER_FLAGS', `c')dnl define(`confDAEMON_OPTIONS',`Addr=190.70.60.40)dnl define(`SMART_HOST', smtp:mgate_org1.company.com)dnl define(`QUEUE_DIR',`/var/spool/mqueue_fr_org2')dnl define(`ALIAS_FILE',`/etc/mail/aliases_fr_org2')dnl MAILER(local)dnl MAILER(smtp)dnl LOCAL_RULE_0 R$+ < @ $* $={MyDom}. > $#local $: $1 LOCAL_CONFIG C{MyDom}company.com