6.6. Sendmail

Several pieces of software boast MTA capabilities, but Sendmail is probably the most well known. In its first incarnation, it was developed by Eric Allman in 1979, called Delivermail, and shipped with 4.0 and 4.1 BSD. In the early 1980s, it became known as Sendmail and is now the default mailer on most open and commercial Unix systems today.

As Sendmail was being developed, the "Internet" as we know it today was just beginning to form. TCP/IP had just been developed and communication standards were furiously being formulated to govern the ways computers should interact. It was in this wild-west environment that Sendmail was written. It was developed to implement a "general purpose internetwork mail routing facility," according to Allman's "Sendmail Installation and Operation Guide" (October 25, 1997, http://www.sendmail.org/~ca/e-mail/doc8.8/op.html) and to not rely on any one transport protocol. At the time of its development, the flexibility Sendmail offered was its greatest strength and translated directly into its rapid and widespread adoption.

In these days of ubiquitous TCP/IP networking and the universal reliance on the SMTP protocol, its flexibility (more specifically, the wealth of compiled code implementing this flexibility) is its greatest drawback.

While this bit of historical aside may seem unnecessary in a book about building OpenBSD and FreeBSD servers, bear in mind that Sendmail continues to be the default mailer on both operating systems. Cotemporary critics insist that Sendmail's long history has given rise to a massively complex mail transport system implementing a wealth of features rarely used. A system this complex is rarely fully understood by those who administer it and this lack of understanding during deployment can lead to a host of security problems. As evidence, critics offer Sendmail's long list of discovered vulnerabilities during the years.

Many administrators who eschew Sendmail in favor of alternate mailers do so without really assessing Sendmail's security posture today. In recent years, Sendmail has shown comparatively few vulnerabilities. The availability of commercial support for the product has made it a more attractive option for companies who have this as a requirement. These administrators often have little recent experience with Sendmail and choose to administer a different platform as a result of preconceived notions. As with any system, however, you should administer software you are comfortable with if you know Sendmail, feel free to use it.

6.6.1. Installation and Configuration

Sendmail is installed as the default MTA on both OpenBSD and FreeBSD systems, thus there is little to do for installation. You may recall from Chapter 3 that Sendmail will be listening on 127.0.0.1:25 by default. In order for Sendmail to work properly, you must not use the nosuid option (in /etc/fstab) when mounting the filesystems that contain your mail queue and the sendmail binary.

FreeBSD users may also choose to install Sendmail through ports instead of tracking updates to the daemon with the operating system.

If you try to install Sendmail through ports and override the PREFIX environment variable to convince the port to overwrite the base version, the installation will fail and you will be chastised. Instead, accept the default /usr/local prefix and run make mailer.conf from the mail/sendmail directory in your ports hierarchy to update /etc/mail/mailer.conf to point to the version of Sendmail installed through ports.

Whether or not your system has been recently built, your first priority in running any server should be to bring your system up to date. Because Sendmail is part of the base operating system, it will be upgraded with the rest of the system.

FreeBSD users who are tracking Sendmail through ports must not forget to upgrade that port in addition to performing a system upgrade. Be careful during the mergemaster step of the system upgrade not to overwrite the changes your port has made to /etc/mail/mailer.conf. If you choose to set NO_SENDMAIL=true in /etc/make.conf to speed up your system build, make sure you delete all existing Sendmail binaries. If you leave them behind, they will not be updated to account for vulnerabilities.

Follow the appropriate procedures to bring your system up to date; see Chapter 3 and Chapter 4 for more information. Ensuring that you are running an up-to-date version of Sendmail will go a long way toward protecting your operating system from compromise.

6.6.2. Root Background

The sendmail binary used to be a setuid root program. This means that regardless of which user was invoking the command, it would run as root. Allowing arbitrary users to run programs as root is, of course, fairly dangerous and the default was changed to a setgid binary as of Version 8.12. This allows sendmail to run as the user invoking the program, yet continue to transfer mail via SMTP or write to the client mail queue /var/spool/clientmqueue.

Another important aspect of sendmail to remember is that when root access is not needed, the binary drops privileges. Certain aspects of handling mail, of course require root privileges, for instance:

• Listening on privileged port 25 for SMTP

• Reading ~/.forward files restricted to user-only read/write access

• Writing out files owned by arbitrary users

For this kind of flexibility, sendmail must from time to time do things as root. When root privileges are not needed, sendmail will fork, drop privileges using setreuid(3), seteuid(3), or setuid(3) as available. When the child process has completed its non-root task, it exits, leaving behind the parent still running as root.

6.6.3. The Configuration Files

For administrators without years of experience configuring and tuning Sendmail, one of the keys to successful and sane configuration is to treat .cf files as binaries: don't modify them to change the configuration, modify the corresponding .mc file. OpenBSD places the source .mc files in /usr/share/sendmail/cf. Most importantly the openbsd-localhost.mc is the source of /etc/mail/localhost.cf: the default configuration file used by sendmail on OpenBSD. FreeBSD users should instead use the .mc and .cf files in /etc/mail. Additional example .mc files are located in /usr/share/sendmail/cf/cf. Details on how to modify .mc files, a background on the m4 macro language processor, etc., are beyond the scope of this book. However, these details are fully covered by the README found under /usr/share/sendmail on your FreeBSD or OpenBSD system.

6.6.4. Overall Sendmail Security

At the beginning of this chapter, we talked about three types of situations you should look out for when deploying a mail server: attacks that threaten the operating system, illegitimate mail relaying, and blocking unwanted mail. While architecture and software updates mitigate the risks, there is more work to be done in the configuration of your mail software. This section delves into some of the configuration options available to you with Sendmail. As we point out how each option mitigates risks, you can decide whether it's worth using on your servers.

6.6.4.1 File and directory permissions

It is imperative that Sendmail's binaries and configuration files have appropriate permissions. Weak permissions on files and directories can easily result in system compromise. For instance:

• Everyone who has write access to your sendmail.cf can use the program form of the F command combined with setting the DefaultUser to 0:0 to cause sendmail to execute an arbitrary script as root. If that script happens to make one of your installed shells (or a copy of a shell in /tmp, for instance) a setuid binary, anyone with local access can get root access.

• Attackers may also exploit group-writable .forward and :include: files to gain system access as the file owner.

• Protecting the aliases file alone is not sufficient as that is merely a source file to generate the alias database, a db3(3) format file called aliases.db in /etc/mail.

• Improper directory ownership can result in root-owned files being overwritten or directory owners being replaced.

To help prevent these situations, sendmail will check the permissions of all sendmail-related binaries, configuration files, and directories on the system. You can force an audit with the following command:

% sudo sendmail -v -d44.4 -bv postmaster

Observe the output closely and ensure your system does not fall prey to weak permissions. Once you have solidified the desired permissions on your system, you may want to employ some combination of file immutability and permissions auditing software like Tripwire, Osiris, or mtree(8).

6.6.4.2 Beware recipient programs

Most sendmail configuration files, including .forward files, :include: mailing lists, aliases, and the sendmail.cf configuration file itself, support the execution of arbitrary programs. We mentioned earlier that .forward and :include: mailing list files are parsed and acted upon in the user context. If you've been diligent, these files will be writable only by the owner, ensuring that the execution of programs is intentional. If you've not been careful, users could easily start running programs as other users.

Still, just the fact that these files point to arbitrary programs means you've got another problem to deal with. All of these programs have suddenly become a part of your mail system, and you'll have to audit them, too. Be especially wary of the aliases file: sendmail will take actions on this file in the daemon user context.

You might want to consider restricting users from passing incoming mail to programs by ensuring their shell as specified in the passwd files is not in /etc/shells. You may still allow login by specifying a valid shell that is not in /etc/shells: you could, perhaps, create a /bin/allow-login shell, which is a copy of /bin/tcsh, and ensure /bin/allow-login is not listed in /etc/shells.

Beware of letting users log into your mail server. Keeping an administrator-only machine secure is certainly easier than securing a system with a variety of local accounts. Consider enforcing the use of mail retrieval protocols instead of direct mail access as described previously.

There are, of course, a variety of other Sendmail-specific configuration options to consider also. One of these can help restrict what programs sendmail will execute on behalf of users.

6.6.5. Security-Related Configuration Options

6.6.5.1 Arbitrary program restriction

Sendmail comes with a variety of helper programs including smrsh(8). This "sendmail restricted shell" is meant to replace /bin/sh as the shell used by sendmail to execute programs specified in configuration files in the |/path/to/program syntax. In fact, smrsh will only execute programs located in /usr/libexec/sm.bin (by default) in addition to the shell built-in commands echo, exec, and exit.

To configure sendmail to use smrsh, thus tightly restricting users' ability to execute arbitrary programs (a good thing!), use a stanza similar to the following in your .mc file before your MAILER(`local') stanza:

FEATURE(`smrsh',`/usr/libexec/smrsh')

You will then need to link to programs that should be allowed to run. For example, to grant users the ability to pass mail into vacation(1) and procmail(1), issue these commands:

% sudo ln -s /usr/bin/vacation /usr/libexec/sm.bin/vacation % sudo ln -s /usr/bin/procmail /usr/libexec/sm.bin/procmail

6.6.5.2 Don't blame Sendmail

As of Version 8.9 of Sendmail, the daemon is more careful about overall file and directory permissions making it more difficult for the careless administrator to deploy Sendmail with weak file and directory permissions. If you're adamant about supporting permissions that sendmail does not want to tolerate, you can use the appropriately named DontBlameSendmail option. So, if your configuration changes result in an insecure installation, and your host is compromised, blame yourself instead.

If you find you have a legitimate need to loosen the restrictions sendmail imposes on file ad directory permissions, review the documentation on this option at http://www.sendmail.org/tips/DontBlameSendmail.html. Remember, instead of making configuration files group writable, use sudo(8) to tightly control and audit who makes changes to what files. This will keep you from making configuration mistakes with DontBlameSendmail, and the strong audit trail will help deter or detect would-be saboteurs.

If you must use this option, it may be compiled into your configuration file with a statement similar to the following in your .mc file:

define(`confDONT_BLAME_SENDMAIL',`GroupWritableAliasFile, IncludeFileInGroupWritableDirPath')

6.6.5.3 Masquerade your domain

Many organizations send mail internally and retain full hostnames for host-to-host mail. When the mail leaves the organization, however, these internal hostnames are no longer resolvable. In order to ensure that mail reaches the destination (because the sender's domain must resolve), it's usually a good idea to masquerade all hosts and subdomains within a domain to the top level domain.

That is, mail sent from two internal hosts taco.mexicanfood.net and salsa.condiments.mexicanfood.net should reach their destination and appear to have come from @mexicanfood.net. This configuration option is a appropriate for a mail relay and may be configured using a stanza similar to the following in your .mc file:

MASQUERDADE_AS(`mexicanfood.net') MASQUERDADE_DOMAIN(`mexicanfood.net') FEATURE(`masquerade_envelope')

These three lines ensure (in order) that mail sent from the local host is masqueraded, mail relayed through this machine from other hosts is masqueraded, and envelope information (in addition to header information) is masqueraded.

Note that usernames will be preserved and you may run into mail routing problems by collapsing your internal namespace. Thus, many organizations enforce organization-wide usernames and masquerade on the internal mail server also. If you choose to masquerade on your internal server, you will likely want to retain host information for system and service users like root and cron. To do this, use one of the following methods in your .mc file:

EXPOSED_USER(`root cron') EXPOSED_USER_FILE(`/etc/mail/masquerade-user-exceptions')

6.6.5.4 Obfuscate greeting

It is of marginal value to obfuscate the greeting (for example, the first line of Example 6-4) sendmail displays when client programs or attackers connect to port 25 on your host. Most attacks you face come from scripts, iterating through open ports looking for daemons to exploit. These scripts rarely care about what mail server you happen to be running, they will attempt the exploit regardless.

Still, some administrators prefer to give away as little information as possible. A laudable goal and if you have secured your system and Sendmail in every other conceivable way and have time left over, by all means configure an obfuscated greeting by adding a stanza similar to the following in your .mc file:

define(`confSMTP_LOGIN_MSG',`$j MexiMail Server')

6.6.5.5 Permissions of transient files

As a consequence of normal operations, sendmail will create and delete a variety of files. These files fall into two categories: temporary files and queue files. The permissions of these transient files are controlled by the TempFileMode and QueueFileMode options. Ensure that if you compile new values into the .cf files provided with the base operating system, you do so with great care.

The values of these options may be changed from the .mc file using stanzas similar to the following:

define(`confTEMP_FILE_MODE',`0600') define(`confQUEUE_FILE_MODE',`0600')

6.6.5.6 Privacy options

sendmail can be configured to be a little less helpful and a little more paranoid with the PrivacyOptions option in the sendmail configuration file. This is a particularly useful configuration item and we examine its possible values below.

authwarnings

When specified, authwarnings tells sendmail to include X-Authentication-Warning headers into mail messages when certain situations arise that are cause for suspicion. Some examples of this include: when someone used the -C switch to use an alternate configuration file, use of the -f switch to replace the sender, hostname mismatches like the one in Example 6-4, not specifying HELO/EHLO, etc. These headers are fairly unobtrusive and you may find value in looking for them with your content filters as described later in this chapter.

goaway

Shorthand specification for the following values: authwarnings, noexpn, novrfy, noverb, needmailhelo, needexpnhelo, needvrfyhelo, and nobodyreturn.

nobodyreturn

This is "no body return," not "nobody return." That is, do not return the body of the message as part of a bounce. This can be especially useful if you have to deal with a lot of spam and returning the volume of illegitimate mail is chewing up your bandwidth.

noetrn

Don't allow the SMTP EtrN command. If you are MX for an organization that has intermittent network capability and will only be able to receive mail at certain times, they may need a way to tell you to process your queue for them. These organizations could contact your mail server and issue, for instance, EtrN smtp.onlinesometimes.net. This will tell your server to process all messages in the queue that could not be delivered to smtp.onlinesomtimes.net due to network problems at last attempt. If this does not describe a situation you face, enable noetrn.

needexpnhelo

The EXPN command is a handy, but often unnecessary information disclosure, as described later in this section. The needexpnhelo option causes sendmail to reject EXPN commands unless preceded by a HELO/EHLO. There is little real security value in this option alone, and EXPN should be disabled anyway.

needmailhelo

Like the needexpnhelo option, needmailhelo requires a HELO/EHLO before the MAIL FROM command. From a security standpoint, HELO is weak and requiring it adds a little network traffic, no more.

needvrfyhelo

At this point you can surely guess what this means. Make sendmail require a HELO before honoring a VRFY. Like EXPN, VRFY is nothing but unnecessary information disclosure and should be disabled anyway.

noexpn

The EXPN command will expand local addresses. This will cause any relevant entries from a user's ~/.forward file to be printed out, or list the addresses to which the message will be delivered if the argument is an alias. The noexpn option also implies the noverb option. Use noexpn.

noreceipts

The noreceipts option primarily turns off sendmail's ability to send return receipts. In fact, this option disables delivery status notifications (DSNs) altogether. DSN is what allows sendmail to notify senders when there are problems with mail delivery and be discriminating by tailoring status notifications based on specific errors. Many users rely heavily on return receipts and administrators rely on DSNs (users seem never to read DSNs), we recommend that you do not specify this option.

noverb

This option turns on verbose processing of mail and should only be used when debugging.

novrfy

The VRFY command is another source of unnecessary information disclosure. When used, sendmail will determine whether or not the argument specified to the VRFY command represents a valid account on the system. Frankly, there are other ways of getting this information, if a little slower. Still, VRFY is not a particularly useful feature and may be safely disabled.

public

This turns off all PrivacyOptions.

restrictexpand

Think of restrictexpand as noexpn in the command-line context. This option causes sendmail to run in nonprivileged mode when run with the -bv command- line argument so that attempts to expand contents of other users' ~/.forward and :include: files fail. The restrictexpand option also disables the verbose -v command-line argument. Using this option is a good idea.

restrictmailq

When specified, this restricts the use of the mailq command so that users who wish to view the mail queue must be in the same group as the group ownership of the queue directory. This can be valuable if non-administrators have access to the server.

restrictqrun

Ensures that only root (specifically, the owner of /var/spool/mqueue, which is root unless you changed it) is able to process the mail queue with the -q command-line argument to sendmail. While this alone does not provide much greater security, forcing administrators/users to use sudo to process the mail queue will provide better auditing.

Define privacy options in your .mc file with a statement similar to the following:

define(`confPRIVACY_FLAGS', `authwarnings,noexpn,novrfy')

6.6.5.7 Running sendmail as nonprivileged users

In certain situations, sendmail should run as another user for security reasons, but there is no obvious user to choose, for example, when sendmail is executing programs or writing files specified through aliases. In this case, sendmail drops privileges and changes to the user specified in the configuration file as the DefaultUser. On FreeBSD and OpenBSD systems, this user is mailnull. This user should not be a member of any groups (other than the mailnull group) on the system, should not have a valid home directory or shell, and should be used for nothing but this purpose.

In addition, sendmail can run in a variety of different modes including a listening server on *:25, 127.0.0.1:25, or purely to de-queue messages in either the outbound queue /var/spool/mqueue or the locally submitted outbound queue /var/spool/clientmqueue. In this last case, sendmail is run with the -Ac command-line argument, which causes it to start up and use the available submit.cf as its configuration file. By default, this file specifies the option RunAsUser=smmsp. The reason for this is that the daemon only needs to process files in /var/spool/clientmqueue and send them outbound (and the clientmqueue is owned by smmsp:smmsp), so there is no reason to run as root.

Note that DefaultUser tells sendmail to use a specified non-root account when it needs to drop privilege but cannot decide which user to change to. RunAsUser, on the other hand, tells sendmail to run as the alternate user instead of root altogether. These two options may be configured from corresponding .mc files with statements similar to the following:

define(`confDEF_USER_ID', `user:group') define(`confRUN_AS_USER', `user:group')

6.6.5.8 Safe file environment

As we have discussed, sendmail is able to deliver mail to both files and programs. In fact, it can deliver mail to anything that you can specify as a path: this includes items in /dev, sockets, etc., provided it's running with the appropriate permissions. Using the SafeFileEnvironment option, you're able to simultaneously restrict sendmail from being able to write to anything other than regular files and specify a path under which all writing must be done. Obviously specifying a path of / will not restrict where on the filesystem sendmail may write, but will keep it from writing to non-regular files.

The safe file environment may be specified in your .mc file using the following stanza:

define(`confSAFE_FILE_ENV',`/home')

6.6.5.9 Trusted user

Sendmail's notion of a trusted user, specified as an argument to the TRustedUser option, allows a non-root user to manage Sendmail. This includes managing the various maps Sendmail uses and stopping (not starting!) and restarting sendmail. While this may be convenient in certain situations, the same behavior would be better achieved through the careful configuration and use of sudo to manage access rights. By default on FreeBSD and OpenBSD platforms, smmsp is the trustedUser when sendmail is processing the clientmqueue (specified in submit.cf) and root is the trustedUser otherwise.

Trusted users may be configured in an .mc file with using a stanza similar to the following:

define(`confTRUSTED_USER',`username')

6.6.5.10 Trusted users

Believe it or not, Sendmail has both trusted user and trusted users settings and they mean completely different things. Be careful when making configuration changes to either of these options. Whereas the TRustedUser is able to perform some Sendmail administration, the trusted users are only able to change the sender of a message by using the -f command-line argument. This can be useful when local mailing lists need to specify alternate sender addresses. Since SMTP has no particular restrictions on declaring From addresses, there is little real value in restricting trusted users. Still, the restrictive default is probably fine in most situations. The root, daemon, and uucp users are always listed as trusted users.

Trusted users, specified in the T class may be configured in one of the two following ways:

define(`confTRUSTED_USERS',`user1 user2 user3') define(`confCT_FILE',`/path/to/trusted-user-file')

6.6.6. Limiting Denial of Service Attacks

By default, Sendmail is not very resistant to denial of service attacks. To help mitigate the risks of these kinds of attacks, several rate-limiting options exist.

confCONNECTION_RATE_THROTTLE

Although it is difficult to devise a "reasonable" value for the number of connections sendmail should accept per second, this threshold nevertheless exists and is tunable. Fairly idle servers may make effective use of this by limiting connections to one every second. Mail administrators of servers that handle large volumes of mail will want to avoid defining this option.

confMAX_DAEMON_CHILDREN

This configuration item limits the number of children the parent sendmail process can have running at any given time. This is a more useful configuration parameter, but its value will depend on the resources available on your system. Once this limit is reached, other pending connections will be delayed.

confMIN_FREE_BLOCKS

When this threshold is reached, sendmail will cease accepting messages. The default is 100 free blocks, though you may want to increase this value to leave room for other data on the filesystem (if there is any). Remember to always monitor system disk space closely.

confMAXRCPTSPERMESSAGE

This configuration option defines the maximum number of recipients to which a message may be addressed. You may want to tune this value to a reasonable number to mitigate the risks of attacks that attempt to brute-force hundreds or thousands of usernames in one given message. Bear in mind, this is not common from spammers: UCE is usually sent with only a few recipients at most.

confMAX_MESSAGE_SIZE

The maximum size of any given message that sendmail will handle. Keep this value under 10 megabytes if you can (even as little as two or three), and provide alternatives for transporting large files to your users.

Define these options in your sendmail.mc file, rebuild your sendmail configuration files and restart sendmail.

6.6.7. Blocking Unwanted Mail

As of Version 8.9, Sendmail refuses to relay mail by default. In order for messages to pass through your mail server, they must either be destined for a domain you handle, or the sending host must be a member of one of the domains listed in /etc/mail/relay-domains. This can be further restricted by using FEATURE(`relay_hosts_only') in your .mc file requiring that the sending host itself be listed in the relay-domains file. Avoid other FEATUREs that open up relaying, as they are generally more permissive than you really want.

6.6.7.1 Access database

Sendmail supports an access database (usually /etc/mail/access) that describes actions to take with mail based on hosts, domain, email addresses, network specification, or tagged connection and envelope information. Values of these keys must be REJECT, DISCARD, OK, RELAY, or an arbitrary error message. This can be useful to ensure mail from local networks and hosts is not blocked. Some also use access databases to list domains or addresses from which a lot of spam originates. Unfortunately this is an uphill battle: as soon as you list a sending location, the same message can appear from other sources.

6.6.7.2 DNS blacklists

Sendmail can easily be configured to reject mail from sites listed in real-time blacklists (RBLs) using the FEATURE(`dnsbl'). Alone, this FEATURE will use the original RBL at http://www.mail-abuse.com/. The other services mentioned previously may also be used when supplied as arguments to this FEATURE. Instructions for setting up blacklists for Sendmail may be found at each RBL provider site.

6.6.7.3 Milters

The Mail Filter API (milter) provides a way to hook third-party content filtering tools into Sendmail. A huge variety of plug-ins that use this milter functionality already exist and more appear regularly. We refer to these plug-ins colloquially as "milters" themselves, and describe a few key milters next.

Milter capability is built into Sendmail on FreeBSD by default. In order to get milter support with your Sendmail installation on OpenBSD, perform the following steps:

# echo WANT_LIBMILTER=YES >> /etc/mk.conf % cd /usr/src/gnu/usr.sbin/sendmail % make clean obj depend && make && sudo make install % sudo mkdir /usr/include/libmilter % sudo cp include/libmilter/*.h /usr/include/libmilter

One important thing to remember about milters is that they execute inline and are not post-processing options. Thus, they have the capability to reject messages during the SMTP conversation, obviating the need to store messages on disk. Traditionally, mail post-processing had been done after delivery to a delivery agent like procmail(1).

6.6.7.4 Arbitrary content filtering

The milter-regex port in the mail directory of your ports hierarchy is your solution for "quick and dirty" content filtering. Installing this milter is as simple as a make install for both FreeBSD and OpenBSD systems. To activate this milter, add the following line to your .mc file and regenerate your .cf.

INPUT_MAIL_FILTER(`milter-regex',`S=unix:/var/spool/milters/regex.sock, T=S:30s;R:2m')

In order for this milter to work, of course, the milter-regex daemon must be running so that /var/spool/milter-regex/sock will exist when sendmail TRies to send messages there. Create a startup script milter.sh and place it in /usr/local/etc/rc.d to start milter-regex on boot with the -c argument specifying the configuration file (perhaps in /usr/local/etc/milter-regex). Place expressions in this configuration file describing the kinds of messages you'd like to block. For instance, to block all messages SpamAssassin marks with a score of 12.0 or higher, use the following expression in your milter-regex file:

reject "This really, really looks like spam to me." header /^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*/

See the milter-regex(8) manual page for more configuration details and examples.

6.6.7.5 Virus protection

Virus protection is essential to stop the flow of malware through your servers to more vulnerable client workstations and servers running Windows. Viruses and worms that exploit vulnerabilities in Unix software are uncommon, but not unheard of. A variety of commercial and noncommercial options exist including McAffee Virus Scan, Kaspersky Anti-Virus, and Clam Anti-virus (ClamAV). Perhaps the most popular choice, and the one chosen by SourceForge, is ClamAV.

Installation of ClamAV as a milter on FreeBSD is as simple as running make WITH_MILTER=YES install from the security/clamav directory in the ports tree. OpenBSD users do not have an available clamav port on the system, but an unofficial clamav port is available at http://www.fatbsd.com/openbsd/clamav/. Once installed, the clamav-milter can be started using a command similar to the following:

% sudo clamav-milter -lo  /var/spool/milters/clamav.sock

Of course, you may want to adjust where you put the socket. As with the regex milter, edit your .mc file and add a line similar to the following, and then regenerate your .cf.

INPUT_MAIL_FILTER(`clmilter',`S=local:/var/spool/milters/clamav.sock, F=, T=S:4m;R:4m')

FreeBSD users can take advantage of the installed startup scripts in /usr/local/etc/rc.d by configuring the following options in /etc/rc.conf:

clamav_clamd_enable="YES" clamav_milter_enable="YES" clamav_milter_flags="--local --outgoing --max-children=50 --quarantine-dir=/var/ quarantine --dont-log-clean --headers --postmaster-only" freshclam_flags="--daemon --checks=12" freshclam_enable="YES"

OpenBSD users may want to ensure that clamd and clamav_milter start automatically when the system boots, that the added _clamd user is aliased to a human being's mail address in the aliases file, and that the freshclam virus database update program is run periodically through cron.

Before restarting sendmail to enable ClamAV support, be sure to edit the clamav configuration file. That's /usr/local/etc/clamav.conf on FreeBSD. OpenBSD users may want to copy /usr/local/share/examples/clamav.conf to /etc/clamav.conf and edit that.

6.6.8. Authentication and Encryption

We discussed earlier that SMTP is an authentication-free protocol. By design, anyone can connect to an SMTP server and send mail that travels in clear text to the server. Certain organizations, however, who must accept and relay mail from known users on unknown and untrusted networks, need some means to verify that a user is who he says he is. One solution is the Simple Authentication and Security Layer (SASL).

Of course, authentication without encryption should send a shiver up the spine of any security-minded system administrator. Providing an encrypted channel over which authentication can occur for the SMTP exchange is handled by Transport Layer Security (TLS).

6.6.8.1 Installing Sendmail+SASL+TLS on FreeBSD

FreeBSD provides a sendmail-sasl port in mail/sendmail-sasl. A simple make install in the port directory will install the binaries in /usr/local/sbin. You will also need to make mailer.conf to activate the version of sendmail from ports.

All that is left is a little configuration.

6.6.8.2 Installing Sendmail+SASL+TLS on OpenBSD

OpenBSD administrators should first install the Cyrus-SASL port from security/cyrus-sasl2, or if you prefer, retrieve the binary package and install it using pkg_add(1). Once installed, adjust the name of the shared object in /usr/local/lib as follows:

% cd /usr/local/lib % sudo ln -s  libsasl2.so.2.11  libsasl2.so

The exact name of the library to which you must create a libsasl2.so symlink will vary based on the exact version of SASL you install on your system.

Once this is done, rebuild sendmail with SASL support as follows:

# echo WANT_SMTPAUTH=YES >> /etc/mk.conf % cd /usr/src/gnu/usr.sbin/sendmail % make clean obj depend && make && sudo make install

This will replace the Sendmail-related binaries on your system with those with SASL support, but you must still configure sendmail to use SASL and TLS.

6.6.8.3 Configuring Sendmail with SASL+TLS

To configure Sendmail to use SASL and to activate TLS support, edit the .mc source configuration file and add the following options:

define(`confCACERT_PATH',`/etc/mail/certs') define(`confCACERT',`/etc/mail/certs/CA.cert.pem') define(`confSERVER_CERT',`/etc/mail/certs/cert.pem') define(`confSERVER_KEY',`/etc/mail/certs/key.pem') define(`confAUTH_MECHANISMS',`PLAIN LOGIN CRAM-MD5 DIGEST-MD5')dnl TRUST_AUTH_MECH(`PLAIN LOGIN CRAM-MD5 DIGEST-MD5')dnl define(`confAUTH_OPTIONS',`p,y')dnl

Note that this allows "plain" logins where the users' passwords are transmitted in clear text over the network; with TLS, these clear-text passwords will be sent over an encrypted channel. Some MUAs do not properly handle any form of authentication other than plain text. If you find yourself in this position, use the PLAIN parameters, otherwise omit it. The exact location of your certificates may vary, but having at least these four certificate options defined in your .mc file will enable TLS support.

After you have modified your .mc file, rebuild your .cf file and install it. Once this is done, you must configure SASL to authenticate users in some way. Users may be authenticated against the local password file, an OpenLDAP server, a MySQL or PostgreSQL database, and so on. The details of configuring SASL are beyond the scope of this document, but a number of online HOWTOs for these topics exist.

To test SASL functionality, it may be worthwhile to use saslpasswd2(8) to create a separate authentication database and configure saslauthd(8) accordingly.

# echo "pwcheck_method: saslauthd" > /usr/local/lib/sasl2/Sendmail.conf % sudo /usr/local/sbin/saslpasswd2  testuser (follow prompts) % sudo /usr/local/sbin/saslauthd -a getpwent

You will then need to restart sendmail for SASL authentication over TLS. Note that in order for saslauthd to start at boot, OpenBSD administrators need to add appropriate lines to their /etc/rc.local script.