Site Administration Page 4 - Getting Started with Sendmail |
Problem You must keep your sendmail software up-to-date. SolutionSticking with the standard software management method used on your system is the easiest way to upgrade sendmail. If you use a package manager, go to your Unix vendor’s web site, download the appropriately packaged sendmail update, and install it using the package manager. If the vendor cannot provide a critical sendmail update or does not provide the compiled-in features you need, and you decide to use the sendmail source code distribution, gracefully transition from the package manager to the source code distribution by following the Unix vendor’s advice on how to remove a package that was installed by the package manager. The Discussion section shows an example of using the Red Hat Package Manager to remove the sendmail RPM before the sendmail source code distribution is installed. If you need to use the sendmail source code distribution, download the latest version of sendmail from ftp://ftp.sendmail.org/, from http://www.sendmail.org/current-release.html, or from one of a large number of mirror sites. A link to the mirror sites is found on the http://www.sendmail.org/ home page. The Discussion section provides an example of downloading the sendmail source code distribution via ftp. Get the signature file associated with the version of sendmail you downloaded. For example, the signature file for the sendmail.8.12.9.tar.gz tarball downloaded in the Discussion section is sendmail.8.12.9.tar.gz.sig. Download the PGP keys needed to verify the signature, and add them to your key ring (you only need to do this approximately once a year). After the PGP keys are added to your key ring, they can be used to verify the signature file of any further downloads made during that calendar year. Use the pgp or gpg programs to verify the signature of the downloaded file (the Discussion section shows an example using gpg). If you accept the signature, restore the sendmail distribution tarball file. Discussionsendmail changes frequently. When the first draft of this chapter was written, the latest release of sendmail was about 3 weeks old, and the previous release was only 11 weeks old! Does this mean you must upgrade sendmail every few months? Not at all. Yet you should keep track of new sendmail releases in order to determine when upgrading is important to you. Three reasons that system administrators choose to upgrade are: Security sendmail is a popular target for network intruders. They attack sendmail because it is a large, complex program that runs on many systems; sendmail is even run on desktop workstations that sometimes have less than adequate system administration. The weaknesses exposed by these attacks are quickly fixed in new sendmail releases. Stay informed by subscribing to the sendmail-announce mailing list to receive notices of new sendmail releases and by monitoring the Spammers Security attacks usually involve unauthorized access or denial of service. A related problem is the unauthorized use and theft of service that occurs when a spammer misuses your email system. Current sendmail releases do a much better job of preventing mail abuse than old releases did. Watch for new releases that add anti-spam features. If you can reduce spam, the world will thank you. New features Anti-spam features are not the only new features added to sendmail releases. Sometimes you may find a feature that is important enough to warrant an upgrade. For example, sendmail 8.11 added support for Transport Layer Security (TLS), which might be important to your organization. Of these three reasons for upgrading, security is the most important. If you know of a security problem, you can bet that the bad guys also know and are doing their best to exploit it. Close security holes as quickly as possible. Chapter 10 shows how sendmail can be patched to close security holes. Once you have decided to upgrade the sendmail software, you need to decide how you will do it. The easiest way to upgrade software is to use the software management tool provided with your version of Unix. A classic example of such a tool is the RPM Package Manager (RPM) that was developed by Red Hat and is used in many different Linux distributions. Tools like RPM install software packages that have already been customized for a particular Unix variant, placing the files in the proper directories and relieving the administrator of the burden of compiling the software. These tools also provide security features, such as the --verify option of the rpm command, that check the software and files for tampering during and after the installation. When you want to upgrade to a new version of sendmail, check your Unix vendor’s web site to see if it is available in their package format.* Despite the benefits of software management tools, sometimes you need to compile your own software to enable special features, and sometimes the latest version of software is not available in a package format. If you must switch to the sendmail tarball on a system where the previous sendmail installation was done by a package manager, backup the current configuration and then uninstall the current version of sendmail using the package manager before you upgrade. The example shows how to uninstall sendmail using RPM: #service sendmail stop This example is from a Red Hat 7.3 system. Start by shutting down the current sendmail daemon. Then use rpm -qa to find out which sendmail RPM packages are installed, and rpm --erase to remove each of the packages. Notice that the --nodeps option is used with the final rpm command. The --nodeps option forces rpm to erase the package, even if doing so breaks the dependencies of other packages. Removing the sendmail daemon, which is what the final rpm command does, breaks other packages that depend on the sendmail daemon. Once you install the new sendmail daemon, those packages should function again. However, the negative impact on dependencies, caused by switching from an RPM based installation to a tarball installation, is one reason why you should always try to upgrade an RPM installation with another RPM, if possible. Perform these steps to remove the currently installed sendmail after successfully compiling the new version of sendmail and before installing the newly created sendmail binaries. This uninstall step is necessary to prevent the package manager from falsely reporting errors when the package manager is used to scan the software for possible tampering. Caution should also be exercised when installing a vendor’s sendmail package on a system that already has a custom sendmail configuration. As Recipes 1.2 to 1.7 show, sendmail can be compiled with special options; however, the vendor might not provide the options you need, and the vendor package might overwrite the specially compiled sendmail binary. Bottom line: take care whenever you transition from one installation technique to another. If you’re not changing installation techniques, and you don’t use a package manager, you don’t need to be concerned with any of this before you proceed with installing the sendmail source code distribution—you can just follow the steps that are discussed below. Begin by downloading the sendmail source code distribution from http://www.sendmail.org/current-release.html, from any of the mirror sites, or from ftp://ftp.sendmail.org/pub/sendmail/. Here is an example using ftp: $ ftp ftp.sendmail.org The new release is stored in the pub/sendmail directory as a compressed tarball under the name sendmail.release.tar.gz for those who use gzip and sendmail.release.tar.Z for those who use compress. In either case, release is the current numeric release number. For example, the release number at this writing is 8.12.9, so the gzipped tarball is named sendmail.8.12.9.tar.gz and the compressed tarball is named sendmail.8.12.9.tar.Z. Next, get the signature file associated with the version of sendmail you downloaded. For example, the signature file for sendmail.8.12.9.tar.gz is sendmail.8.12.9.tar.gz.sig. Here we download it during the same ftp session: ftp> get sendmail.8.12.9.tar.gz.sig If you do not have the current sendmail PGP keys on your key ring, download the PGP keys needed to verify the signature. Here we add the following step to the ftp session to download the keys for the current year: ftp> get PGPKEYS Add the PGP keys to your key ring. In the following example, gpg (Gnu Privacy Guard) is used: $ gpg --import PGPKEYS gpg is used in this example because it is included as part of the Red Hat Linux distribution used on our sample sendmail system. Of the 11 exportable keys in the PGPKEYS file, only one is imported to our key ring. The not changed comment for the other 10 keys shows that they were already installed on the key ring. The first time you import PGPKEYS, all 11 keys will be added to the key ring. Before using the new key, verify its fingerprint, as shown here: $ gpg --fingerprint 396F0789 Compare the displayed fingerprint against Table 1-1 that shows sendmail’s signing key fingerprints.
If the fingerprint is correct, you can sign, and thus validate, the key. In this gpg example, we sign the newly imported sendmail key: $ gpg --edit-key 396F0789 Remember, it is not necessary to download and import the PGPKEYS file every time you download a new sendmail release. New keys are only added to the PGPKEYS file about once a year. After the sendmail keys have been added to the key ring and signed, you can verify the sendmail distribution tarball. Here we use the sendmail.8.12.9.tar.gz.sig signature file to verify the sendmail.8.12.9.tar.gz compressed tarball:* $ gpg --verify sendmail.8.12.9.tar.gz.sig sendmail.8.12.9.tar.gz Based on this, the distribution can be safely restored, compiled, and installed. Use tar to restore the tarball. The tarball creates a directory with a name derived from the sendmail release number. Therefore the following commands create a directory named sendmail-8.12.9 in/usr/local/src: #cd /usr/local/src The path /usr/local/src/sendmail-8.12.9 is used throughout this book. When implementing the recipes, adjust this path as appropriate for your system. See AlsoRecipe 10.4 provides a detailed example of downloading and installing sendmail patches, which are sometimes used as an alternative to downloading a full distribution. sendmail, Third Edition, by Bryan Costales with Eric Allman (O’Reilly), covers downloading the sendmail source distribution in section 2.2. PGP: Pretty Good Privacy, by Simson Garfinkel (O’Reilly), is a full book about PGP. The GNU Privacy Handbook (GPH), which is available at http://www.gnupg.org/gph/, provides detailed information about GPG.
blog comments powered by Disqus |
|
|
|
|
|
|
|