Setting up sendmail on a firewall, Part 3
June, 1999
Learn about special situations and testing techniques
Summary
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 installment covers installation, optional
features, and testing techniques. An example of configurations for a special
situation is described. (4,500 words)
| |
WIZARD'S GUIDE TO SECURITY
|
|
|
| By Carole Fennelly |
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 column into the Wizard's Guide to Sendmail.
|
Setting up sendmail on a firewall: Read the whole series!
|
|
|
To paraphrase an old saying, an example is worth a thousand words.
This month, I'll elaborate on some optional features of sendmail and
provide an example of a configuration I've used. While this example worked for
me, I am by no means stating that it is the best or only
solution to the problem. It's 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 didn't
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 wasn't
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's 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're 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 isn't world-writable. In fact, it shouldn't be
world-readable either, unless you're running a POP or IMAP server on the
firewall. Mine is owned by root and is readable only 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 isn't true on a firewall. Because there are no users actually
receiving mail on the firewall, sendmail doesn't need to read users' home
directories to look for forward or vacation files.
Therefore, it doesn't 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 config 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 shouldn't be the real one. In my recent column, "Audits
from hell," 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're using a dbm database.
A database record consists of two parts: the key and the action. The
key can be a username, 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'll 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.
If, however, the mail comes from host okay.cyberspammer.com, then
the
mail is accepted. Mail from host 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 the mail was sent
satisfactorily when in fact it wasn't.
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's 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's 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 subdomains
(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 subdomaining 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 his or her address. Yuck.
They're 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
Bryan Costales's Sendmail, Second Edition. (See Resources.)
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 emails 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 wasn't an actual attack, and in fact shows
up every time I get mail from that site. I was glad I hadn't jumped
to the conclusion that I was being attacked. (See "Chain of
Command" 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 nonexistent
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 Costales's Sendmail 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
I'll never do it 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.
|
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
|
| |
|
Return to
article
|
|
Copyright 2003, ITworld *-* Please direct questions and comments to
Carole Fennelly.
Permission is granted to quote, reprint or redistribute provided the
text is not altered, and the author and ITworld
are credited.
|
