The setup_sendmail script is used to enable the sendmail daemon. This allows the Network Security Toolkit probe to transmit email in a standard manner.
The setup_sendmail script was added
starting with the 1.0.5 release of the
Network Security Toolkit.
When you use the setup_sendmail script, you will have the option as to whether you want to appear as a SMTP server to the rest of the network. You should NEVER enable this option if your probe is accessible from the network. Doing so would most likely result in your Network Security Toolkit probe being used as a mail relay host for spammers.
In a typical situation, you would invoke this script without any arguments and it would then enable the sendmail daemon such that the Network Security Toolkit probe would then be able to send mail out (other systems on the network would not be able to use the service).
Figure 3.8. setup_sendmail Typical Usage
[root@probe root]# setup_sendmail
Starting sendmail: [ OK ]
Starting sm-client: [ OK ]
[root@probe root]#
Help can be found from the script using the
--help option. Most likely you would want to
pipe the results into less (like:
sendmail --help | less). The resulting help
is shown in its entirety below:
Figure 3.9. setup_sendmail Help Output
[root@probe root]# setup_sendmail --help
Usage:
setup_sendmail [-d DOMAIN] [-f HOST] [--relay] [-h|--start|--setup|--remove]
Typically, one just runs this command without any command line
options to configure the NST probe for the sendmail service and to
then start up the sendmail service. Once started, you can verify
that sendmail is working properly with a command like:
echo "$(date): Test sendmail" | sendmail -v user@domain.com
For a more thorough test of your sendmail settings, try using
test_sendmail.
If you want client machines on your network to be able to use the
probe like a SMTP server, you will need to include the --relay
option.
The following example enables the probe to act like a SMTP server
and to use the "Smart Host" option enabling sendmail to forward the
processing to stmp-server.indy.rr.com:
setup_sendmail --relay --smart-host smtp-server.indy.rr.com
If you just need to temporarily enable/disable the sendmail service,
you can use:
/etc/rc.d/init.d/sendmail start|stop
If you are completely done with the sendmail service, you can stop
it and clean up the files involved with mail via:
setup_sendmail --remove
Where:
-h | --help
Displays this help screen
-d DOMAIN | --domain DOMAIN
Used to specify the fully qualified domain name which can be
resolved to a IP address. The sendmail daemon will not send out
mail if this name can not be resolved. If omitted, we will
make our best guess using getipaddr.
--relay
If you want the SMTP service to be public you need to specify
this option. WARNING: This will enable your probe to be used as a
mail transport agent by any system which can connect to it. You
should NEVER specify this option if your probe is running outside
of a firewall as it would allow anyone to use it as a mail relay
host. You typically don't use this option unless you need a
running SMTP server to diagnose email issues of clients on your
network.
-f HOST | --smart-host HOST
This corresponds to the "Smart" relay host option (DS) in the
/etc/mail/sendmail.cf configuration file. It can be useful if you
need to forward the mail processing to another SMTP server
(typically at your ISP). For example, I've found that I need to set
it to smtp-server.indy.rr.com in order to get all of my email
out.
--start
This is the default (if you don't specify any commands). Causes
any previously started sendmail stuff to be stopped and cleaned
up (mail queues are nuked). It then configures the system for the
sendmail daemon and starts it up.
--setup
This is similar to the start command except that the sendmail
deamon isn't actually started. When your ready to start the
daemon, you'll need to run:
/etc/rc.d/init.d/sendmail start
--remove
This stops any running sendmail daemon and then removes all of
the configuration, log, spool and links associated with the
sendmail service.
[root@probe root]#
Once setup, the script will create the standard /etc/rc.d/init.d/sendmail script. You can use this script if you need to temporarily stop or start the sendmail service.
Figure 3.10. Stopping sendmail
[root@probe root]# /etc/rc.d/init.d/sendmail stop
Shutting down sendmail: [ OK ]
Shutting down sm-client: [ OK ]
[root@probe root]#
Figure 3.11. Starting sendmail
[root@probe root]# /etc/rc.d/init.d/sendmail start
Starting sendmail: [ OK ]
Starting sm-client: [ OK ]
[root@probe root]#
If you want to stop the sendmail
service and remove all of the associated files and links that
were placed into RAM, you can invoke the
setup_sendmail script with the
--remove option.
Figure 3.12. setup_sendmail Removal Of Service
[root@probe root]# setup_sendmail --remove
Shutting down sendmail: [ OK ]
Shutting down sm-client: [ OK ]
[root@probe root]#
Once you have the sendmail daemon running, there are several places you can look to check on its status. This might be necessary if mail is not being routed as you hoped (trust me, getting sendmail properly configured for your environment can be a bit tricky). Here are some useful ideas when tracking down problems:
You can invoke the mail command directly from the command line (as shown above) to send a test message to a specific email address.
The mailq command will show you how many messages are currently queued up for processing by the sendmail daemon.
/var/log/maillogYou will find error messages reported by the
sendmail daemon in the
/var/log/maillog file. If no errors
have occurred, the file will be empty.
/var/spool/mail/rootIf any outbound mail bounces back, the
/var/spool/mail/root file will be
created and contain a log of the bounced messages. This
file will not exist until the first bounced message
occurs.
/etc/mail/sendmail.cfThis is the main configuration file for the sendmail daemon. If you need to tweak your sendmail rules, you will need to edit this file (trust me - you won't really WANT to edit it). After editing this file you will need to start/stop the sendmail service. WARNING: This file is removed/replaced each time the setup_sendmail script is invoked - so make a backup copy if you choose to edit it by hand.
You will find a test_sendmail script
available to help test your sendmail
setup. It will attempt to send a email note to
vpn@localdomain plus all other email
addresses listed on the command line. It then examines the log
and spool files to see if it looks like the email notes were
successfully delivered. It is recommended to pass both a
external email address AND and email address you have access
to at your ISP. For example, the usage
below demonstrates how I might use the
setup_sendmail script for the
indy.rr.com ISP and then
use the test_sendmail script to verify that
mail can be delivered to user accounts on the Network Security Toolkit probe, a
user account at the ISP, and a user account
outside of the ISP (note, if you omit the
domain on a email address to the
test_sendmail script, it will default it to
the domain returned by getipaddr
--public-domain).
Figure 3.13. Using test_sendmail to Check sendmail Configuration.
[root@probe root]# setup_sendmail -f smtp-server.indy.rr.com
Starting sendmail: [ OK ]
Starting sm-client: [ OK ]
[root@probe root]# test_sendmail root@localdomain fake@bogus.com pindy
Generating email messages with date stamp: 2004-06-23 17:12:24
========================================================================
Sending email message to: vpn@localdomain...
Version 8.12.8
Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX
MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6
NETUNIX NEWDB NIS PIPELINING SASL SCANF STARTTLS TCPWRAPPERS
USERDB USE_LDAP_INIT
Canonical name: probe.localdomain
UUCP nodename: probe
a.k.a.: probe.localdomain
a.k.a.: [192.168.0.3]
============ SYSTEM IDENTITY (after readcf) ============
(short domain name) $w = probe
(canonical domain name) $j = probe.localdomain
(subdomain name) $m = localdomain
(node name) $k = probe
========================================================
vpn@localdomain... Connecting to [127.0.0.1] via relay...
220 probe.indy.rr.com ESMTP Sendmail 8.12.8/8.12.8; Wed, 23 Jun 2004 17:12:24 -0500
>>> EHLO probe.localdomain
250-probe.indy.rr.com Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
>>> MAIL From:<root@probe.localdomain> SIZE=161
250 2.1.0 <root@probe.localdomain>... Sender ok
>>> RCPT To:<vpn@localdomain>
>>> DATA
250 2.1.5 <vpn@localdomain>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 i5NMCOjG003788 Message accepted for delivery
vpn@localdomain... Sent (i5NMCOjG003788 Message accepted for delivery)
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 probe.indy.rr.com closing connection
========================================================================
Sending email message to: root@localdomain...
Version 8.12.8
Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX
MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6
NETUNIX NEWDB NIS PIPELINING SASL SCANF STARTTLS TCPWRAPPERS
USERDB USE_LDAP_INIT
Canonical name: probe.localdomain
UUCP nodename: probe
a.k.a.: probe.localdomain
a.k.a.: [192.168.0.3]
============ SYSTEM IDENTITY (after readcf) ============
(short domain name) $w = probe
(canonical domain name) $j = probe.localdomain
(subdomain name) $m = localdomain
(node name) $k = probe
========================================================
root@localdomain... Connecting to [127.0.0.1] via relay...
220 probe.indy.rr.com ESMTP Sendmail 8.12.8/8.12.8; Wed, 23 Jun 2004 17:12:24 -0500
>>> EHLO probe.localdomain
250-probe.indy.rr.com Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
>>> MAIL From:<root@probe.localdomain> SIZE=164
250 2.1.0 <root@probe.localdomain>... Sender ok
>>> RCPT To:<root@localdomain>
>>> DATA
250 2.1.5 <root@localdomain>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 i5NMCOjG003797 Message accepted for delivery
root@localdomain... Sent (i5NMCOjG003797 Message accepted for delivery)
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 probe.indy.rr.com closing connection
========================================================================
Sending email message to: fake@bogus.com...
Version 8.12.8
Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX
MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6
NETUNIX NEWDB NIS PIPELINING SASL SCANF STARTTLS TCPWRAPPERS
USERDB USE_LDAP_INIT
Canonical name: probe.localdomain
UUCP nodename: probe
a.k.a.: probe.localdomain
a.k.a.: [192.168.0.3]
============ SYSTEM IDENTITY (after readcf) ============
(short domain name) $w = probe
(canonical domain name) $j = probe.localdomain
(subdomain name) $m = localdomain
(node name) $k = probe
========================================================
fake@bogus.com... Connecting to [127.0.0.1] via relay...
220 probe.indy.rr.com ESMTP Sendmail 8.12.8/8.12.8; Wed, 23 Jun 2004 17:12:25 -0500
>>> EHLO probe.localdomain
250-probe.indy.rr.com Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
>>> MAIL From:<root@probe.localdomain> SIZE=161
250 2.1.0 <root@probe.localdomain>... Sender ok
>>> RCPT To:<fake@bogus.com>
>>> DATA
250 2.1.5 <fake@bogus.com>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 i5NMCPjG003806 Message accepted for delivery
fake@bogus.com... Sent (i5NMCPjG003806 Message accepted for delivery)
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 probe.indy.rr.com closing connection
========================================================================
Sending email message to: pindy@indy.rr.com...
Version 8.12.8
Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX
MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6
NETUNIX NEWDB NIS PIPELINING SASL SCANF STARTTLS TCPWRAPPERS
USERDB USE_LDAP_INIT
Canonical name: probe.localdomain
UUCP nodename: probe
a.k.a.: probe.localdomain
a.k.a.: [192.168.0.3]
============ SYSTEM IDENTITY (after readcf) ============
(short domain name) $w = probe
(canonical domain name) $j = probe.localdomain
(subdomain name) $m = localdomain
(node name) $k = probe
========================================================
pindy@indy.rr.com... Connecting to [127.0.0.1] via relay...
220 probe.indy.rr.com ESMTP Sendmail 8.12.8/8.12.8; Wed, 23 Jun 2004 17:12:26 -0500
>>> EHLO probe.localdomain
250-probe.indy.rr.com Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
>>> MAIL From:<root@probe.localdomain> SIZE=191
250 2.1.0 <root@probe.localdomain>... Sender ok
>>> RCPT To:<pindy@indy.rr.com>
>>> DATA
250 2.1.5 <pindy@indy.rr.com>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 i5NMCQjG003837 Message accepted for delivery
pindy@indy.rr.com... Sent (i5NMCQjG003837 Message accepted for delivery)
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 probe.indy.rr.com closing connection
========================================================================
Checking for email message delivery errors...
Checking vpn account for email message containing '2004-06-23 17:12:24'
Success: Found '2004-06-23 17:12:24' in '/var/spool/mail/vpn'
Checking root account for email message containing '2004-06-23 17:12:24'
Success: Found '2004-06-23 17:12:24' in '/var/spool/mail/root'
Checking log file for error messages in email to: fake@bogus.com
It appears that our message to 'fake@bogus.com' was accepted.
You should check the 'fake@bogus.com' email account for a new
message containing the string '2004-06-23 17:12:24'.
Checking log file for error messages in email to: pindy@indy.rr.com
It appears that our message to 'pindy@indy.rr.com' was accepted.
You should check the 'pindy@indy.rr.com' email account for a new
message containing the string '2004-06-23 17:12:24'.
The log file: /root/test_sendmail.log has been created.
[root@probe root]#
The setup_sendmail script allows one to easily turn the Network Security Toolkit probe into a SMTP server for the LAN. This might be useful for testing client machines on your LAN. For example, you could setup Outlook on a Windows machine to use the Network Security Toolkit probe as its SMTP server. HOWEVER, you should NEVER enable this option if your Network Security Toolkit probe is exposed to everyone on the Internet (spammers would most likely discover this service and make use of your Network Security Toolkit probe to deliver their SPAM).
To enable the Network Security Toolkit probe to act as a
SMTP server for the network, add the
--relay option.
Figure 3.14. setup_sendmail as SMTP Server
[root@probe root]# setup_sendmail --relay
Starting sendmail: [ OK ]
Starting sm-client: [ OK ]
[root@probe root]# nmap 192.168.0.9
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-06-17 07:15 EST
Interesting ports on probe (192.168.0.9):
(The 1655 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
443/tcp open https
3306/tcp open mysql
Nmap run completed -- 1 IP address (1 host up) scanned in 2.694 seconds
[root@probe root]#
Notice how port 25 is now open (and accepting
connections) on my Network Security Toolkit probe after including the
--relay option.
It was discovered that setting the "smart host" option
in the /etc/mail/sendmail.cf file was
required in some situations. To the best of my understanding,
this tells the sendmail daemon that it
should not directly try to handle the mail transfer with
remote hosts, but instead pass its work to another
SMTP server to process the messages.
For example, I've found that my ISP won't allow me to send email directly from my Network Security Toolkit probe machine to accounts hosted by the ISP. My ISP does not allow users to run servers. This was a bit confusing to me as I was only sending mail out. My Network Security Toolkit probe was not accepting connections on port 25 - so in my mind I view my situation as a client and not a server. Regardless of how I viewed the situation, my ISP mail servers said "Hey, there is a sendmail server attempting to connect to us from a IP address that should not have a sendmail server running. Must be some virus infected user spewing out SPAM. We better close the connection". To work around this situation, I needed to forward the processing of my mail to my ISP's SMTP server.
It was discovered that specifying a "Smart" relay host
in the /etc/mail/sendmail.cf file could
be used in this situation. Once enabled, mail is no longer
sent directly from the Network Security Toolkit probe to the final destination,
but is instead forwarded to the "smart host" for
processing.
The following demonstrates how one would use the
setup_sendmail script in order to forward
mail processing to
stmp-server.somedomain.com:
Figure 3.15. setup_sendmail as SMTP Server
[root@probe root]# setup_sendmail --smart-host smtp-server.somedomain.com
Starting sendmail: [ OK ]
Starting sm-client: [ OK ]
[root@probe root]#
It is possible to specify both --smart-host
HOST and the --relay option to
the setup_sendmail script if your
situation warrants it.