Email for Standalone Workstations


Knowing how to run a full-fledged email server is an excellent system administration skill. But this skill won't help you much if your FreeBSD machine isn't intended to be an Internet server providing mail services for dozens of users. What if you're just running a workstation, in the same way that someone might run a Windows desktop machine, with a Gnome or KDE desktop and graphical productivity applications instead of server tools?

Fortunately, a standalone workstation's email setup is much less complex than that of a full-scale server. FreeBSD's default configuration is to start a "submission" Sendmail process (sendmail_submit_enable="YES" is the default setting in /etc/defaults/rc.conf), and you need not add any mention of Sendmail to /etc/rc.conf to enable your system to deliver mail from your local mail clients to remote SMTP servers.

Still, it's important that you know how to control the standalone workstation environment and customize its behavior to your needs, and there are some interesting tricks that make standalone computing with FreeBSD more convenient than would otherwise be the case.

Using Fetchmail to Retrieve Email from POP3 and IMAP Servers

Most consumer operating systems have email client programs (such as Outlook, Apple Mail, Mozilla Thunderbird, and so on) that have their own internal, built-in mechanisms for checking POP3 or IMAP servers. Each one gets your mail in its own way and then stores it in its own fashion internally. Some MUA programs of this type exist for FreeBSD, as discussed earlier (particularly in Chapter 6), and they work just as you'd expect any such program to work.

However, you might choose instead to run a shell-based MUA such as Mutt, Elm, or Pine on your local workstation, just as you would on a server. These programs operate directly on the system's central /var/mail directory and your mail spool file inside it, rather than keeping their own internal cache of downloaded messages. This allows you to share the mailbox between programs, search through it using command-line tools, and take advantage in many other ways of the versatility and open nature of the mail system to make it behave just the way you want, such as by writing your own scripts to parse your mail spool and process it according to your own needs.

But to get the messages from the POP3 or IMAP server where your email address stores them (for instance, all mail to a frank@earthlink.net address would collect on the earthlink.net servers) to your local FreeBSD workstation, something needs to make the POP3 or IMAP connection and deliver the new messages from the remote mailbox to your local one. That something is Fetchmail, a small but versatile utility written by Eric Raymond.

Fetchmail can be installed out of the ports (/usr/ports/mail/fetchmail) or packages. It runs as a user process, on demand, and takes its runtime configuration from a .fetchmailrc file in your home directory. This file specifies remote POP3 or IMAP servers to poll for new mail, the intervals at which to check, and numerous other options.

Fetchmail then retrieves new mail as specified and relays it to port 25 on your workstation, where Sendmail is listening for incoming SMTP connections. It then will deliver the mail to your local mailbox according to all the rules that would normally apply, such as .forward files and mail aliases.

After Fetchmail has been installed (it is available in the FreeBSD ports collection in the mail directory), you will need to configure the .fetchmailrc file in your home directory before you can use it. This can be done in one of two ways.

The first method involves using the fetchmailconf program. This is a graphical configuration program for Fetchmail that is written in Python and uses the Tk toolkit (a toolkit for building graphical user interfaces in the X11 system). Although fetchmailconf comes with the Fetchmail program, it requires Python and Tcl/Tk to be installed in order to work. (Python and Tcl/Tk are both popular languages available for many different platforms.)

The second method of configuring Fetchmail involves creating the .fetchmailrc file manually. The format of the configuration file is straightforward, and the Fetchmail man page is extremely good, covering in detail every option that can go in the .fetchmailrc file. This is the method we will cover in this chapter.

Configuring the .fetchmailrc File

In your home directory, open a new file called .fetchmailrc in your favorite text editor. The .fetchmailrc file you create here will contain three sections: global options, server options, and user options.

Caution

It's very important that the .fetchmailrc file sections appear in exactly the order shown here. Also note that no options that belong to a previous section can be used after a new section has been started. One of the most common causes of errors in .fetchmailrc files is having options in the wrong order or in the wrong place.


This chapter doesn't cover all the options available to .fetchmailrc because there are far too many. What we will do instead is to create a sample setup for retrieving mail from a POP3 server, a fairly common user situation. Use the information presented in this section as a starting point for getting Fetchmail up and running. Then, refer to the man page for Fetchmail for any advanced configuration you want to do.

The first section of the .fetchmailrc file contains the global options. These options will apply to all the mail servers and user accounts that will be listed later on in the configuration file. It is possible to override some of the global options with server- or user-specific options, but as a general rule, these lines will apply to all the servers and accounts that Fetchmail checks. Here is an example of a simple global configuration section and the options it might contain:

set daemon 600 set postmaster frank set logfile ./.fetchmail.log


These are the most common options used in the global section. Here's an explanation of each line:

  • The first line causes Fetchmail to run in daemon mode and check for new mail every 600 seconds (10 minutes). When Fetchmail is started, it will check for new mail and move itself into the background as a daemon. After that, it will check for new mail every 600 seconds. If this line is not present, when you invoke Fetchmail, it will check for new mail and then terminate immediately and not check again.

  • The second line is the fallback address. Any mail that Fetchmail receives that is not addressed to a local user will be sent to this account on the local system. You should probably set this to the same user you will be running Fetchmail as.

  • Finally, the third option sets a log file in which Fetchmail will log its activity. Alternatively, you can use the line set syslog instead, which will cause Fetchmail to use syslogd for logging. syslogd is the system-logging daemon that handles the logging of other system events. See Chapter 14 for more about syslogd.

The next section of the .fetchmailrc file is the server section, which contains information on each mail server that should be checked for mail. Here is a sample server section that is configured to check one email server:

poll mail.example.com proto pop3 no dns


Several other server options are available. See the Fetchmail man page for full details. Here are the options shown in this example:

  • The first line causes the server mail.example.com to be checked for new mail at the interval configured by the set daemon option in the global section, as well as each time Fetchmail is invoked manually. The alternative would be skip mail.example.com. In this case, this server would be skipped and not checked for new mail at the regular intervals or when Fetchmail is invoked manually. If the skip option is used, the server will only be checked for new mail when you specify it by name on the command line when invoking Fetchmail manually.

  • The second line tells Fetchmail the protocol to use with this server. In this case, it's POP3. Other legal protocols are IMAP, APOP, and KPOP.

  • The third option tells Fetchmail not to perform DNS lookups when performing "multidrop" local name resolution (deciphering local usernames from the domains in the address headers of each message). If you are running over a dial-up Internet connection, you will probably want to include this line to prevent delays in getting your mail.

The third and final section of the .fetchmailrc file is the user section, which contains information about the account itself. Here is a sample user section of .fetchmailrc:

user frank pass secretword fetchall flush


Here are some points to note in this example:

  • The first and second lines contain the username and password, respectively, that you use to access the mail on your ISP's mail server. (As a matter of responsible security practice, this should be different from the passwords you use for other services, such as your online banking account.)

  • The third line tells Fetchmail that it should retrieve all messages from the server, including those that have already been read.

  • Finally, the fourth line tells Fetchmail that it should flush the server (delete the messages it downloads off the server). This line is not strictly necessary because it's implied in the default configuration.

Several more user options are available, including options that cause Fetchmail not to delete mail off the server that it downloads, options that specify that only new messages should be downloaded, and so on. See the Fetchmail man page for full details.

The complete Fetchmail configuration file looks like this:

set daemon 600 set postmaster frank set logfile ./.fetchmail.log poll mail.example.com proto pop3 no dns user frank pass secretword fetchall flush


From top to bottom, this file basically says the following: "Check for new mail every 600 seconds (10 minutes). Send any unaddressed mail to the user frank. Log the actions to .fetchmail.log. Perform the 10-minute-apart checks against the server mail.example.com using the POP3 protocol, and do not attempt to do DNS lookups on local usernames. Use the username frank and the password secretword to log in to the server, fetch all the messages, and delete the messages off the server after they are downloaded."

Caution

Because the .fetchmailrc file contains your username and password for the mail server, its permissions should be set so that only you, the user running Fetchmail, can read this file. The permissions should be no higher than 600. You can set the permissions to the correct value by typing chmod 600 .fetchmailrc. This will allow only the owner of the file to read or write to it. Fetchmail will complain and refuse to run if you attempt to start it with a .fetchmailrc file that has permissions looser than this.


This brief introduction to Fetchmail should get you up and running with a basic configuration. For more advanced options, see the man page for Fetchmail. It is very detailed and fully explains all the options available for the .fetchmailrc file.

Sendmail Configuration for Standalone Workstations

For Fetchmail to work, Sendmail (or some equivalent) has to be running on port 25 to accept incoming messages. However, Sendmail is configured by default to handle outgoing mail, and for good reason; it's not generally a good idea to run your workstation with no MTA at all. For example, Mutt and other shell-based mail clients send messages by passing them directly to Sendmail, rather than by connecting remotely to some external SMTP host. This prevents relaying-related issues, as discussed earlier.

Still, you can do a few things to tweak Sendmail's performance and configuration so that it's optimized for use in a system that isn't connected to the Internet at all times. The first such configuration is the "smart" mail host, and the second is an automated mail spool run.

Find the following lines in /etc/mail/freebsd.mc:

dnl Dialup users should uncomment and define this appropriately dnl define(`SMART_HOST', `your.isp.mail.server')


Uncomment the define line by removing the dnl, and change your.isp.mail.server to the appropriate mail server name. Rebuild the config file by running make cf and make install from inside /etc/mail.

This change allows your workstation to operate like any desktop operating system in which each mail client makes its own SMTP connection to the SMTP server provided by the dial-up ISP, which then relays the mail on to its final destination. Because you might be using shell-based MUAs such as Mutt and Pine, which send mail by passing it directly to Sendmail rather than trying to make their own in-program SMTP connections to a defined SMTP relay, you need a centralized way to make these mail clients behave like their commercial Windows counterparts. Defining SMART_HOST forces Sendmail to direct all outgoing mail to your dial-up SMTP server.

The reason for all this is that most SMTP servers will reject mail that comes from an unresolvable IP address, and many ISP networks don't provide DNS lookup information for their dial-up clients. If you don't define SMART HOST, this limitation will prevent your FreeBSD workstation from being able to send mail reliably to a good percentage of the mail hosts on the Internet. However, because you have an available SMTP server at your ISP, and because this server will relay mail from all its dial-up customers (because that's how Windows MUAs work), you can rest assured that defining SMART_HOST will get all your messages to their destinations.

Another configuration item you can tweak is the outgoing ("submission") message queue. By default, Sendmail does a queue run every 30 minutes (using the -q30m command-line option, set in /etc/defaults/rc.conf). If you're a dial-up user who connects for only brief periods, this interval might be too long. You can add a line to /etc/rc.conf overriding the default interval (changing the default -q30m to -q10m):

sendmail_flags="-L sm-mta -bd -q10m -ODaemonPortOptions=Addr=localhost"


However, an even more efficient way to handle this is to leave the default -q30m untouched and to simply do a queue run each time you connect to the Internet. As you'll recall, you can initiate a queue run with the sendmail -q command, optionally adding -v for entertainment or debugging purposes.

Doing this by hand is sure to become tedious, though, so you can add sendmail -q to your ip-up script, which we discussed in Chapter 24, "Networking with PPP and 802.11."




FreeBSD 6 Unleashed
FreeBSD 6 Unleashed
ISBN: 0672328755
EAN: 2147483647
Year: 2006
Pages: 355
Authors: Brian Tiemann

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net