CompTIA Linux+ / LPIC-1 Cert Guide (Exams LX0-103 & LX0-104/101-400 & 102-400) (2016)
Chapter 17. Configuring Print and Email Services
This chapter covers the following topics:
Managing Printers and Printing
Mail Transfer Agent Basics
This chapter covers the following exam topics:
Manage printers and printing: 108.4
Mail Transfer Agent (MTA) basics: 108.3
Linux systems are often deployed as print and email servers. Both the printing and email servers are lightweight and easy to use. This makes them great candidates for small environments with limited resources, but they also find their way into larger environments where Linux-savvy people just want to get work done.
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz enables you to assess whether you should read this entire chapter or simply jump to the “Exam Preparation Tasks” section for review. If you are in doubt, read the entire chapter. Table 17-1 outlines the major headings in this chapter and the corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.”
Table 17-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping
1. Your printer, named JonathansDesk, had an error printing a document, and now CUPS has stopped the printer. How do you get jobs printing again?
a. cupsenable JonathansDesk
b. lpq -P JonathansDesk
c. cupsaccept JonathansDesk
d. cupsaccept -P JonathansDesk
2. Which of the following commands prints a file called resume.pdf to a printer called Main?
a. lpr -d Main resume.pdf
b. lp -P Main resume.pdf
c. lp -d Main resume.pdf
d. lpr resume.pdf
3. Where are CUPS configuration files stored?
a. /etc/cupsd
b. /etc/cups
c. /var/lib/cupsd
d. /var/etc/cups
4. The component of an email system that is responsible for mail delivery from one computer to another is called:
a. Mail User Agent (MUA)
b. Mail Relay Agent (MRA)
c. Mail Transfer Agent (MTA)
d. Mail Delivery Agent (MDA)
5. You configured an alias for your helpdesk, so that help@example.com goes to jonathan@example.com, isaac@example.com, and david@example.com.
After trying it out, however, the message bounces. What is the likely cause?
a. You didn’t restart your MTA.
b. You already have a help@example.com user.
c. One of the users has a .forward file that is overriding the alias.
d. You didn’t run newaliases.
6. Which of the following is not a typical Linux Mail Transfer Agent?
a. Exchange
b. Sendmail
c. Qmail
d. Postfix
Foundation Topics
Managing Printers and Printing
Despite promises of a paperless office we still live in a world that needs to print. Hooking up a printer to a computer is simple in principle, but the situation gets more complicated once you want other people printing to a shared printer.
The Linux printing system is incredibly extensible, to the point where it can detect the type of file being printed and emulate other network printing systems.
The Print Spooler
Printers have been around for a long time, as has the need to print to them over a network. When you have multiple people submitting work, called print jobs, to the same printer, you find that one person submits a print job while another job is printing. Something needs to control access to the printer so that one print job finishes before the next one starts. This is the job of a print spooler.
A spooler is also helpful in receiving the entire job from the remote computer and spoon feeding it to the printer. Without the spooler, each remote computer would be responsible for parceling out data over a relatively fast network to a much slower printer. The spooler lets the computer send the print job across the network and then forget about it.
The print spooler can manage multiple printers. Each printer has one or more print queues where the jobs are stacked up to be sent to the printer.
Network Printing Protocols
The first printing protocol to hit Unix was the line printer daemon protocol (also known as line printer remote, or LPR). This protocol is simple; a conversation between a client and a server involves a quick handshake and then the job itself. It is so simple that printers often implement the protocol themselves.
The BSD Unixes included the lpr set of tools and SysV Unixes included a similar program called lp. Both are functionally the same and vary in their command line options.
Network printing stayed the same for several years until an open source project called LPRng (Next generation of LPR) tried to improve on BSD printing. LPRng was compatible with all the BSD commands but added in new features such as an improved security model and better monitoring.
LPR is simple, but it lacked features that were becoming more important in a world where the Internet was taking hold. The Internet Printing Protocol (IPP) came out of a collaboration between Novell, Xerox, Microsoft, and Lexmark. IPP is built on top of HTTP, which is what powers the Web, so problems like authentication, encryption, and the protocol definition are already solved.
An independent developer, in parallel, started working on a better printing system for Unix. This project, called the Common Unix Printing System (CUPS) uses IPP and makes the job of managing printers much easier. CUPS was picked up quickly by Linux distributions, and the author was later hired by Apple, who also bought the rights to CUPS and continued to support its development. Fifteen years later, CUPS is the dominant printing system in Linux and Apple OSX systems.
The CUPS Daemon
The Common Unix Printing System is built around a daemon that listens for requests both from clients to print and from humans to manage the printers and queues. Data transfer is done through the Internet Printing Protocol, which is built on top of HTTP so the same daemon can do both jobs.
Print requests that come in to CUPS go through a series of conversions and filters until they land on a CUPS backend, which is akin to a printer driver. This pipeline of filters and conversions allows CUPS to accept data in different formats and print correctly on a variety of printers. For example, you can send an image file directly to CUPS, which detects it as an image and then translates it to something the printer understands. In another printing system, sending an image to the printer would end up with page after page of strange characters. You would need each application to do the translation into something the local system supports.
The CUPS Pipeline
If you can understand the way that a print job flows through CUPS, you will be in a better position to fix problems when they happen. The CUPS pipeline used to process print jobs is shown in Figure 17-1.
Figure 17-1 How CUPS processes a print job
The top of the pipeline is where jobs are received either through LPR or IPP. If the job is received as an LPR job, a small daemon is spawned to handle the connection and translate it to IPP.
The print job is received and queued for processing. Images are generally kept in their raster formats, and other file types are converted to PostScript (or kept as PS if it started out there).
Other filters are applied once the job is in either PostScript or raster. Pages can be counted for statistics or accounting purposes; pages can be resized to fit the output or shrunk to be able to fit multiple pages on a single piece of paper.
The final processing step converts the PostScript or raster file into an output suitable for the destination printer. Not all printers support PostScript, so this is where the file gets transformed into Hewlett Packard’s Printer Control Language (HP PCL) or a proprietary format.
The software in this step performs a similar role as that of a printer driver, except that most printers don’t ship with Linux drivers. Several projects have sprung up to support different printers, either by duplicating the functionality or by allowing you to upload files from the native driver. The two main projects here are Foomatic and Gutenprint. Both provide drivers for common printers, and it is likely that your printer is supported by both projects.
Finally the output is sent to the printer by whichever means is needed. The printer may be connected by USB, Serial, Parallel, or a network connection, and the CUPS backend takes care of sending it to the printer.
The final destination does not need to be a printer. The destination could be another IPP queue or a file that lets you print to a local PDF file.
This modular approach to printing lets each step handle the job it is best at. Filters do not need to know about the printer as those details are handled by another step.
Configuring CUPS
CUPS is likely installed on your system, but you can check your package manager for the cups package to see whether it’s installed. For Debian distributions that’s dpkg -s cups and for Red Hat it’s rpm -q cups.
Even though CUPS is ultimately configured with configuration files on disk, most configuration is done from within a web browser. The CUPS daemon can talk to both printers and web browsers.
Begin configuring your printer by pointing your browser to http://localhost:631. You see the welcome screen shown in Figure 17-2.
Figure 17-2 The CUPS welcome screen
From the welcome screen, select the Administration option to get the administration screen, shown in Figure 17-3.
Figure 17-3 The CUPS administration screen
This administration screen is the main place to perform CUPS configuration, such as adding and removing printers, deleting jobs, and managing who and what can print.
From the administration screen, select Add Printer from the top left of the screen. CUPS tries to detect any printers by listening to the network and checking the USB peripherals. Figure 17-4 shows a list of discovered printers, along with generic options to add nondiscovered printers.
Figure 17-4 List of discovered printers
If you are prompted to provide information in an Authentication Required pop up, provide the user name of Root and the password for the root user. Changes to CUPS require privileges not available to regular users.
Modern network-enabled printers implement a protocol called Bonjour that helps computers discover printers and other devices. The printer periodically broadcasts its availability over the network and applications such as CUPS listen for these broadcasts.
If you have a USB printer, CUPS is also able to discover it, and it will be shown alongside other discovered printers. Recall from Chapter 1, “Installing Linux,” that the lsusb command shows what USB devices are attached to the computer by looking at the /proc filesystem. This same method is used to find USB printers.
Not all network printers are discoverable. If you have such a printer, the printer’s status page should give enough details to complete the remaining steps using one of the Other Network Printers options. You are prompted for those details on the next screen.
In this example, it is the discovered network printer that is of interest. Don’t worry if you see the same printer multiple times.
Click on the Continue button to see the details about connecting to the printer, which are shown in Figure 17-5.
Figure 17-5 Viewing the printer connection settings
The Add Printer dialog shown in Figure 17-5 shows the connection settings for the printer. You can provide several pieces of information to organize your printers, most of which are already filled out for you:
The name of the printer, which is the name of the queue.
A description that helps people identify the printer when browsing for it.
The location of the printer, which is further descriptive information for people browsing.
The connection string, which CUPS does not let you edit for discovered printers. This tells CUPS how to connect to the printer over the network or a local port.
Whether or not to share the printer to other computers.
Other than the name of the printer, you can change any of the details later.
Click the Continue button to proceed to the next step of choosing the make and model of your printer.
Figure 17-6 gives you a chance to review the settings you just entered and to choose the make, or manufacturer, of your printer.
Figure 17-6 Choosing the make of the printer
If your printer happens to include a PostScript Printer Description (PPD) file, you can upload it from this page rather than choosing the make and model by clicking the Browse button to find the file on your local computer and then choose Add Printer to continue. The PPD file would be on the manufacturer’s web site or on a disk that came with the printer.
If you don’t have the PPD file, which is the more likely scenario, pick your printer manufacturer from the list and click Continue.
The next step is to choose the model of your printer, shown in Figure 17-7.
Figure 17-7 Choosing the model of the printer
Select the option associated with your printer, or choose a generic option. For example, HP printers tend to understand the Printer Control Language (PCL), so the HP LaserJet Series PCL 6 option is chosen in Figure 17-7.
If your printer is not listed, you can experiment with the generic option, or check your distribution’s package system to see whether drivers are available. For example, for an Epson printer you could run yum search Epson or look for packages with Gutenprint or Foomatic with apt-cache search gutenprint and apt-cache search foomatic.
Finally, click Add Printer and you are taken to the final step, shown in Figure 17-8.
Figure 17-8 Setting the printer’s default options
This last step, shown in Figure 17-8, allows you to set the default options for people using the printer. You can choose the Query Printer for Default Options button or choose your own options at the bottom, and then choose the Set Default Options button.
The default options set properties like the paper size and resolution. Depending on the printer, you may also be choosing a paper source or features like double-sided printing.
Select the Administration menu to get back to the main menu. You now have a printer configured.
CUPS Maintenance
The basic administration of a printer can be done from the printer’s status screen. From Administration, click on Manage Printers, and then select your printer. You can see an example in Figure 17-9.
Figure 17-9 Viewing the printer status
The key parts of this status screen are
The title, which also gives the status of the printer and the queue such as Processing, Accepting Jobs, Not Shared
The Maintenance and Administration pull-downs that let you manage the printer
The Jobs list, which shows any print jobs being printed or awaiting printing
Printer State
The state of the printer is tracked in two ways. First, the queue itself is either accepting or rejecting jobs. This refers to CUPS receiving a request to print and taking responsibility for that request. CUPS can accept a job even if the printer is off, as it will be spooled to disk in /var/spool/cups. The job prints when the printer is ready.
Next, the printer itself can be in one of a few states:
Idle—The printer is not printing anything and is awaiting work.
Processing—CUPS is currently sending data to the printer.
Stopped—An error happened with a print job, so CUPS stopped further printing to the printer.
Paused—The administrator has temporarily suspended printing to this printer.
In normal operation, a printer will be either idle or processing.
Maintenance and Administration Pull-downs
The maintenance and administration pull-downs give you several options that either perform actions or change the state of the printer.
From the maintenance menu you can
Print a test page.
Clean print heads, which is only helpful on an inkjet printer.
Print a self-test page, such as the printer’s status page.
Pause or resume the printer.
Accept or reject further jobs from the queue.
Move all jobs to another queue.
Cancel all jobs in the queue.
The difference between pause/resume and accept/reject is an important one. The queue is either in accept or reject mode. A remote client trying to print to a queue in reject mode will get an error. If the queue is in accept mode but the printer is paused, the job will be accepted but will not print until the printer itself is resumed.
The latter two options are helpful when dealing with a malfunctioning printer. There will usually be several jobs backed up, and if they’re not going to print soon you should move them to another printer or get rid of them so you can troubleshoot properly.
Administration Menu
The Administration menu offers some options relating to the configuration of the printer:
Modify Printer—Takes you back through the setup steps you did earlier so you can change the address or enable sharing
Delete Printer—Removes the printer from the system
Set Default Options—Performs just the last step of printer creation, which is to determine the default settings such as paper size
Set as Server Default—Make this the default queue for jobs not assigned a queue
Set Allowed Users—If authentication is set up you can restrict who can print to the queue or to prevent certain people from printing
Jobs List
The Jobs List shows you the list of jobs, in order, that are awaiting printing. The Show All Jobs button switches the view to include jobs that have already been printed; otherwise, you only see jobs awaiting printing.
Each job has three control buttons:
Hold—Prevents printing of the job without removing it from the queue. Release the job by pressing the button again.
Cancel—Removes the job from the queue.
Move Job—Moves the job to another queue.
Command Line Tools
CUPS has several command line tools. Some are specific to CUPS and some are for compatibility with the old lpr/lpd printing systems. Furthermore, the configuration for CUPS is held in human readable text files that can be edited instead of using the web interface.
Note
The exam focuses on the command line tools. Reviewing the web configuration is important to get an understanding of CUPS but is not on the exam. If you don’t have a printer to practice with, you can create a fake printer with a command like lpadmin –p FakePrinter –E –v /dev/null –m raw, or select the Virtual PDF printer option when creating a new printer. The command creates a printer called FakePrinter where all output is discarded; the second option generates PDFs of the output for you.
Legacy Tools
CUPS provides an interface compatible with the legacy lp printing system. It is used to print from the command line and to view print queues. As some applications still print through the legacy printing system, this interface is important.
Even though these legacy compatibility commands were originally used with the LPR protocol, the versions implemented by CUPS support IPP.
lp/lpr
The lp and lpr commands print whatever they receive on the input stream, or any files passed on the command line. Example 17-1 shows a simple way to print:
Example 17-1 Printing from the Command Line
# echo "testing" | lp
request id is Hewlett-Packard_HP_LaserJet_Pro_MFP_M127fn-6 (0 file(s))
# lp memo.ps
request id is Hewlett-Packard_HP_LaserJet_Pro_MFP_M127fn-7 (1 file(s))
The response to this command is a message indicating whether the job was accepted. If you use the lpr command in the same fashion, it does not return any output.
If you are not printing to the default printer, you need to tell lp which destination queue to print to with the -d option, such as with lp -d Hewlett-Packard_HP_LaserJet_Pro_MFP_M127fn.
lp and lpr differ in some of their options, as each is a compatible implementation of its BSD and SYSV predecessor, respectively. The biggest difference is that lp expects the name of the printer to be specified with -d (destination), while lpr expects the -P option.
To print multiple copies, such as 2, use lp -n 2 or lpr -#2.
lpstat
lpstat provides status information about your printers and jobs. It shows the list of jobs you have queued when it is run with no arguments.
A good use of lpstat is to see all the print queues and their status through the -a (all) option. Example 17-2 shows this in action:
Example 17-2 Showing the Status of All Printers
# lpstat -a
Hewlett-Packard_HP_LaserJet_Pro_MFP_M127fn
accepting requests since Sat 02 May 2015 09:47:31 PM CDT
lpstat is primarily concerned with the queue rather than the printer itself. The printer is paused in Example 17-2, but the queue itself is accepting requests. The fact that the printer is paused is not reflected in the output.
Some other uses of lpstat are
lpstat -d—Displays the name of the default printer
lpstat -r—Indicates whether CUPS is running
lpstat -s—Provides a status summary of how the system is configured
lpstat -t—Provides a more detailed summary of how the system is configured
Without any options, lpstat shows a list of jobs queued by the current user to the default printer. You can also pass the name of a printer to see jobs queued by the current user to that printer.
lpq
lpq queries the print queue for the status of the printer and any jobs. The description of each job includes helpful information such as the owner and an identifier for the job that can be used with other commands. Example 17-3 shows such a query:
Example 17-3 Querying the Printer for Status
# lpq
Hewlett-Packard_HP_LaserJet_Pro_MFP_M127fn is not ready
Rank Owner Job File(s) Total Size
1st root 3 Test Page 1024 bytes
Example 17-3 shows that the printer is not ready, which is the same as the printer being paused in the web interface. It does not say anything about the status of the queue itself. You can also see that a job with job ID 3 is in the queue.
By default you only see the default printer. Use the -a option to see all printers on the system, or -P to specify an individual printer. lpq is slightly different from lpstat in that lpstat without any options shows you all jobs queued by the current user, while lpq shows all users.
lprm
lprm removes jobs from the queue, just like the rm command removes files from the filesystem. Example 17-4 shows a print job being removed.
Example 17-4 Removing a Print Job
# lprm 3
# lpq
Hewlett-Packard_HP_LaserJet_Pro_MFP_M127fn is not ready
no entries
The lprm command prints nothing if it succeeds; otherwise, it tries to print a helpful message such as to indicate that the job doesn’t exist or the user doesn’t have permissions.
Like other commands, you can specify a printer with -P. Running lprm with no job ID removes the top ranked job on the given queue. Use lprm -a to remove all print jobs in the queue.
An alternative way of cancelling a job is with the cancel command. This command works similarly to lpq. Cancel job 13 with cancel 13. If you want to cancel a job from a queue other than the default queue, use the name of the queue and the job number, separated with a dash:
$ lpstat
Hewlett-Packard_HP_LaserJet_Pro_MFP_M127fn-9 sean 3072
Sun 03 May 2015 10:19:24 AM CDT
$ cancel Hewlett-Packard_HP_LaserJet_Pro_MFP_M127fn-9
Both methods work equally well, and you should know both for the exam.
CUPS Tools
CUPS provides a small number of tools for interacting with the printing system from the command line.
cupsaccept/cupsreject
These two commands control the status of the given queue. Unlike the lp series of commands, the names of the printers are specified without a separate option.
cupsreject tells CUPS to reject all jobs sent to the queue, and cupsaccept reenables the queue. Example 17-5 shows such an example.
Example 17-5 Rejecting Jobs
# cupsreject Hewlett-Packard_HP_LaserJet_Pro_MFP_M127fn
# echo hi | lp
lp: Destination "Hewlett-Packard_HP_LaserJet_Pro_MFP_M127fn" is not
accepting jobs.
# lpstat -a
Hewlett-Packard_HP_LaserJet_Pro_MFP_M127fn not accepting requests since
Sat 02 May 2015 09:47:31 PM CDT -
Example 17-5 shows that after the queue has been rejected, any attempt to print to it shows an error that the queue is not accepting jobs. This status can be verified with the lpstat command.
cupsenable/cupsdisable
These two commands enable and disable the printer itself, rather than the queue. Just like cupsaccept and cupsreject, give the name of the print queue on the command line.
If the printer is in a stopped state because of an error, you can use the cupsenable command to reenable it. If you need to take down the printer for some maintenance, you can disable printing, while still accepting jobs, with cupsdisable. Once you reenable the printer, the jobs begin printing again.
cupsctl
cupsctl is a tool to manage the configuration of the CUPS daemon. Run it by itself to get a list of the current configuration options.
By default, the CUPS web interface only listens to requests from the machine that it’s running on. If you want to enable remote administration, run cupsctl --remote-admin. You disable remote administration with cupsctl --no-remote-admin.
Shared printers usually only accept requests from machines on the local network. In larger networks this can be a problem because two machines that are talking to each other may be on different networks, connected with a router. In this case, run cupsctl --remote-any to allow anyone that can connect to the computer to print to it. Disable this with cupsctl --no-remote-any.
If you are in a more informal setting where you trust users to delete jobs even if they don’t own them, cupsctl -- user-cancel-any allows anyone to cancel jobs.
Configuration Files
CUPS has a variety of files in /etc/cups. Most of the options you will ever want to change can be done in the web interface. The Server panel in the Administration screen gives you an opportunity to set some global options and to edit one of the configuration files from within the web interface.
Some of the interesting files in the configuration directory are
classes.conf—Contains the classes, which can also be created in the web interface. A class is a group of printers, and printing to a class queues the job to the first available printer.
cupsd.conf—The main configuration file, which can also be edited in the web interface. This contains default settings such as timeouts, rules about what can be done by different people, and logging settings.
cupsd.conf.default—A default configuration file that you can use if you really break your production cupsd.conf. Editing the configuration file on the Web also gives you an option to revert to the default file.
printers.conf—Configuration for each printer that you configured on the system.
ppd—A directory containing the PPD files for each configured printer.
Troubleshooting Printing
Printing seems to be the most tedious area of system administration to troubleshoot. You have users involved, software applications generating output, queues on servers, and mechanical components that have to operate with tight tolerances. Printing is a real-time process built as a series of components playing a big game of hot potato; one component is trying to hand off work to the next component as fast as possible.
Troubleshooting printing means understanding the flow of a print job and the tools necessary to investigate each step of the flow.
Problems tend to fall into one of two categories: Either nothing at all was printed, or something printed but it didn’t work correctly.
Try Printing from the Command Line
If nothing at all is printing, especially from within an application, try printing from the command line to see whether this is a problem with the application or with CUPS. Run something like echo “test” | lp -d PRINTERNAME and see whether anything prints.
If it works from the command line but not the application, it is likely a configuration problem with the application or a permissions problem. Reconfigure the application, paying special attention to the name and type of the printer.
Was the Job Queued?
If you print something and nothing comes out of the printer, you should check to see whether the job was queued. This can be done from the CUPS web interface by looking under the Printers tab, or with the lpq command.
If the job was not queued, you should check to see whether CUPS is running. You should also verify the name of the queues, and that the queue is accepting jobs either through the web interface or the lpstat -a command. Reenable the queue with cupsaccept or through the web interface.
Can CUPS Send the Job to the Printer?
At this point you’ve verified that clients can submit jobs to the queue, but the queue is not being processed by the printer.
The first check should be to see whether the printer is either in the Stopped or Paused states. If so, reenable it through the web interface or use the cupsenable command.
If the printer is in the stopped state, that means a previous job had a problem. Clearing this job from the queue with lprm or the web interface may get jobs flowing again.
At this point it’s a good idea to check the printer itself to make sure it’s on and properly connected to the network. Chapter 19, “Networking Fundamentals,” discusses methods of testing network connectivity to devices.
The printer itself may be jammed or otherwise display an error. If so, take care of those problems.
Turn On Debugging
If nothing up until has solved the problem, you should enable extra logging within CUPS and check those logs. This can be done from the Administration screen in the Server pane:
Check Save Debugging Information for Troubleshooting and then click Change Settings.
Try the previous troubleshooting steps.
Click View Error Log.
The error logs guide the rest of your troubleshooting.
Mail Transfer Agent Basics
Email is as old as the Internet itself, having existed in various formats since the early 1970s. What we now recognize as email evolved from simple beginnings to support images, rich text, and attachments.
You may recognize an email address, such as sean@example.com. The @ separates the user, in this case sean, from the domain, which is example.com. When you send an email to sean@example.com, a detailed set of steps are followed by many machines across the Internet to get your email delivered.
How Email Flows
Getting email to work properly involves several different components. Each of these components must do a particular job and then hand off the email being delivered to the next component in the chain.
Sometimes a single server or application handles multiple components. Even when this is the case, troubleshooting is more effective when you continue to think of the system in terms of components. We look at each component in turn.
Mail User Agent
The Mail User Agent, or MUA for short, is the technical term for an email client. You use your MUA to send and receive email. Many things can do the job of the MUA such as a dedicated program, a web page, a smartphone, or even an application that sends out alerts.
The MUA’s job is to capture the email in some format, including the recipient, and send it to the next link in the email chain—the Mail Transfer Agent (MTA).
The MUA is free to communicate to the MTA in whatever protocol makes sense. Where the email system is a proprietary one such as Microsoft Exchange using Microsoft Outlook as the MUA, the communication is done in some kind of application-specific protocol. The MUA might be an application running inside a browser, so the communication there might be called to a remote web server. Other times the communication is done in the protocol used to transfer mail over the Internet itself: the Simple Mail Transfer Protocol (SMTP).
Mail Transfer Agent
The MTA’s job is to receive an email from an MUA or other MTA and get it one step closer to the final destination. The process of getting an email between two parties might take several MTAs. It is common for organizations to relay email from MTAs in the field to a smaller set of outbound MTAs. Relaying happens when an MTA forwards a message on behalf of another MTA.
This relaying step is also where a great deal of spam email comes from. Any server that is relaying should take care to make sure that the email being relayed is either from a known source or going to a known source. Without this check, someone could anonymously funnel the latest request for help from the fake prince of a small nation through your server and you would forward the email for him.
Locking down your MTA to prevent spam is a weighty topic, but fortunately Linux distributions come minimally configured to prevent this, and the detailed configuration of an MTA is not in scope for the exam.
The Language of Email
Email exchange over the Internet is done through the Simple Mail Transfer Protocol. This is a text-based communications protocol that lets different email systems talk to each other even if they would normally talk with proprietary protocols.
Example 17-6 shows what an SMTP conversation looks like.
Example 17-6 An SMTP Conversation Between Two MTAs
220 www.ertw.com ESMTP Postfix
HELO www.ertw.com250 www.ertw.com
MAIL FROM: sean@ertw.com
250 2.1.0 Ok
RCPT TO: swalberg@gmail.com
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Testing
Hi Sean, just testing
.
250 2.0.0 Ok: queued as 8E720731A
QUIT
221 2.0.0 Bye
In Example 17-6 you can see that the conversation is all readable instead of being some kind of binary protocol. The server prefixes all its responses with a number indicating a status code. The wording that follows the number is actually for humans, not other computers!
Understanding SMTP is not necessary for the exam, but for real world troubleshooting it’s valuable to know the kind of information carried inside the protocol, and what’s in the email itself. For example, SMTP doesn’t care about the subject line. It just needs to know who sent the email, where it’s going, and the contents of the email. The final system is the one that cares about the contents.
Linux MTAs
Linux has a variety of MTAs. Each one still speaks SMTP, but what differs is how the software is configured and what extra features it can have. There are four MTAs relevant to the exam.
Sendmail was once the most popular MTA on the Internet. It can speak a variety of protocols order to connect different email systems. Sendmail is less of an MTA than it is a system for building an MTA out of a language called M4, and is therefore incredibly complicated. This author, not fondly, remembers having a large book on his shelf that was needed to explain how to configure Sendmail. Other than the complexity, Sendmail’s main criticisms are that it puts too many responsibilities in a single process and has a history of security problems.
Postfix is an MTA that came out of IBM Research and is still actively developed by the open source community. Postfix has extensive policy configuration to prevent spam and separates concerns into separate processes for security. Even though programs like sendmail had support for external filters such as Anti-Virus scanners bolted on, this external filtering functionality is a first-class citizen in the Postfix world.
Qmail was written as a secure replacement to Sendmail. Like Postfix, the concerns are compartmentalized to prevent a successful compromise of one component from gaining access to other components. The configuration is fairly simple, perhaps even more so than Postfix. The source is now in the public domain, so the development seems to have fragmented and slowed down.
Exim is another monolithic MTA, like Sendmail, but has a better security record. Exim is highly configurable without needing to devolve into the madness that is sendmail’s M4. At one point Exim was the default MTA in Debian, but the project has since switched to not offering an MTA in a standard installation.
Despite the variety of MTAs with their own configurations, there are some commonalities when it comes to some basic commands and functionality. Part of these commonalities are on the part of the MTA itself, and some are through work done by most distributions to ease the transition between MTAs.
Domain Name System
The domain name system (DNS) is what translates between hostnames, such as www.example.com, and IP addresses, such as 127.0.0.1. The DNS plays an integral role in delivering email.
Your MTA needs to know where to deliver email. This information might be statically configured to send everything to a centralized mail server, but at some point an MTA needs to look up this information in the DNS if the destination is outside your organization.
First, the MTA extracts the domain from the email address. For joe@example.com, the domain is example.com. Next, the MTA queries the DNS for the Mail Exchange (MX) record. It may get back the names of one or more MTAs. For example, Google’s public mail servers are listed inExample 17-7.
Example 17-7 Querying a Domain’s MX Records
$ host -t mx google.com
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
Google lists five mail servers, each with a different priority level: 10, 20, 30, 40, and 50 (while the records may display in any order, the priority number dictates the order in which they should be tried). The lowest value has the highest priority, so a remote MTA would first try delivering toaspmx.l.google.com. If that fails, it is free to try the next one in the list. However, by advertising five MTAs, Google is promising that any one of them is valid to deliver mail for people at google.com.
If a domain does not publish any MX records in the DNS, an MTA can try to resolve the domain name to an address and deliver mail there. If that fails, the domain likely doesn’t accept email and the message should bounce. In email terminology, a bounce happens when an email is rejected at some point in the chain. Most of the time a user can expect to receive an email in return indicating that the email was not delivered. Some systems will not return bounce messages for users that don’t exist because spammers who try and make up usernames will generate an excessive amount of bounces.
Mail Delivery Agent
The Mail Delivery Agent (MDA) receives email through SMTP like an MTA and delivers it to a local mailbox in whichever format is used at the destination site. Sometimes it is writing the email to a flat file unique to the user; sometimes it is writing it to a database for performance reasons.
The MDA, in its capacity as an MTA, also has the opportunity to perform aliasing and forwarding. Aliasing happens when a user wants to receive email with a different name. For example, instead of creating an account for sales@example.com, you can create an alias pointing sales to one or more existing accounts. Thus you can make your sales address public but send all the email to a particular user’s account. This lets you switch the destination without needing to make the change public and also means that people only need to check one mailbox.
Forwarding is similar to aliasing except that the redirect is to different email system. joe@example.com might want to send all his email to his mobile phone that has its own email address. Some organizations prohibit this to maintain control over email, or may have policies on where emails can be forwarded. Some MDAs also allow users to create their own forwarding rules.
The MDA is usually a function of the MTA. The MTA might deliver the mail itself or pass the email to an external command should it determine that the email should be delivered locally.
Once the MDA has processed the message and delivered it to a mailbox, the email is considered to be delivered. It’s up to the recipient to read the email.
Mail Server
The final piece of the puzzle is the mail server that reads the user’s mailbox and allows the recipient to read the email. Usually the user reads the email in the same MUA she uses to send email. This MUA can connect to the mail server with the same proprietary protocol used to send messages. If emails are sent with SMTP, something else needs to be used, as SMTP is only for sending messages, not reading them.
The Post Office Protocol (POP) or Internet Message Access Protocol (IMAP) are used by the MUA to read emails off the mail server. POP is primarily used to download emails to the local computer and delete them off the computer, and IMAP usually leaves the email on the server and reads the email over the network.
POP is simple as it was designed to transfer email to the client and then delete it off the server. IMAP was designed to mirror features on the client so that more work could be performed server-side; therefore it supports folders and searching.
The MDA and mail server are closely linked in that the MDA must write email in a place and format that the mail server can read, but they don’t necessarily need to be the same software.
Creating Aliases and Forwarding Email
When the MTA decides that the email it received is to be delivered to a local account it hands off the email to the MDA. The MDA can then deliver the email to a local account’s email box, which is usually a file in /var/spool/mail. Before delivery, the MDA first checks to see whether there are additional instructions on how to handle the email, which is called an alias.
Mail aliases are systemwide and stored in a file called /etc/aliases. They are systemwide because an alias does not belong to a user. The email comes in, the MDA sees there is an alias for that name, and the MDA delivers the email to the user specified in the alias.
The format of /etc/aliases is simple:
alias: recipient
An alias can have multiple recipients, in which case they are separated by a comma:
alias: recipient1,recipient2
An alias name may or may not exist as a local user account. For example, it is common to send root’s email to a named user:
root: sean
Comments are allowed with the hash mark:
# Send root's mail to sean
root: sean
Even though the root account exists, any mail that was to be delivered to root goes to sean instead.
Committing Changes
Your changes to /etc/aliases do not go into effect immediately. Your MDA actually reads a database file called /etc/aliases.db, which is optimized for reading. Making your email software read the file every time would put a damper on performance, so you need to compile the text file into something that can perform lookups quickly.
The newaliases command updates the aliases.db file for you so that your changes to aliases take effect. This command must be run as root because the permissions of the files should not allow users to modify it.
If there are no problems, the newaliases command returns nothing. If there is a formatting problem you get an error:
# newaliases
postalias: warning: /etc/aliases, line 96: need name:value pair
The server usually lets you know if you forgot to run newaliases with a message in the mail log, usually /var/log/messages.
warning: database /etc/aliases.db is older than source file /etc/
aliases
This indicates that you haven’t run the newaliases command since last changing /etc/aliases.
Other Types of Aliases
You have seen how to alias a single address to other local accounts, such as to give Rebecca all the emails going to the human resources alias. There are more things you can do to the email other than deliver it to a local account.
The aliases file also accepts fully qualified email addresses. If you were to have a line in your aliases file like:
isaac: i.smith@example.com
any email destined to the isaac account would be sent back to the MTA to be directed to i.smith@example.com.
The destination of the alias could also be a file:
support: /var/log/support.please.ignore
would redirect all email to the support account to a file in /var/log. Imagine how much easier an administrator’s job would be if she didn’t have to deal with those pesky users!
The destination can also be a script if the name of the file is prefixed with the pipe (|) operator:
support: | /usr/local/bin/new_ticket.sh
In this case, the email would be passed to a script that would presumably ingest the email into a new support ticket.
Don’t forget, you need to run newaliases after making any changes!
User-Defined Forwarding
Users can define their own forwarding rules by placing a file called .forward (note the leading period) in their home directory, containing the forward instructions.
The instructions in the ~/.forward file are the same as those in the /etc/aliases file. The only difference in the format is that there is no need to specify the aliased user, as it is the owner of the ~/.forward file. Thus, if user Isaac had a ~/.forward file containing i.smith@example.com, all his email would be redirected to the external address.
One thing to keep in mind is that an alias can refer to other aliases. If Isaac wanted to redirect his mail offsite and keep a copy locally, he would need to escape the local alias to prevent it from being reprocessed as an external redirect:
\isaac
i.smith@example.com
Managing Queues
An MTA receives a message and stores it in a queue for later processing. A queue allows the MTA to process an email later if the destination MTA isn’t listening, or sends an error indicating your MTA should retry the connection later. The mailq (mail queue) command shows the queue, shown in Example 17-8.
Example 17-8 A Mail Queue
# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
AC1687363* 3229 Tue Apr 14 05:48:57 MAILER-DAEMON
cfvxfvrsi@example.com
451817349 651 Sat Apr 11 13:06:09 nginx@www.noreply.com
(connect to example.org[172.16.33.111]:25: Connection timed out)
jermainewillilams@example.org
This command looks at the mail queue files in /var/spool/mqueue and displays them on the screen. You can see from Example 17-8 that there are two messages in the queue. It is normal to see mail there as typos and spam cause delivery to all sorts of incorrectly configured servers.
If you are looking into problems with delivery to a particular destination, the mail queue is a good place to look, as you’ll see the emails waiting to go out there. The logs, usually /var/log/maillog, are also a good place to look for a historical accounting of each email.
mailq is actually a command from sendmail, but due to the compatibility layer most distributions put in place, it runs the appropriate command depending on your MTA of choice. For example, Postfix uses postqueue -p, exim uses exim -bp, and qmail uses qmail-qread.
Even newaliases is a sendmail compatibility command!
Summary
Printing involves a series of discrete steps that get a print job from an application to the final printer. CUPS, the Common Unix Printing System, uses the Internet Printing Protocol (IPP) for communication, as opposed to the older Line Printer Remote (LPR) based commands.
A series of command line tools allow you to enable and disable both printers and queues, and to query and modify the jobs being processed.
Email is much like printing in that there are several discrete steps. The Mail Transfer Agent does the bulk of the work in moving email closer to its destination, relying on the Mail Delivery Agent to do the final work of delivering the email to the user’s mailbox.
Email aliases are used to redirect email from one user to another, even if that first user doesn’t exist. Users can also set up their own forwarding rules, such as to send email to another account or pass it through a filter.
Exam Preparation Tasks
As mentioned in the section “How to Use This Book” in the Introduction, you have a few choices for exam preparation: the exercises here, Chapter 21, “Final Preparation,” and the practice exams on the DVD.
Review All Key Topics
Review the most important topics in this chapter, noted with the Key Topics icon in the outer margin of the page. Table 17-2 lists a reference of these key topics and the page numbers on which each is found.
Table 17-2 Key Topics for Chapter 17
Define Key Terms
Define the following key terms from this chapter and check your answers in the glossary:
print spooler
print queue
line printer remote
Internet Printing Protocol
Common Unix Printing System
CUPS backend
Mail User Agent
Mail Transfer Agent
Simple Mail Transfer Protocol
relay
Sendmail
Postfix
Qmail
Exim
bounce
Mail Delivery Agent
aliasing
forwarding
Review Questions
The answers to these review questions are in Appendix A.
1. What is the proper URL to access the CUPS administrative interface running on the same machine as the web browser?
a. http://localhost
b. https://localhost
c. http://localhost:631
d. http://localhost:389
2. Which of the following printer states would indicate that something went wrong with the printer and that some administrative action is necessary?
a. Idle
b. Processing
c. Stopped
d. Paused
3. How would you determine the default printer that print jobs go to? Type the command and all arguments.
4. A user calls you in panic and says he printed something to a printer called OfficePrinter and it’s sending out page after page of junk. You turn to your command line and check the queue:
OfficePrinter is printing
Rank Owner Job File(s) Total Size
1st john 3 randomjunk 8765309 bytes
How do you stop the job?
a. lprm -P OfficePrinter
b. lprm -P OfficePrinter 1
c. lpq -P OfficePrinter --delete-all
d. Turn off the printer.
5. One of your printers, CentralArea, has a broken paper feeding mechanism and won’t be fixed for a few days. Rather than queue jobs until it’s fixed, how can you make things so that people trying to print to it get an immediate error, without needing to delete the printer?
a. lpstat --disable -P CentralArea
b. cupsreject -P CentralArea
c. lpadmin -x CentralArea
d. cupsreject CentralArea
6. What are two example of Mail Transfer Agents that operate as a series of daemons with separated responsibilities?
a. Sendmail
b. Qmail
c. Exim
d. Postfix
7. You have been asked to send all emails to hr@yourcompany.com to rebecca@yourcompany.com and edward@yourcompany.com. What’s the name of the file that you will be editing? Use the full path to the file.
8. After adding an email alias to the appropriate file, what command should you run?
a. mailq
b. update-aliases
c. postmap
d. newaliases
9. A user comes to you and asks how she can send all her email to her second account, j.smith@example.com, instead of reading it locally. What are the instructions you would give her?
a. Run sendmail -f j.smith@example.com.
b. Add j.smith@example.com to ~/.forward.
c. Add j.smith@example.com to /etc/aliases.
d. Add j.smith@example.com to ~/.aliases.