Why Do I Need sendmail?





Why Do I Need sendmail?

figs/moderate.gif figs/hack49.gif

As an end user, you've probably asked yourself: "If all I'm doing is running a FreeBSD machine for personal use, why should I need to run a heavyweight MTA daemon like sendmail?"

sendmail is the standard Mail Transport Agent (MTA) on FreeBSD, as it is on most Unix systems. In fact, the majority of email passing over the Internet will probably travel through a sendmail server at some point. However, sendmail isn't the easiest software package to manage, and the configuration file syntax gives most people a headache. There are several alternative MTA packages available, but these are also industrial-strength programs suitable for demanding use.

Many modern graphical email clients, such as Netscape Mail or Evolution, can send email directly to a mail server machine across the network. So, no, you won't need an MTA on your local machine to send email. (However, you will need an MTA if you use one of the more traditional Unix mail clients, such as mail, mutt, or pine.)

Regardless of your email client, if you want to see any automatic emails the system sends—usually from the periodic scripts—then you do require an MTA. More precisely, Unix programs expect to be able to send email by piping its text into the standard input of /usr/sbin/sendmail, and have the system take care of the rest of the work for them.

The venerable sendmail is only one of many MTAs available. Choosing another MTA does not always mean that you need to change the habits you picked up while working with sendmail. All three major BSD systems have a translator file, /etc/mailer.conf, that identifies which commands to execute when the user or another process executes sendmail, mailq, or newaliases.

For example, if you install postfix, you still use the sendmail command, even though the real job is done by the commands from the postfix package. The existence of /etc/mailer.conf makes it easy to replace one MTA with another without turning the whole mail subsystem upside down.


1 Closing Port 25

Since most systems aren't mail servers, you can disable the receiving of email. In other words, there's no reason to have sendmail listening on port 25 on any exposed interface.

Port 25 must be open on SMTP mail servers, but it does not have to be open in order to send an email as a client. Remember, any unnecessary open port is a potential security risk.


It is possible to close port 25 (except on the loopback interface) and still allow sendmail to run occasionally in order to process outgoing messages. Add the following line to /etc/rc.conf:

sendmail_enable="NO"

With the release of sendmail-8.12.2 in 2002, sendmail has been split into two parts, each with a separate configuration file. These are the MTA process, which uses SMTP to copy the mail from machine to machine, and the Mail Submission Process (MSP), whose job is to read in the complete text of any new email and reliably inject it into the MTA. When programs run /usr/sbin/sendmail, they interact with the MSP.

You can either run an MTA process locally or not run it at all, configuring the MSP to deliver straight to the MTA on your provider's smart host. In order to deliver any email, it has to pass from the MSP to an MTA. The MSP talks SMTP to the MTA to do that, which requires the MTA to be listening on port 25.

2 Simple sendmail Configuration with a Local MTA

Setting sendmail_enable="NO" in /etc/rc.conf does not turn off sendmail—use sendmail_enable="NONE" for that—but it does stop sendmail from receiving incoming email. In fact, sendmail_enable="NO" will result in starting up two sendmail processes: an MSP queue manager and an MTA process that listens on the loopback address only. Having the MTA listen only on the loopback interface means that it can be accessed only from the local machine. This is an acceptably secure compromise between having port 25 open generally and not having access to the local MTA at all.

If you want to send emails to external recipients, edit the sendmail configuration file slightly to tell it the name of your provider's email smart host:

# cd /etc/mail

# cp freebsd.mc `hostname`.mc

where `hostname` turns into the system's hostname.

Open <hostname>.mc in your favorite editor. Change the line that says:

dnl define(`SMART_HOST', `your.isp.mail.server')

to read:

define(`SMART_HOST', `smtp.yourprovider.net')

Replace smtp.yourprovider.net with the correct name of your provider's SMTP server. dnl stands for "Delete until New Line"—it's used to comment out text in .mc files, so this change simply uncomments an example line in the default .mc file. Note that in .mc files, the left tick (`) is different from the right tick (').

By default, the submission port (587) is also open. This port is part of the SMTP standard, but there is very little application support at the moment, so you won't miss it if you close it. Add this line to your hostname.mc:


FEATURE(no_default_msa)dnl

Now process the .mc file into a .cf file, and install and activate it:

# make

# make install

# make restart-mta

You don't need to make any changes to the default sendmail MSP configuration. This setup will send all messages for nonlocal users to the provider's smart host for processing. It doesn't provide any means of receiving incoming emails over the network.

3 Simple sendmail Configuration Without a Local MTA

Instead of running both a sendmail MSP queue runner and a sendmail MTA process, an alternative is to use just an MSP queue runner. Don't worry about the sendmail MTA, as you're not using it. In addition to sendmail_enable="NO", add these lines to /etc/rc.conf:

sendmail_submit_enable="NO"

sendmail_outbound_enable="NO"

You'll also need to customize the sendmail configuration slightly, this time for the MSP rather than the MTA.

# cd /etc/mail

# cp freebsd.submit.mc submit.mc

Change the last line in submit.mc from:

FEATURE(`msp', `[127.0.0.1]')dnl

to:

FEATURE(`msp', `smtp.yourprovider.net')dnl

where, as before, smtp.yourprovider.net is your ISP's mail smart host.

Then, install and activate the new configuration:

# make

# make install

# make restart-msp

Again, this will permit you to send email anywhere in the world, but not to receive incoming messages. This differs from the preceding "with MTA" configuration, in that this has to send all outgoing messages—without exception—through the provider's smart host. In return, there is no longer a sendmail process listening on port 25.

A third alternative to send-only SMTP i s ssmtp, which is available in the FreeBSD ports collection or from source at the main web site. You can find detailed instructions in Bill Moran's "Setting up to send only" article at http://www.potentialtech.com/wmoran/outgoing-only.html.


4 See Also


     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows