sendmail

Electronic mail was one of the first applications to be widely adopted across the Internet, and despite changes in technology and a shift toward information delivery via the World Wide Web (WWW), e-mail has managed to hold its ground. E-mail has undergone many changes is recent years : instead of plaintext messages being sent from command-line clients (or mail user agents , MUA), there are many different mail protocols for remote clients to retrieve their mail from a centralized server (for example, POP, IMAP), as well as multimedia content being supported through MIME extensions.

Although desktop clients are technically capable of running mail servers, most organizations still prefer to run a single main mail server, running a mail transport agent (MTA), such as the traditional sendmail daemon or a newer replacement (for example, qmail). This is because server systems such as Solaris have high uptime and better security features than the average desktop client and because the security of mail services can be managed centrally . For example, if a security flaw is revealed in sendmail, a patch can be freely downloaded from SunSolve and applied to the server with minimal disruption to users. If everyone ran their own mail server, new security problems could take weeks if not months per incident to rectify in a large organization.

In this section we will examine the background to understanding how e-mail is addressed and delivered, by using the TCP transport protocol, and examine the configuration of the popular sendmail mail transport agent.

Understanding E-Mail Protocols

Transferring electronic mail between servers on the Internet is largely conducted using the Simple Mail Transfer Protocol, or SMTP. The advantage of using SMTP is that mail transfer can be initiated by a local third-party mail user agent, such as elm or pine, or it can be performed manually by a user using telnet. This makes installing sendmail somewhat easier because all mail commands can be tested interactively by a human operator, and the response to each command can be evaluated appropriately.

If your users are not logged in through a shell on the local mail server, it will be necessary for you to provide a means by which they can send and retrieve mail through the server by using a remote mail client. There are two protocols that support this: the Post Office Protocol (POP), which is the oldest client/server mail transfer protocol and only supports offline mail reading, and IMAP (the Internet Message Access Protocol), which supports both offline and online mail reading. The choice between the two will often come down to which mail user agents your users are comfortable with, and which protocol their favorite client supports. However, there can be other considerations like authentication, authorization, and security that would sway an administrator to stipulate that IMAP be used over POP, even for offline mail reading.

Tip  

It should be noted that POP is generally easier to install and configure than IMAP.

SMTP

SMTP is the Simple Mail Transfer Protocol (SMTP), which allows servers to exchange mail with each other on a message-by-message basis. Standardized since the publication of RFC 821, SMTP has become the dominant Internet mail transfer protocol at the expense of earlier transfer methods such as the ancient UUCP (Unix-to-Unix copy program) and the X.400 protocol, which is still popular with intranet and LAN-based e-mail. SMTP allows sendmail and other mail transport agents such as qmail to accept connections on port 25 and speak to each other in a language that is interpretable by humans . In fact, as we will see later, it is actually possible for an administrator to manually test sendmail by telnetting to port 25 and issuing SMTP commands directly. This is very useful for troubleshooting and testing existing configurations. Unfortunately, SMTP is almost too simple, because it can be used by malicious users to forge e-mail headers so as to make an e-mail appear to come from another user.

SMTP supports a sender/receiver model of host-to-host e-mail transactions: a host, such as mail.companyA.com , may wish to transfer a message to mail.companyB.com . The server mail.companyA.com first makes a connection to port 25, which mail .companyB.com acknowledges. Then, mail.companyA.com identifies the sender of the message, and again, mail.companyB.com acknowledges. Next , mail.companyA.com states the recipient of the message, and again mail.companyB.com acknowledges. If the local user exists, or is listed in the /etc/aliases database, the acknowledgement is in the affirmative . However, if no local user can be matched to the intended recipient, the acknowledgement is in the negative. If a user is found, the message is transmitted from mail.companyA.com to mail.companyB.com , and the latter acknowledges receipt (with a receipt number). mail.companyA.com then requests a disconnection, and mail.companyB.com complies. Mail is held on the MTA until the RECV command to retrieve the message is sent by the MUA. This transaction is shown in Figure 37-1.

Figure 37-1: Mail exchange transaction between mail.companyA.com and mail.companyB.com.

This kind of transaction is conducted millions of times every day on mail servers around the world and is very fast. In the example, each of the acknowledgements from mail.companyB.com is associated with a three-digit numeric code: for example, a successful command from mail.companyA.com is always acknowledged with a code 250 from mail.companyB.com . Alternatively, if a user is not local, the code 551 is returned.

There are a number of standard SMTP commands, which are summarized here:

• HELO Identifies the mail sending host to the mail receiving host.

• MAIL Identifies the remote user who is sending the mail to the mail receiving host.

• RCPT Indicates the local user to whom the mail is to be delivered.

• DATA Precedes the body of the mail message.

• VRFY Checks that a particular local user is known to the mail system.

• EXPN Expands local mailing lists.

• QUIT Terminates a session.

In addition to the standard SMTP commands presented here, RFC 1869 proposed extensions to SMTP, called ESMTP. ESMTP allows developers to extend the services currently provided by SMTP. MTAs that support ESMTP commands will attempt to greet each other with the EHLO command. If ESMTP is supported, a list of implemented commands on the remote server is returned. For example,

 server% telnet server.companyB.com 25 Trying 192.68.232.45... Connected to server.companyB.com. Escape character is '^]'. 220 server.companyB.com ESMTP Sendmail 8.9.1a/8.9.1; Fri, 18 Feb 2000 13:05:14 +1100 (EST) EHLO server.companyA.com 250-server.companyB.com Hello [e-mail] [192.68.231.64], pleased to meet you 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ONEX 250-ETRN 250-XUSR 250 HELP 

One example of an ESMTP command is Delivery Status Notification (DSN), which was proposed in RFC 1891 and reports on the status of remote mail deliveries to local users, just like a certified letter.

POP

Many users today do not log in directly to an interactive shell on a mail server or run a local mail client like mailx or elm; instead, they are able to use a GUI-based mail reading client that runs locally on their PC, contacting the mail server directly to retrieve and send their mail. One of the client/server protocols that facilitates this kind of mail delivery is the Post Office Protocol (POP), as codified in RFC 1725. POP supports offline mail delivery to remote clients when mail addressed to a user account is delivered via a centralized mail server. POP supports many useful features, including the ability to retain copies of e-mail on the server and transmit a copy to the client. This can be very useful for auditing and backup purposes, as a client machine may have to be reinstalled, or it may crash, in which case all of the user s mail (including unread mail) might be lost.

Tip  

Reliability of service is still one of the main arguments for using a centralized mail server.

To retrieve mail from a POP server, a client machine makes a TCP connection to port 110. The client then greets the server and receives an acknowledgement, and then the session continues until it is terminated. During this time, a user may be authenticated. If a user is successfully authenticated, they may begin conducting transactions in the form of retrieving messages until the QUIT command is received by the server, in which case the session is terminated . Errors are indicated by status codes like -ERR for negative responses and +OK for positive responses. POP is deliberately SMTP-like in its command set and operation, making it easier for administrators to apply their skills to configuring both kinds of systems.

One of the drawbacks of POP is its lack of security: although users are authenticated using their username and password on the mail server, this exchange is not encrypted ”which means that anyone snooping the network might be able to retrieve this username and password. This would allow a rogue user to log in to the mail server as the mail user, perhaps without the mail user realizing this for a long time because they themselves never log in directly to the mail server. Since telnet and ftp use exactly the same method of authentication, it s certainly no worse than the standard networking toolset.

To obtain a free POP server for Solaris, download the freeware Qpopper server from Qualcomm at http://www.eudora.com/qpopper/index.html . Alternatively, Netra systems are supplied with the SUNWipop package that provides a POP service for that platform. Qualcomm also has a free POP mail user agent called Eudora that is very popular in educational institutions, and it is available for both the Macintosh and Windows platforms. Figure 37-2 shows the main user screen from Eudora: users can retrieve their mail from a remote server and display it ordered by date, sender, and subject. In addition, files from the local Macintosh or Windows file system can be sent as attachments by using the MIME extensions. Software like Eudora makes it easy for Macintosh or Windows users to have the convenience of local file access and GUI-based interfaces while retaining the security and reliability of the Solaris server platform. However, it should be noted that browsers such as Netscape and other command-line MUAs (such as elm or pine) may be more appropriate than Eudora for some environments.

Figure 37-2: The POP-based Eudora client for Microsoft Windows, which receives mail from a : entralized and secure Solaris mail server.

IMAP

The Internet Message Access Protocol (IMAP), codified in RFC 2060, is intended to be a replacement for the POP protocol. While IMAP can perform offline processing, it is primarily intended for remote clients to retain some of the features of online processing enjoyed by MUAs like mailx and elm. A remote MUA using IMAP has the ability to perform more sophisticated transactions than a POP-based client: while POP works for requests like retrieving all new messages on the server and passing them to the client, IMAP supports requests of just header, just message bodies, or both. In addition, a search can be made for messages matching a particular criterion ”for example, a request could be made to find all messages received by a particular user, or all messages received on a particular day. Although a POP-based MUA can perform these operations on its local copy of mail messages, IMAP can perform these operations remotely on the server. In addition, server-side messages can be marked with different flags indicating whether they have been replied to, for example. Again, this reflects the kind of functionality often supplied by server-side MUAs like mailx or elm, but allows these operations to be performed by remote, easy-to-use GUI interfaces. Even if IMAP users want to store their files locally, like a POP-based service, this is also supported ”but significantly, there is a synchronization feature whereby the local mailbox contents can be regularly matched with the mailbox on the server. This ensures that no data corruption occurs due to errors on the client machine. Remote mail folders are also possible.

In summary, POP and IMAP offer significantly different functions, and the use of either protocol depends on the mail user agents that are supported and the needs of the users.

Tip  

Many mail clients only support POP, and it may be that your organization keeps with the POP platform because of this reason alone, even though IMAP offers many more features.

Mail Headers

When a mail message is delivered into a user s mailbox, it contains a history of its delivery process in the headers that precede the message body. These headers include

• From Records the mail sending user, and the date and time at which the mail was received.

• Received Provides details of how the mail was received by the MTA on the mail server, including the remote computer s name, MTA name , and identification.

• Date Indicates the time and date at which the message was received.

• Message-Id A unique number generated by the sending host that identifies the message.

• To Indicates the user to whom the message was addressed ”usually a user on the local machine.

• Content-Type Indicates the MIME type in which the message was encoded. This is usually text, but could contain multimedia types as well.

• Content-Length The number of lines making up the body of the message.

• Subject The subject of the mail message as entered by the sender.

Mail Transport

Now that we have reviewed how mail is transferred between the client and the server, we turn our attention to server-to-server mail communications. Mail exchange between servers is performed by using mail transport agents (MTAs) such as sendmail, which implement the SMTP protocol. sendmail is the most popular mail transport agent for Solaris and many other UNIX systems, even though newer systems, such as qmail make configuring an MTA easier. In this section we cannot cover all material relating to sendmail, because it is one of the most complex UNIX programs to master; however, we provide sufficient detail so that most administrators working in a standard environment will be able to configure and test their mail transfer environment.

sendmail is the standard mail transport agent that is supported by default under Solaris, although it is certainly possible to install an alternative third-party MTA like qmail (see http://www.qmail.org/ for details).

EXAM TIP  

As installed, Solaris 9 supports sendmail version 8.

In most Solaris installations, the sendmail MTA relies on a single configuration file ( sendmail.cf ), which contains sets of rules to determine how e-mail is to be sent from the local host to any arbitrary remote host, and which mailer is to be used (for example, for local vs. remote delivery). The rules are used to choose the mechanism by which each message is delivered, while mail addresses are often rewritten to ensure correct delivery. For example, a mail message sent from a server command line may not include the fully qualified domain name in the Reply-to field. This would mean that a remote user would not be able to reply to a message sent to them.

Tip  

The sendmail MTA ensures that the virtual envelopes that contain e-mail messages are addressed correctly by inserting headers where appropriate to identify senders and recipients.

Although sendmail is highly customizable, it is also difficult to configure and test because a single error in the rules can produce unexpected results. sendmail reads and processes every rule in sendmail.cf , so in order to speed up the process, the rules are written in a computer friendly format. Unfortunately, like assembly language, computer- friendly rules are rarely human friendly! In this section we will review the configuration of sendmail, and highlight some of the security issues that continue to surround its deployment. Fortunately, the public version of sendmail allows you to use simple configuration rules to create a sendmail.mc file, which is easier than working directly on the sendmail.cf file.

The sendmail.cf file consists of single-line commands, which can range from rules and macros to options and headers. Some of these commands must appear only once if they specify a directive that affects the interpretation of rules (there can, however, be many rules in a sendmail.cf file). The main kinds of commands in a sendmail.cf file are

• C Specifies a class that can contain more than one item. For instance, C{MAILCLIENTS} mars venus pluto specifies an array that contains a list of mail clients (mars, venus, and pluto).

• D Specifies a macro. For example, DR mail.companyA.com specifies a macro named R whose contents is mail.companyA.com.

• E Specifies an environment variable. As a security measure, sendmail does not use environment information passed to it, preferring to use values specified in the sendmail.cf file. To set the location of a Java Virtual Machine (VM), which may be used to support some mail- related applications, use the variable specification EJVM=/usr/local/java/bin/java.

• H Specifies a header, such as the Received: header. These definitions can be now very complex because of the inclusion of multipart MIME messages.

• M Specifies the mail delivery agent. For instance, Mlocal, P=/bin/mail specifies that /bin/mail is the mail delivery agent, which is usually the case under Solaris.

• O Specifies an option. For example, setting O SendMimeErrors=True enables the sending of MIME-encapsulated error messages.

• P Sets message precedence. For example, first class mail is set with a precedence of zero (Pfirst-class=0), while junk mail is set with a precedence of “100 (Pjunk=-100).

• R Specifies a rule. For example, the rule R$- $@ $1 @ ${Mydomain} Rewrite address appends the FQDN defined by the macro ${Mydomain}to a username.

• S Indicates the start of a ruleset, which can either be specified as a number (for example, S2 for rule-set two) or with a label (for example, SDomainRules for the DomainRules ruleset).

There are six kinds of system-defined rulesets that are contained in the sendmail.cf file:

• S0 Handles basic address parsing. For example, if a user address is not specified, an error message user address required is returned.

• S1 Processes the e-mail sender s address.

• S2 Processes the e-mail recipient s address.

• S3 Performs name canonicalization and initiates the rewriting rules. For example, invalid addresses are checked (for example, those with colons), and any angle brackets <<>> are stripped from the address.

• S4 Performs the final output postrewriting, including conversion of expanded addresses like pwatters%mail @companyA.com to [e-mail] .

• S5 The final rewriting ruleset, which occurs after all aliases, defined in /etc/aliases , have been expanded.

User-defined rulesets can occupy S6 and above. For example, ruleset 33 is defined in Solaris to support Sun s RemoteMode. A typical sendmail rule takes the form

 Rlhs     rhs     description 

where R indicates that the line is a rule, lhs is the left-hand side of the rule, rhs is the right-hand side of the rule, and description is a comment that is useful for humans to interpret what action the rule performs. The left-hand side is a specification for matching a particular mail header, while the right-hand side specifies the action to be taken if a match is found for the rule.

In the same way that lex, yacc, and JavaCC can be used for specifying actions based on matched tokens, so does the sendmail parser. When the sendmail.cf file is parsed by sendmail, it recognizes several specifiers on the left-hand side:

• $- Matches a single token.

• $* Matches any number of tokens, including zero tokens.

• $+ Matches any number of tokens greater than zero.

• $=character Matches any token equal to character.

If any rule stated using these specifiers finds a match, then one or more actions may be performed by one or more right-hand side specifiers:

• $@ Rewrite and return.

• $ > integer Rewrite using the ruleset specified by integer.

• $# Deliver through the specified mailer.

• $character and $integer Actions can be performed on variables defined on the left-hand side.

As an example, we examine a rule that adds a fully qualified domain name onto a mail server username, where a message is destined for external delivery. In this case, $h (host) is set to mail and $d (domain) is set to companyA.com . Thus, a rule to match a username with no FQDN specified would be

 R$+     $@@$h.$d     Add a FQDN to username 

Thus, any valid Solaris username like pwatters will have mail, ., and companyA.com appended to it for external delivery, giving

 [e-mail] 

A more complex rule for a more complex organization that has multiple internal networks might have a second level in the FQDN above the company name (for example, the mail server for the sales department of companyA.com would have the FQDN mail.sales.companyA.com ). In this case, we define $o (organization level), set $o to sales, and change the rule to

 R$+     $@@$h.$o.$d     Add a FQDN to username, including organization level 

Hence, any valid Solaris username like neil will have mail, ., sales, ., and companyA.com appended to it for external delivery, giving

 [e-mail] 

Thus, the combination of rules, macros, and options can successfully create and resolve most e-mail addresses. If all of the rule writing and option setting seems daunting to a first-time sendmail administrator, it is possible to use GUI-based configuration tools to ease the burden . One of the easiest ways to run and configure sendmail is to use webmin, which is freely available at http://www.webmin.com/webmin/ . webmin is a web-based interface for system administration for Solaris, including sendmail. Using any browser that supports tables and forms, you can make use of the sendmail configuration module that allows administrators to manage sendmail aliases, masquerading, address rewriting, and other features. webmin can also use SSL to secure connections between your web browser and the webmin server, which is especially useful for remote administration. Figure 37-3 shows the webmin interface and the options it supports for configuring sendmail.

Figure 37-3: Webmin GUI interface for configuring sendmail.

Running sendmail

sendmail is started as a daemon process from scripts that are usually activated during multiuser startup ( /etc/rc2 ). To stop sendmail manually, use the following command:

 /etc/init.d/sendmail stop 

To start sendmail, use this command:

 /etc/init.d/sendmail start 

Troubleshooting

Since sendmail can be a difficult program to configure, sendmail also includes some provision for troubleshooting. For example, the command

 server# sendmail bt 

causes sendmail to execute in address-testing mode, which is very useful for testing rulesets interactively before including them in a production system. Keep in mind that ruleset 3 is no longer invoked automatically in address-testing mode; thus, to test the address

 [e-mail] 

you should use the test string

 "3,0 [e-mail]" 

instead of just using

 "0 [e-mail]"! 

As a complete example:

 ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 0 [e-mail] rewrite: ruleset   0   input: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset 199   input: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset 199 returns: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset  98   input: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset  98 returns: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset 198   input: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset 198 returns: $# local $: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset   0 returns: $# local $: Paul . Watters . 1996 @ pem . cam . ac . uk > 0,3 [e-mail] rewrite: ruleset   0   input: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset 199   input: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset 199 returns: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset  98   input: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset  98 returns: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset 198   input: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset 198 returns: $# local $: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset   0 returns: $# local $: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset   3   input: $# local $: Paul . Watters . 1996 @ pem . cam . ac . uk rewrite: ruleset   3 returns: $# local $: Paul . Watters . 1996 @ pem . cam . ac . uk 

In addition to sendmail-based troubleshooting, the mailx MUA has a -v (verbose) switch, which tracks the process of mail delivery directly after mail has been sent. For example, if a message is sent from [e-mail] to [e-mail] , from the machine client.companyA.com , the process of delivery is displayed to the sender:

 client% mailx -v [e-mail] Subject: Hello Hi [e-mail]. This is a test. ^D EOT client% [e-mail]... Connecting to mailhost (mail)... 220 mail.serverB.com ESMTP Sendmail 8.9.1a/8.9.1; Sat, 19 Feb 2000 12:13:22 +1100 (EST) >>> HELO mail.companyA.com 250 mail.serverB.com Hello mail.companyA.com (moppet.companyA.com), pleased to meet you >>> MAIL From:<[e-mail]> 250 <[e-mail]>... Sender ok >>> RCPT To:<[e-mail]> 250 <[e-mail]>... Recipient ok >>> DATA 354 Enter mail, end with "." on a line by itself >>> Hi [e-mail]. This is a test. >>>. 250 Ok >>> QUIT 221 mail.companyB.com closing connection [e-mail]... Sent (Ok) 

In the previous example, the local mail server ( mail.companyA.com ) contacts the remote mail server ( mail.companyB.com ) and delivers the mail correctly to the user. Used in this way, mailx can provide immediately useful hints for users and administrators to identify delivery problems with particular user addresses or remote network problems.

Since e-mail is a key Internet service, and since sendmail is the most widely deployed MTA, it is often associated with security warnings and issues. This has led some developers to develop alternative MTA systems like qmail, while many organizations worldwide devote the appropriate resources to tracking down and solving bugs in sendmail. If you are a sendmail administrator, it pays to watch the headlines at sites like the Sendmail Consortium ( http://www.sendmail.org/ ).

For example, sendmail has been shown to suffer from the buffer overflow problem that allows remote users to execute arbitrary commands on a server running sendmail. This is a common problem for UNIX applications written in the C language, but only if proper bounds checking on array sizes is not correctly implemented. In the case of sendmail, very long MIME headers could be used to launch an attack ”a patch is available that allows sendmail to detect and deny messages that might be associated with such an attack. If you need to apply the patch, it is available at ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.9.1a.patch .

m4 Configuration

The m4 macro language can be used to create a sendmail.cf file by making use of a set of predefined macros that have been developed for use with sendmail. In order to create a sendmail.cf file using m4 macros, a text file containing a list of macros to run (and the appropriate parameter values for your site) needs to be created in a text file, typically called sendmail.mc . Once this file has been installed into the cf/cf subdirectory underneath the main sendmail directory, the following command can be used from that directory to build a new sendmail.cf file:

 # cp /etc/sendmail.cf /etc/sendmail.orig # m4 ../m4/cf.m4 sendmail.mc > /etc/sendmail.cf 

The first command backs up the current production sendmail.cf file, while the next command builds a new production sendmail.cf file. Once sendmail has been started, by using the command defined in the previous section, sendmail will be running with the new configuration.

Let s take a closer look at the macros and parameters that can be used to configure sendmail, before examining a sample sendmail.mc file.

Macros

The following macros are defined for use with sendmail.mc :

• DOMAIN Used to define common elements for mail servers with the same domain name.

• EXPOSED_USER Prevents domain masquerading for specific users.

• FEATURE Enables a specific sendmail feature.

• MAILER Specifies the mail delivery program to use on the server (local, smtp, or procmail).

• MASQUERADE_AS Inserts an effective domain on all outgoing e-mail rather than the real domain.

• OSTYPE Defines the host operating system type.

Features

Once the basic domain and operating system parameters have been generated, the next step is to enable specific sendmail features by using the FEATURE macro. One instance of FEATURE is required for every feature that is to be enabled. Commonly used features include

• accept_unqualified_senders Accepts messages for delivery from users with e-mail addresses that do not have a fully qualified domain name.

• accept_unresolvable_domains Accepts messages for delivery from users with e-mail addresses whose fully qualified domain name is not resolvable.

• access_db Enables a database of senders and domains to be maintained from whom mail is automatically bounced or rejected.

• always_add_domain Inserts the domain onto all e- mails sent through sendmail, even those that are being delivered to local users.

• blacklist_recipients Defines a list of recipients who are not allowed to receive e-mail.

• domaintable Substitutes a new domain name for a previous domain name.

• mailertable Allows a different mail server to be associated with each virtual domain supported.

• nullclient Allows local sendmail instances to forward all messages to a single outbound sendmail server for delivery.

• promiscuous_relay Allows relaying of mail from any site through the local server. This should never be used because of the risk that SPAM merchants will find your server and use it to relay SPAM, thereby obscuring its true origin.

• redirect Redirects messages destined for users who no longer exist on the system. Requires a corresponding entry in /etc/aliases with the name of the former user and his or her new e-mail address.

• relay_based_on_mx Uses the MX record defined in DNS to determine if the local sendmail server is the correct server to relay messages from other servers.

• relay_entire_domain Permits all hosts within the local domain to route e-mail through the local sendmail server.

• smrsh A functionally limited shell that can be used to restrict system access by the sendmail daemon.

• use_ct_file Prevents users from changing the username part of their e-mail addresses on outbound e-mails.

• use_cw_file Contains a list of all DNS aliases for the mail server.

• virtusertable Supports routing of e-mail for user accounts with the same username that actually belong to different virtual domains. Thus, [e-mail] is not confused with [e-mail] , even though both domains use the same sendmail instance.

Parameters

Specific parameters can be set for sendmail s operation with the m4 define command. Although most of the values set by default within sendmail will be satisfactory for normal use, you may occasionally need to change a value. sendmail defines a very large number of parameters, but we ll only examine some of the most commonly modified parameters here:

• confDOMAIN_NAME If your DNS server is unreliable, you might want to set the default domain name here.

• confLOG_LEVEL Specifies the logging level for sendmail from 0 (minimal) to 13 (everything).

• confMAILER_NAME The alias used for returning messages and other automatically generated mails sent by the system. This is generally set to MAILER-DAEMON, which is typically aliased to root. (So, it s possible to just set the value to root.)

• confMAX_MESSAGE_SIZE The maximum size, in bytes, of any message that is accepted for delivery. Although large attachments are common these days, an upper limit of a few megabytes should be set to prevent a denial of service attack.

• confSMTP_LOGIN_MSG Replaces the standard sendmail version banner with a local (usually nondescript) message. Can be useful in preventing would-be crackers from attempting an exploit that is specific to your version of sendmail.

Sample sendmail.mc File

Here, we define a sample sendmail.mc file that contains some of the parameters, features, and macros that we ve discussed previously:

 OSTYPE('solaris2') define('confDOMAIN_NAME', 'cassowary.net') define('confLOG_LEVEL', '13') define('confMAILER_NAME', 'root') define('confMAX_MESSAGE_SIZE', '1048576') define('confSMTP_LOGIN_MSG', 'No Name Mail Server') FEATURE('smrsh','/usr/sbin/smrsh') FEATURE(redirect) FEATURE(always_add_domain) FEATURE(blacklist_recipients) FEATURE('access_db') 

There are more extensive examples for many different configuration files supplied with the sendmail source. In particular, Eric Allman s excellent README file should be read by anyone who is seriously contemplating extensive sendmail configuration.

Example SMTP Transaction

In this section we will walk through an actual SMTP session so that you can see how straightforward the procedure is. For example, it is possible to initiate message transfer from a client machine to a user on server.companyB.com by using the following commands:

 client% telnet mail.serverB.com 25 Trying 192.68.232.41... Connected to mail.serverB.com. Escape character is '^]'. 220 mail.serverB.com ESMTP Sendmail 8.9.1a/8.9.1; Fri, 18 Feb 2000 10:25:59 +1100 (EST) 

If you now type

 help 

you will receive a list of SMTP commands that can be used to transfer mail interactively:

 214-This is Sendmail version 8.9.1a 214-Topics: 214-    HELO    EHLO    MAIL    RCPT    DATA 214-    RSET    NOOP    QUIT    HELP    VRFY 214-    EXPN    VERB    ETRN    DSN 214-For more info use "HELP <topic>". 214-To report bugs in the implementation send email to 214-    [e-mail]. 214-For local information send email to Postmaster at your site. 214 End of HELP info 

To actually send a message, you can use a combination of the HELO, MAIL, RCPT, and QUIT commands. HELO introduces the hostname that you are connecting from:

 HELO client.companyB.com 250 server.companyB.com Hello client.companyB.com [192.68.232.45], pleased to meet you 

Next, you need to specify a sender using the MAIL command:

 MAIL FROM: <[e-mail]> 250 <[e-mail]>... Sender ok 

A recipient for the mail should then be specified by the RCPT command:

 RCPT TO: <[e-mail]> 250 <[e-mail]>... Recipient ok 

After transmitting the sender and recipient information, it s then time to actually send the body of the message by using the DATA command:

 DATA 354 Enter mail, end with "." on a line by itself Hello, My mail client is not working so I had to send this message manually  can you help? Thanks. . 250 KAA11543 Message accepted for delivery 

After the message has been accepted for delivery, you can then terminate the session by using the QUIT command:

 QUIT 221 server.company.com closing connection Connection closed by foreign host. 

The message has now been successfully transmitted.

Mail Headers

These headers are useful in understanding how mail is transferred. For example, if a message is sent from a mail client on the local server to another user on the local server, the headers are easy to interpret:

 From [e-mail] Fri Feb 18 13:31 EST 2000 Received: (from pwatters@localhost)         by mail.companyA.com (8.9.1a/8.9.1) id NAA17837         for pwatters; Fri, 18 Feb 2000 13:31:34 +1100 (EST) Date: Fri, 18 Feb 2000 13:31:34 +1100 (EST) From: WATTERS Paul Andrew <[e-mail]> Message-Id: <[e-mail]> To: [e-mail] Subject: Testing Local Delivery Content-Type: text Content-Length: 5 This is a test of local delivery. 

These headers can be interpreted thus: the local user pwatters@localhost sent the remote user [e-mail] a five-line message, encoded as text, on the subject of Testing Local Delivery . The message had an ID of 200002180231.NAA1783 [e-mail], and was serviced by the sendmail MTA version 8.9.1a/8.9.1. If mail is forwarded from another host, the headers become more complicated but follow the same general principles.

Using the Multipurpose Internet Mail Extensions (MIME)

As we saw in the previous example concerning mail headers, there was a Content-Type that was text, but which could have conceivably been any kind of digital medium, thanks to the Multipurpose Internet Mail Extensions (MIME), as proposed in RFC 2045. MIME is very useful for sending multimedia files through e-mail, without having to worry about the specifics of encoding. Since many multimedia files are binary, and e-mail message bodies are transmitted as text, MIME suggests that these files be encoded as text and sent as a normal message. In addition, MIME supports the notion of multipart messages ”that is, a single e-mail message may contain more than one encoded file. This is very useful for sending a number of documents to another user. It is not necessary to overburden sendmail by sending a new message for each document (recall that sendmail processes e-mail messages one at a time).

Tip  

MIME also provides supports for languages that are encoded in ASCII but need to be displayed in another script (for example, Japanese kanji).

MIME defines how a Content-Type header can be used to specify a particular character set or other nontextual data type for an e-mail message. For example, the e-mail header

 Content-Type: text/plain; charset=us-ascii 

indicates that the message consists of plaintext in the US-ASCII character set. MIME also specifies how to encode data when necessary. In addition, MIME stipulates that it is the responsibility of the receiving user to interpret the encoded information, in order to correctly display an encoded message in a form that will be understood by the user. Here is example MIME-encoded message:

 This is a multi-part message in MIME format. ------=_NextPart_000_01A6_01BF7314.FF804600 Content-Type: text/plain;         charset="iso-8859-1" Content-Transfer-Encoding: 7bit Joe, Just confirmed the latest sales figures. See the attached report. Jane ------=_NextPart_000_01A6_01BF7314.FF804600 Content-Type: application/msword;         name="report.doc" Content-Disposition: attachment;         filename="report.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAmQAAAAAAAAAA EAAAmwAAAAEAAAD+////AAAAAJcAAACYAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// 

After the headers are printed, indicating the number and type of attachments, the actual encoded data is printed (which is what all the forward slashes represent, in case you were wondering!). When you run metamail on this file, because it contains MIME encoded data, the user is prompted to save any detected attachments:

 This message contains data in an unrecognized format, application/msword, which can either be viewed as text or written to a file. What do you want to do with the application/msword data? 1 -- See it as text 2 -- Write it to a file 3 -- Just skip it 

At this point, the user enters 2 , and they are then prompted to save the file:

 Please enter the name of a file to which the data should be written (Default: report.doc) > 

The data is then saved to the file specified. MIME is thus very useful for encoding data from several binary files into a portable format that can be transmitted as an e-mail message. Of course, handling MIME manually is not as easy as GUI mail readers, where attachments can be decoded automatically. However, this automation has led to the proliferation of viruses and numerous Trojan horses on some operating systems.