 |  |
| |
Electronic mail (email) is one of the most desirable features of a computer system. You can send and receive email on your Linux system locally between users on the host and between hosts on a network. You have to set up three classes of software to provide email service. These are the mail user agent or mailer, the mail transport agent (MTA), and the transport protocol.
The mailer provides the user interface for displaying mail, writing new messages, and filing messages. Linux offers you many choices for mailers. They are always being improved, and a particular mailer may provide certain features, such as the ability to serve as a newsreader or to serve as a web browser. Mailers tend to differ in terms of their MIME support. (MIME stands for Multimedia Internet Mail Extensions. It is really not multimedia-specific, but more a general standard for describing the contents of email messages.) Some do it better than others. It's difficult to give a recommendation here, though, since all mailers are continually moving toward better MIME support.
The mailer relies on the MTA to route mail from one user to another, whether locally or across systems. The MTA in turn uses a transport protocol, usually either Unix-to-Unix Copy (UUCP) or Simple Mail Transport Protocol (SMTP), to provide the medium for mail transfer.
There are a number of possible scenarios when using email on a Linux system, and depending on those scenarios, you will have to install a different set of software packages. However, no matter which option you choose, you will always need a mailer.
The first scenario applies to dial-up access to the Internet via an Internet Service Provider (ISP). In this scenario, there is often only one user on the Linux machine, although this is not a requirement. The ISP accepts your mail from the Internet and stores it for you on its hard disks. You can then retrieve the mail whenever you want by using the common POP3 (Post Office Protocol) protocol or the newer IMAP protocol. Outgoing mail in this scenario is almost exclusively sent via the SMTP protocol, which is universally used to transport mail over the Internet.
In the easiest case, you use your mailer both to retrieve the mail via POP3 or IMAP and to send it back via SMTP. When you do this, you do not even need to set up an MTA because the mailer handles everything. This is not terribly flexible, but if all you want is to access your mail easily, this might be an option for you. Mailers that support this include KMail from KDE and Mozilla's built-in mail program (both described later).
If you want more flexibility (which comes at the price of more configuration and maintenance work), you can install an MTA such as Postfix, described in the next section. You will need a program that transports the mail from your provider's POP3 or IMAP server. This program fetches your mail when you ask it to and passes the messages on to the MTA running on your system, which then distributes the mail to the recipients' mail folders. One program that does exactly that is fetchmail, which we will cover later in this chapter. Outgoing mail is again sent via SMTP, but with an MTA running on your machine, you can choose not to send the outgoing messages directly to your provider's SMTP server, but rather to your own server, which is provided by the MTA. The MTA then forwards the mail to your provider, which in turn sends it to the recipients. With this setup, you can instruct your MTA to send outgoing mail at certain intervals only so that you do not always have to make a dial-up connection.
The third scenario is meant for machines that have a permanent connection to the Internet, either because they are in a network that has a gateway with a permanent connection, or because they are using a leased line to your Internet provider. In this case, you might want to receive mail messages as soon as they arrive at your provider and not have them stored there. This also requires setting up an MTA. Incoming mail will be directed to your SMTP server (i.e., your MTA). Your provider will have to set things up accordingly for this to work.
Of course, there are many more scenarios for using mail, and mixtures between the three mentioned are possible as well. If you are going to set up a mail service for a whole network, you will most certainly want to read the Linux Network Administrator's Guide (O'Reilly) as well as a book about your MTA.
You have a number of software choices for setting up email on a Linux host. We can't describe all the available email solutions, but we do describe some packages that are often used and quite suitable for their respective tasks. We document what we think are the most popular Linux solutions at this time: the mailers KMail and Mozilla, the Postfixmail transport agent, and the fetchmail implementation of the POP3 and IMAP protocols. These are relatively simple to configure but provide all the features most users need. In addition, with these tools, you can cover all the scenarios described earlier.
Several MTAs are available for Linux. Historically, the most common MTA on Unix has been Sendmail, which has been around for a long time. It is generally considered somewhat more difficult to use than the alternatives, but it is thoroughly documented in the book sendmail by Bryan Costales with Eric Allman (O'Reilly).
Postfix is a newer MTA, developed by security guru Wietse Venema as a replacement for Sendmail. It's designed to be compatible with Sendmail but to provide a higher level of security and be easier to configure.
Postfix is a highly flexible and secure piece of software that contains multiple layers of protection against would-be attackers. Postfix was also written with performance in mind, and employs techniques to limit slower activities such as creating new processes and accessing the filesystem. It is one of the easier email packages to configure and administer because it uses straightforward configuration files and simple lookup tables for address rewriting. It is remarkable in that it is simple to use as a basic MTA, yet still able to handle much more complicated environments.
Many Linux distributions have Postfix built-in, so you may already have it installed on your system. If not, you can find prebuilt packages or compile it yourself from the source code. The Postfix home page (http://www.postfix.org/) contains links to download both the source code ("Download") and packages for different Linux distributions ("Packages and Ports").
Postfix has two different release tracks: official and experimental. The experimental releases contain all the latest patches and new features, although these might change before they are included in the official release. Don't be put off by the term "experimental"; these releases are very stable and have been tested thoroughly. If you are looking for a feature that is available only in the experimental release, you should feel more than comfortable using it. Read the release notes for both tracks to know what the current differences are.
Before setting up Postfix, you should understand that if your system is going to receive mail from others across the Internet, the DNS for your domain has to be configured correctly. DNS is discussed in Chapter 15.
Let's assume for this discussion that you are configuring a host called halo in the domain example.org and that you have a user account michael on your system. Regardless of how you want to receive mail, your host halo.example.org must have a DNS A record that maps its hostname to its IP address.
In this example your email address is going to be either michael@halo.example.org or michael@example.org. If you want to use the first form, configuring the DNS A record is enough for messages to reach you.
If your system is going to receive all mail for example.org (michael@example.org), the domain should have a DNS MX record pointing to your host halo.example.org. If you are configuring the DNS for your domain yourself, make sure you read the documentation to understand how it works; otherwise, speak to your DNS administrator or ISP about routing mail to your system.
Postfix frequently uses DNS in its normal operation, and it uses the underlying Linux libraries to perform its DNS queries. Make sure your system is configured correctly to perform DNS lookups (see Section 15.2.1.6 in Chapter 15). Postfix usually has to find an MX record to make its deliveries. Don't assume that if Postfix reports a DNS problem with an address, and you find that the domain resolves correctly, that email delivery should succeed. If Postfix reports a problem, you can be almost certain there is a problem.
Although prepackaged distributions are available, you may want to build the package yourself if you want to use any of the add-on libraries or functions that are not included in your distribution. You might also want to get the latest version to obtain a new feature that has not yet been included in your distribution.
Before you install Postfix, be aware that it includes the three commands /usr/bin/newaliases, /usr/bin/mailq, and /usr/sbin/sendmail that are normally used by Sendmail. Postfix provides replacements that work with the Postfix system rather than with Sendmail. You should rename your existing Sendmail commands so that the Postfix installation doesn't overwrite them in case you ever want to use the original Sendmail binaries again:
# mv /usr/bin/newaliases /usr/bin/newaliases.orig # mv /usr/bin/mailq /usr/bin/mailq.orig # mv /usr/sbin/sendmail /usr/sbin/sendmail.orig
Postfix uses Unix database files to store its alias and lookup table information. You must, therefore, have the db3 libraries installed on your system before building Postfix. These libraries are contained within the db3-devel RPM package or the Debian libdb3 package. If you are not using a package manager, you can obtain them directly from Sleepycat Software (http://www.sleepycat.com/). If you are using RPM, execute the following command to see if the necessary libraries have been installed on your system:
# rpm -qa | grep db3-devel db3-devel-3.2.9-5
You should see a line similar to the second line in the preceding command that displays the db3-devel package with a version number. If rpm returns nothing, you must install the libraries before installing Postfix.
On Debian, you can use dpkg to see if the libraries are installed.
# dpkg -l libdb3
If you download a prepackaged Postfix, use your package manager (described in Chapter 7) to install it. If you download the source postfix-1.1.11.tar.gz, move that file to a suitable directory (such as your home directory) to unpack it. The numbers in the name of the file represent the version of this release. Your file may have different numbers depending on the current release when you download it.
Follow this basic procedure to build Postfix. Note that you'll have to be the root user to create the user and group and to install the package.
Rename your Sendmail binaries as described earlier.
Create a user account called postfix and a group called postdrop. See Section 5.7 for information on setting up accounts and groups.
Run gunzip on the compressed file to produce a file named postfix-1.1.11.tar.
Execute:
tar -xvf postfix-1.1.11.tar
to unpack the source into a directory called postfix-1.1.11.
Move to the directory created when you unpacked the file. You'll find a file called INSTALL with detailed instructions about building your Postfix system. In most cases, building Postfix should be as simple as typing make in the directory.
If your build completes without any errors, type make install to install Postfix on your system. You should be able to accept all the defaults when prompted by the installation script.
After installation, you will have Postfix files in the following directories:
The master.cf file controls the various Postfix processes. It includes a line for each component of Postfix. The layout of the file is described by comments in the file itself. Usually, you shouldn't have to make any changes to run a simple Postfix installation.
The main.cf file is the global SMTP configuration file. It includes a list of parameters set to one or more values using the format:
parameter = value
Comments are marked with a hash mark (#) at the beginning of the line. You cannot put comments on the same line as parameters. Commented lines can begin with whitespace (spaces or tabs), but they must appear on lines by themselves.
Multiple values for parameters can be separated by either commas or whitespace (including newlines), but if you want to have more than one line for a parameter, start the second and subsequent lines with whitespace. Values can refer to other parameters by preceding the parameter name with a dollar sign ($).
Here's an example of an entry that includes comments, multiple lines, and a parameter reference:
# Here are all the systems I accept mail from. mynetworks = $myhostname 192.168.75.0/24 10.110.12.15
As mentioned earlier, Postfix also installs replacements for /usr/bin/newaliases, /usr/bin/mailq, and /usr/sbin/sendmail.
Before you start Postfix for the first time, you have to make sure that the aliases table is formatted correctly and that a few of the critical configuration parameters are set correctly for your system.
Historically Sendmail has used the file /etc/aliases to map one local username to another. Postfix continues the tradition. The /etc/aliases file is a plain-text file that is used as input to create an indexed database file for faster lookups of aliases on your system. There are at least two important aliases on your system that must be set in your /etc/aliases file. If you have been running Sendmail on your system, these aliases are probably already set correctly, but make sure your file has entries for root and postmaster pointing to a real account that receives mail on your system. Once you have verified the aliases, execute the command newaliases to rebuild the index file in the correct format for Postfix.
The /etc/postfix/main.cf file contains many parameters, but there are just a few important ones that you should verify before starting Postfix; we'll explain these in this section. If you installed Postfix from a prepackaged distribution, these parameters might already be set correctly. It's also possible that the Postfix defaults work for your system, but edit your /etc/postfix/main.cf file to make sure.
myhostname = halo.example.org
mydestination = $myhostname $mydomain
myorigin = $mydomain
Some Linux distributions that already include Postfix configure it to use procmail by default. procmail is a separate mail delivery agent (MDA) that can filter and sort mail as it makes deliveries to individual users on your system. If you need the features it provides, you should study the procmail documentation carefully to understand how it interacts with Postfix. For many systems, which don't filter mail for users at the MTA level, procmail is an unnecessary additional layer of complexity because Postfix can also make local deliveries and provide some of the same functions. Your distribution might be configured to use procmail in either the mailbox_command or mailbox_transport parameters. If you want Postfix to handle local deliveries directly, you can safely comment out either of these parameters in your /etc/postfix/main.cf file.
Once you have verified the important configuration parameters described earlier and rebuilt your aliases index file, you are ready to start Postfix. As the superuser, execute:
postfix start
You can stop Postfix by executing:
postfix stop
Whenever you make changes to either of Postfix's configuration files, you must reload the running Postfix image by executing:
postfix reload
Once you have Postfix running, all the users on your system should be able to send and receive email messages.
Any of your applications that depend on Sendmail should still work, and you can use the sendmail command as you always did. You can pipe messages to it from within scripts and execute sendmail -q to flush the queue. The native Postfix equivalent for flushing the queue is postfix flush. Options to Sendmail that deal with it running as a daemon and setting queue delays do not work because those functions are not handled by the sendmail command in Postfix. All the Postfix options are set in its two configuration files. Many parameters deal with the Postfix queue. You can find them in the manpage for qmgr(8).
After starting or reloading Postfix, you should check the log to see if Postfix reports any problems. (Most Linux distributions use /var/log/maillog, but you can also check the file /etc/syslog.conf to be sure.) You can see Postfix's most recent messages by running the command tail /var/log/maillog. Since Postfix is a long-running process, it's a good idea to check the log periodically even if you haven't been restarting it. You can execute the following to see if Postfix has reported anything interesting while running:
egrep '(reject|warning|error|fatal|panic):' /var/log/maillog
In general, Postfix keeps you informed of what is going on with your system by logging lots of good information to syslogd. On Linux syslogd uses synchronous writes by default, which means that after every write to the log file, there is also a sync to force everything in memory to be written to the disk. Therefore, the performance of Postfix (and other processes) can suffer. You can change this default by preceding the name of the log file with a hyphen in /etc/syslog.conf. Your entry in syslog.conf for mail logging should look like the following:
mail.* -/var/log/maillog
Be sure to have syslogd reread its configuration file after you make any changes. You can execute killall -HUP syslogd to reinitialize it.
Because of Postfix's compatibility with Sendmail, if you have your system configured to start Sendmail at system initialization, more than likely Postfix will start correctly when your system boots. However, system shutdown will probably not work correctly. Most Linux distributions shut down Sendmail by locating a process called sendmail and then killing that process. The Postfix processes, while in many ways compatible with Sendmail, do not run under the name sendmail, so this shutdown fails.
If you would like your system to shut down cleanly, you should create your own rc script for Postfix, as described in Chapter 5. The commands you need to include in your script to start and stop Postfix are exactly the same as those you execute on the command line, postfix start and postfix stop. Here's an example of a basic script to get you started. You may want to review other rc scripts on your system to see if you should add more system checks or follow other conventions and then make your adjustments to this example:
#!/bin/sh
PATH=""
RETVAL=0
if [ ! -f /usr/sbin/postfix ] ; then
echo "Unable to locate Postfix"
exit 1
fi
if [ ! -f /etc/postfix/main.cf ] ; then
echo "Unable to locate Postfix configuration"
exit 1
fi
case "$1" in
start)
echo -n "Starting Postfix: "
/usr/sbin/postfix start > /dev/null 2>1
RETVAL=$?
echo
;;
stop)
echo -n "Stopping Postfix: "
/usr/sbin/postfix stop > /dev/null 2>1
RETVAL=$?
echo
;;
restart)
echo -n "Restarting Postfix: "
/usr/bin/postfix reload > /dev/null 2>1
RETVAL=$?
echo
;;
*)
echo "Usage: $0 {start|stop|restart}"
RETVAL=1
esac
exit $RETVALPlace this script in /etc/rc.d/init.d or /etc/init.d, depending on your Linux distribution. Then make the appropriate symlinks in each of the rcN.d directories for each runlevel in which Postfix should start (see Section 5.3.2). For example, if you want to have Postfix start at runlevels 3 and 5 and stop at runlevels 0 and 6, create symlinks like those that follow for RedHat. For Debian the rcN.d directories are directly below /etc:
# cd /etc/rc.d/rc3.d # ln -s ../init.d/postfix S97postfix # cd /etc/rc.d/rc5.d # ln -s ../init.d/postfix S97postfix # cd /etc/rc.d/rc0.d # ln -s ../init.d/postfix K97postfix # cd /etc/rc.d/rc6.d # ln -s ../init.d/postfix K97postfix
If you create a Postfix rc script, you should configure your system not to start Sendmail at startup.
The default installation allows any system on the same subnet as yours to relay mail through your mail server. If you want to override the default, you can set the parameter mynetworks to be a list of hosts or networks that you trust to relay mail through your system. You can specify a list of IP addresses or network/netmask patterns, and any connecting SMTP client that matches will be allowed to relay mail. You can list network or IP addresses that reside anywhere. So, for example, if you want to be able to relay mail through your home Postfix system from your work machine, you can specify the IP address of your machine at work in your home Postfix configuration.
Here's an example that allows mail from the local subnet (192.168.75.0/28) and a single host located elsewhere:
mynetworks = 192.168.75.0/28 10.150.134.15
If you want to allow relaying for mobile users that do not have static IP addresses, you have to use some kind of SMTP authentication mechanism. Postfix can work with SASL Authentication (which requires that Postfix be compiled with additional libraries, and that users' client software be specially configured) and pop-before-smtp (which requires a POP server running on the same system to first authenticate users).
It is important not to open relay access to anyone except users you trust. In the early days of the Internet, open relays were commonplace. Unfortunately the current prevalence of spam has precluded that kind of freedom. If your MTA is not protected, you leave yourself and other Internet systems vulnerable to abuse. Spammers constantly scan for open relays, and if you place one on the network, it is only a matter of time before it will be found. Fortunately, the default Postfix installation behaves correctly. However, if you make lots of changes to your Postfix configuration (especially in setting up antispam controls, ironically), you may inadvertently open yourself up to relay abusers.
If you want your own Postfix installation to relay mail through another MTA, specify the IP address of the relay server using the relayhost parameter. Postfix normally figures out where to deliver messages on its own, based on the destination address. However, if your system is behind a firewall, for example, you may want Postfix to hand off all messages to another mail server to make the actual delivery. When you specify a relay server, Postfix normally performs a DNS query to obtain the mail exchanger (MX) address for that system. You can override this DNS lookup by putting the hostname in square brackets:
relayhost = [mail.example.org]
The configuration described here creates a simple Postfix installation to send and receive messages for users on your system. But Postfix is an extremely flexible MTA with many more configuration options, such as hosting multiple virtual domains, maintaining mailing lists, blocking spam, and virus scanning. The manpages, HTML files, and sample configuration files that come with Postfix contain a lot of information to guide you in the more advanced configurations.
If your provider stores your mail for you until you fetch it, and you do not want to use your mailer to download the mail, you need a program that retrieves the mail from your provider's computer. There are a lot of programs for doing this; we will discuss fetchmail here briefly because it is both robust and flexible and can handle both POP3 and IMAP.
You can get fetchmail from your friendly Linux archive; chances are that your distribution carries it, too. In case you download a source distribution of fetchmail, unpack, build, and install it according to the installation instructions. At the time of this writing, the current version is 5.9.13.
You can control fetchmail's behavior via both command-line options and a configuration file. It is a good idea to first try to fetch your mail by passing the necessary information on the command line, and when this works, to write the configuration file.
As an example, let's assume that my provider is running the POP3 protocol, that my username there is joeuser, and that my password is secret. The hostname of the machine where the POP3 server is running is mail.isp.com. I can then retrieve my mail with the following command:
fetchmail --protocol POP3 --username joeuser mail.isp.com
fetchmail then asks me for my password and, after I specify it correctly, retrieves the mail waiting for me and passes it on to my MTA for further delivery. This assumes that a SMTP server is running on port 25 of my machine, but this should be the case if I have set up my MTA correctly.
While you are experimenting with fetchmail, it might be a good idea to also specify the option — keep. This prevents fetchmail from deleting the messages from your POP3 account. Normally, all messages are deleted from your provider's hard disk once they are safely stored on your own machine. This is a good thing because most providers limit the amount of mail you can store on their machines before retrieving them, and if you don't delete the messages after fetching them, you might reach this limit quite quickly. On the other hand, while testing, it is a good idea to be on the safe side and use — keep so as not to lose any mail.
With the aforementioned options to fetchmail, you should be able to get your mail in most cases. For example, if your provider uses the newer IMAP protocol, simply specify IMAP in the command line instead of POP3. If your provider has some unusual setup, you might need one of the other options that the fetchmail(1) manual page tells you about.
Once you are satisfied with the download process, you can write a fetchmail configuration file in order not to have to enter all the options each time you use the command. This configuration file is called .fetchmailrc and should reside in your home directory. Once you are done editing it, make sure it has the permission value 0600 so that nobody except yourself can read it because this file might contain your password:
chmod 0600 ~/.fetchmailrc
The full syntax of the configuration file is detailed in the fetchmail manpage, but in general you need only very simple lines that start with poll. To specify the same data as on the command line in the previous example, but this time include the password, put the following line into your configuration file:
poll mail.isp.com protocol pop3 username joeuser password secret
Now you can run fetchmail without any parameters. Since fetchmail already knows about your password from the configuration file, it will not prompt you for it this time. If you want to play it safe while testing, add the word keep to the poll line.
Using fetchmail with a configuration file has one additional advantage: you can fetch mail from as many mailboxes as you want. Just add more poll lines to your .fetchmailrc, and fetchmail happily retrieves your mail from one server after the other.
When and how you run fetchmail depends on your connection to the Internet. If you have a permanent connection or a cheap, flat rate, you might want to have fetchmail invoked by cron at a suitable interval (like once an hour). However, if your Internet connection is nonpermanent (dial-up) and costly, you might want to choose to run fetchmail by hand whenever you actually want to fetch and read your mail so as to minimize your Internet connection time. Finally, if you are using PPP for dialing in to your Internet service provider, you might want to invoke fetchmail from the ip-up script, which is invoked as soon as an Internet connection is made. With this setup, when you browse a web page and your computer dials up your provider, your mail is fetched automatically.
In this section we describe tasks, services, and some additional utilities involved in managing your electronic mail system.
You should normally use only one Internet host to get all your mail. It is possible to use a more complex arrangement, but this is frowned upon because of the possibility of setting up loops — virtual Sargasso Seas of lost network information. Loops can route mail in circles, passing over and over through the same machines until they "time out" by exceeding the limit on the number of machines they can pass through.
If you want to get your mail directly from the Internet, you need to register an Internet domain name for your system. Please see Section 16.2.1.1 for more information about this.
You should set up a cron task to occasionally check the mail queue (usually /var/spool/mqueue) and force an attempt to deliver mail that wasn't previously delivered for some reason. Mail can be queued because a host is temporarily unreachable, or a filesystem is full, or for myriad other little reasons. cron is discussed in Section 8.2.
The mail administrator also should occasionally check the mail queue and make sure no messages are "stuck" there:
$ mailq
This command generates a report on any mail in the queue. The actual name and syntax of the command may vary depending on the MTA chosen.
KMail is a very user-friendly, feature-rich mailer that comes with KDE and integrates mail smoothly with other utilities. For example, if an email message you receive contains a link to a web page, you can click this link in the message, and the KDE web browser Konqueror will pop up and display the web page. Or, if the email contains an MP3 file as an attachment, you can click it to play the file with one of KDE's MP3 players. Figure 16-4 shows a screenshot of KMail at work.
KMail has a lot of features and settings, but we'll only cover those that get you started quickly and leave it to you to explore KMail further. As you can see in Figure 16-4, the KMail window is divided by default into three parts. On the left, you see a tree of your folders (at first startup, you will have only the default folders, of course). The upper part of the right side shows a listing of messages in the currently selected folder, and the lower part of the right side shows the currently selected message. You can change how the space is distributed between these parts by dragging the separator lines between them. The latest KMail versions even have a fourth part that lets you drill further into the structure of an individual message by displaying the MIME parts the message is composed of. However, this display is turned off by default, as most people do not need it.
Before you can use KMail, you have to set up some information in it. Select Configure KMail from the Settings menu and then open the configuration group Identity by clicking its icon. You can create a number of different identities here; for example, you may want to use different return addresses when emailing as an employee of your company or as a private person. For starters, it is sufficient to fill in the fields Name and Email Address on the General tab (see Figure 16-5).
Next, go to the Network configuration group. Here, you need to create at least one account for outgoing mail and one for incoming mail.
Let's start with the outgoing mail that you will find on the Sending tab (see Figure 16-6). Click the Add... button. You will be asked whether you want to use SMTP or talk to a sendmail installation directly. In almost all cases, if you have an MTA installed locally, you will want to select SMTP. Then, on the General tab of the SMTP transport configuration, give the transport a name (which you can choose arbitrarily because it exists only for you to recognize the settings later and will not be used in any network communication). In any case, you need to enter the hostname of the port. The port is almost always 25; the hostname should be given to you by your provider. If you have a local MTA installed and want to use it, simply enter localhost. If your mail server requires authentication (check with your provider if you are unsure), check the appropriate checkbox and fill in the login name and password.
This should be enough to let you send outgoing email, but we recommend that you take a few additional steps to make this as secure as possible. KMail makes this easy for you by autodetecting the security settings of the SMTP server you are using. Go to the Security tab and click the button labelled "Check what the server supports." KMail will check the connection to the server and use the settings with the highest supported security. Alas, many providers run their mail servers without any security at all.
Now let's continue by configuring the receiving end. Close all subdialogs until you are back at the Network configuration group, and select the Receiving tab. Here you can set up a number of accounts to be queried. This can be useful if you have more than one provider that stores email for you. Click the Add... button and select the type of mail server. If you run your own MTA locally, you need to select Local Mailbox. Usually, you can then accept the defaults on the next page (but change the name to something more appropriate than "Default").
If you retrieve your messages directly from your provider's server, you need to select either POP3 or IMAP, depending on what your provider supports. In the dialog that appears again enter a name of your own choice, then specify your login name, your password, the name of the host that stores your email, and the port (usually 110 for POP3 and 143 for IMAP). All this information should be given to you by your provider or system administrator. You can leave all other options as they are for now, and experiment later with them.
Close all dialogs with the OK button. You should now be ready to
retrieve your email. To do so, select File 
Check
Mail from the menu. This will retrieve all messages from all incoming
mailboxes that you have specified. If it does not work or you get any
error messages, check all the values you entered on the various
configuration pages again and compare them to the information given
to you by your provider or system administrator. The most typical
error is a typo in the hostname, username, or password.
In order to send a message, press Ctrl-N or select Message
New Message. A composer window opens where you can
type in the recipient's address, the subject, and
the actual message body. If you have configured more than one
identity, you can also select the one to be used for this message.
When you are done composing your message, press Ctrl-N. Depending on
how you have configured your outgoing mail transport, the message
will either be put into the output folder and wait there for further
handling (this is the default) or be transmitted directly. If you
want to override your setting for a particular email, just select
Message Queue or Message Send
Now from the menu bar of the composer window.
Messages put into the output folder are by default not sent
automatically (you can, however, configure KMail to always send
messages in the outbox when it checks for incoming messages). To send
all messages in your outbox, select File Send
Queued from the menu bar of the main KMail menu.
If you have problems sending your messages, again please check the settings you have made for typos. Also, in order to prevent the relaying of unsolicited commercial email (so-called spam) via their servers, some providers require that you check your mailbox on the server (providing your username and password as you go) in order to identify yourself, before you can send any email via that server. After you have checked your incoming email, you have a certain period of time (often 15 minutes) to send your outgoing email.
You should now know enough about how to use KMail in order to
continue exploring the mailer on your own. One of the first things
you may want to do (especially if you have a large number of messages
to handle everyday!) is to create folders by selecting Folder
Create and then set up filters by selecting
Settings Configure Filters. This lets you redirect
messages with certain characteristics (e.g., certain senders or
subjects) to predefined folders. For example, you may want to gate
all messages from a mailing list to a folder dedicated to that
purpose.
Mozilla Mail & News is the mail client that comes with the Mozilla web browser if you install more than the minimal installation (which only contains the browser and the composer itself). Chances are that your distribution already carries Mozilla, but if it doesn't, or you'd rather have a newer version, you can download that from http://www.mozilla.org.
The concepts for setting up and using Mozilla Mail are quite similar
to those for KMail, so we will cover only the differences here. In
order to open the mail client, start Mozilla and select Windows
Mail and Newsgroups from the menu. If you are
starting the mailer for the first time, a wizard will pop up that
lets you configure your email. Check Email account on the first page
and your identity information on the second page
(Mozilla's account handling is slightly less
flexible than KMail's because it ties identities to
accounts, while you can change identities at will with KMail).
On the third page, select whether you get your incoming mail via POP or IMAP (it's not possible to retrieve your email locally with Mozilla Mail & News, a big drawback), and specify the incoming and outgoing server name (specify localhost both times if you are running your own MTA). Complete the remaining information on the next pages, and you are ready to run Mozilla Mail & News. The screen layout is by default exactly the same as that of KMail.
As when using KMail, one of the first things you probably want to set
up when using Mozilla Mail & News is additional folders and
filters that sort your incoming messages into these folders. You can
create new folders by right-clicking the folder list and selecting
New Folder... in the context menu that appears. You can configure the
filter rules by selecting Tools Message
Filters....
This concludes our discussion of using email on Linux. As you can see, many options, from simple to sophisticated, are available to help you administer and digest the daily flood of email messages.
|  | |
| 16. The World Wide Web and Electronic Mail |  | 17. Basic Security |
Copyright © 2003 O'Reilly & Associates. All rights reserved.